Not all servers get added to "Jump back in" worlds, server permanently marked as "Not played yet"

[RMEngelbrecht]

Please confirm the following.

• [x] I checked the existing issues for duplicate problems
• [x] I have tried resolving the issue using the support portal
• [x] I have ensured my Modrinth App installation is up to date

What version of the Modrinth App are you using?

0.10.7

What operating systems are you seeing the problem on?

Windows

Describe the bug

Certain servers (though I'm not too sure what the criteria is) do not get added to the "Jump back in" section on the home screen, even when all settings indicate it should. For me e.g. MCC Island works great and gets added to home page, while my own never shows up there. Have also confirmed other servers to be the same.

Steps to reproduce

1. Make sure your settings allow for servers to show up on the Jump back in section (Appearance > Jump back into worlds & Triple dots on the server -> Edit -> Unchecked "Hide from Home page")
2. Join the server while in the Instance -> Worlds screen: observe the playtime updating
3. Go back to the Home page: observe server missing
4. Go back to Worlds tab and see the last play time got reset to "Not played yet"

Optionally:

• Join other server to confirm that one is working; for me mcc island works great and gets added to home page, while my own never shows up there.

Expected behavior

All servers get added to the Home page when settings allow for it.

Additional context

No response

[RMEngelbrecht]

Needs confirmation if it's been fixed or still persisting right now. If still persistent I have an inkling that this issue is related to SRV DNS records compared to A records.

[Qibloon]

I also have this issue it should get fixed

[Hajdew]

Still errors to this day and found some logs

WARN theseus::state::process: Failed to update playtime for profile yo 1.0.7: Error interacting with database: error returned from database: (code: 1) unsupported file format

[Hallskii]

Hi there, can you share logs of a server this happens for?

[RMEngelbrecht]

Sorry I probably should've added logs from the get go but didn't realise the launcher logs are saved. I confirmed this issue still occurs with some servers.

Here is the launcher log:

2026-01-02T23:58:28.222909+01:00  INFO theseus_gui: Initialized tracing subscriber. Loading Modrinth App!
2026-01-02T23:58:28.230762+01:00  INFO theseus_gui: Initializing app...
2026-01-02T23:58:28.481071+01:00  INFO theseus_gui::macos::deep_link: No initial payload found, creating new
2026-01-02T23:58:28.672452+01:00  INFO initialize_state: theseus_gui: Initializing app event state...
2026-01-02T23:58:28.672636+01:00  INFO initialize_state: theseus_gui: Initializing app state...
2026-01-02T23:58:28.672647+01:00  INFO initialize_state:initialize_state: theseus::state: Connecting to app database
2026-01-02T23:58:28.676187+01:00  INFO initialize_state:initialize_state: theseus::state: Fetching app settings
2026-01-02T23:58:28.676346+01:00  INFO initialize_state:initialize_state: theseus::state: Initializing directories
2026-01-02T23:58:28.676476+01:00  INFO initialize_state:initialize_state: theseus::state: Initializing file watcher
2026-01-02T23:58:28.683106+01:00  INFO init_watcher: theseus::state::fs_watcher: Initing watcher
2026-01-02T23:59:07.275327+01:00  WARN theseus::state::process: Failed to update playtime for profile Vanilla: Error fetching URL: HTTP status client error (401 Unauthorized) for url (https://api.modrinth.com/analytics/playtime)

I did some extra testing and the [...] Error fetching URL: HTTP status client error (401 Unauthorized) [...] error line also gets pasted into the log again after I join a server who's status does work afterwards.

Thus I'm not completely sure if this is the cause, but I hope it is an extra nudge in the right direction.

[Hallskii]

Are you logged in and does logging out/in fix it?

[RMEngelbrecht]

Signed out, signing in doesn't fix it:

2026-01-07T08:23:28.338338+01:00  INFO theseus_gui: Initialized tracing subscriber. Loading Modrinth App!
2026-01-07T08:23:28.346637+01:00  INFO theseus_gui: Initializing app...
2026-01-07T08:23:28.719734+01:00  INFO theseus_gui::macos::deep_link: No initial payload found, creating new
2026-01-07T08:23:29.119541+01:00  INFO initialize_state: theseus_gui: Initializing app event state...
2026-01-07T08:23:29.119811+01:00  INFO initialize_state: theseus_gui: Initializing app state...
2026-01-07T08:23:29.120098+01:00  INFO initialize_state:initialize_state: theseus::state: Connecting to app database
2026-01-07T08:23:29.127410+01:00  INFO initialize_state:initialize_state: theseus::state: Fetching app settings
2026-01-07T08:23:29.127540+01:00  INFO initialize_state:initialize_state: theseus::state: Initializing directories
2026-01-07T08:23:29.128372+01:00  INFO initialize_state:initialize_state: theseus::state: Initializing file watcher
2026-01-07T08:23:29.135612+01:00  INFO init_watcher: theseus::state::fs_watcher: Initing watcher
[...]
2026-01-07T08:24:00.972779+01:00  INFO authenticate_finish_flow{code="mra_VbEsmGU8sGMnuVtIbXRA2ygTLiP6DCGZhAdpf36ZnxB5WCTWMXSRzgevNDqM"}:connect: theseus::state::friends: Connected to friends socket
2026-01-07T08:24:25.488843+01:00  WARN theseus::state::process: Failed to update playtime for profile Vanilla: Error fetching URL: error decoding response body

[Hallskii]

Looking at the logs, this doesn’t appear to be server-specific. The warning is for failing to update playtime on the instance being launched, not the server itself. The “recently played” section is derived from instance activity, so if that update fails the server state won’t persist

This points to something environment-specific (for example network issues, VPNs, proxies, or a bad response from the playtime endpoint) rather than a bug tied to a particular server

We could make this more robust by not solely deriving recent worlds from instance persistence, but that isn’t on the roadmap right now. Closing this for now

[RMEngelbrecht]

@Hallskii would it be possible to get more verbose logging for the response body being referenced in the logs for more complete debugging? While I get the logs look like they're profile specific I'm wondering whether it depends on the response body generated for the server.

The playtime update behaviour failing is server specific, I can launch 2 servers back to back and 1 gets their playtime updated while the other one doesn't. So, as you said, a bad response from the playtime endpoint to me sounds the most logical. I would love to spend more time debugging this with the actual response body visible.

To add to this: I changed my own server from an SRV DNS record to an A record and it fixed the issue for my own server. This doesn't seem to be the root issue, as I've checked other servers' records, but I do think it points more in the direction of a malformed response body for certain servers causing their playtime update to fail.

[Hallskii]

Yeah you're right we need to look into this more. Observation as a whole is a bit of a mess right now and I don't think we log the response body for failed playtime updates, so we can't see whether its malformed JSON or something else entirely. I've made a ticket for this internally, but it isn't a massive priority so I can't give an estimate. That said we're in the process of improving logging across the product