[harshdeepsinghin]

automaticUpdateCheck() reads the stored lastCheckedForUpdates value with the wrong format:

self.lastCheckedForUpdates = QDateTime.fromString(self.config["lastCheckedForUpdates"], 'yyyy-MM-dd HH-mm-ss')

The value is written by GuiConfiguration.loadLastUpdateCheckDate() with "yyyy-MM-d HH:mm:ss.z" — the time uses colons and there is a fractional part — so QDateTime.fromString() always returns an invalid QDateTime.

With current PySide6, calling toPython() on an invalid QDateTime raises:

ValueError: year must be in 1..9999, not 0

The surrounding try/except swallows this and logs "Automatic check for updates failed. An update check was manually trigggered...", then forces a manual update check on every launch.

Reproduced with a config value of 2026-10-11 23:09:28.838:

• before: QDateTime.fromString(value, 'yyyy-MM-dd HH-mm-ss') → invalid, toPython() raises ValueError
• after: QDateTime.fromString(value, 'yyyy-MM-d HH:mm:ss.z') → valid

The fix parses with the same format the value is written with, ignores a value that fails to parse, and treats an invalid date as never checked, so toPython() is never called on an invalid QDateTime.

[Et0h]

Cheers for your work on this.

The mismatch between the saved date format and the format used by QDateTime.fromString() looks like a genuine bug, and the additional validity checks seem sensible.

One small improvement before merging: automaticUpdateCheck() still calls datetime.strptime() before validating the date. If the saved value is malformed, this raises an exception and triggers an unnecessary update check, even when self.lastCheckedForUpdates already contains a valid date.

Could you remove the separate datetime.strptime() call and compare lastCheckedFromConfig directly with self.lastCheckedForUpdates after checking that both dates are valid? This would also avoid parsing the same configuration value twice.

It would be useful to confirm that a recent saved timestamp prevents another automatic update check after restarting Syncplay, while an old, missing or invalid timestamp is handled correctly.

Otherwise, this looks like a good, focused fix.

[harshdeepsinghin]

Thanks for the review @Et0h! I've removed the redundant datetime.strptime() call and now compare QDateTime objects directly after validating both dates. This parses the config value only once with the correct format. Pushed as f3fccb7.