Deleted Jellyfin users linger as remembered profiles — no server-side reconciliation, and the active profile can't be removed manually

[classicjazz]

What happened?

After I deleted a secondary user on my Jellyfin server, that user still appears in Sodalite as a remembered profile — in both the launch profile picker and Settings → Profile.

Sodalite never reconciles its locally-stored remembered-profile list against the server's current users. Remembered profiles live in the keychain (one cached access token each) and every picker renders straight from that local list. SessionRestorer.restore() runs entirely off local keychain/preferences with no network call, so a cold launch never checks them. /Users/Public is fetched only on the "Add another profile" screen, and only to hide already-added users — never to prune ones that vanished. The only auto-prune path (probeActiveUser) runs solely on a server switch and only for the currently-active profile via a /Users/Me 401; it never inspects the other remembered profiles.

Expected: Sodalite drops any remembered profile that is no longer a valid user on the server — e.g. on cold launch / when a profile grid is shown, or when a cached token is rejected with 401.

Manual removal does exist (press-and-hold a profile card → "Remove profile"), but: (a) there's no on-screen hint for it in the launch picker and it's hard to discover on tvOS, and (b) it's disabled for the profile you're currently signed in as, so if the deleted server user is your active profile the only recourse is a full Logout.

Steps to reproduce

1. On the Jellyfin server, create a second user.
2. In Sodalite: Settings → Profile → "Add another profile", sign in as that second user so it's saved as a remembered profile, then switch back to your main profile.
3. On the Jellyfin server, delete the second user.
4. Relaunch Sodalite and/or open the launch profile picker and Settings → Profile.
5. Observe: the deleted user is still listed as a selectable profile. Nothing in the app removes it. Selecting it just fails (its token is now invalid) without cleaning the entry up.

Sodalite build

1.0.0 (build 22)

tvOS version

26

Apple TV model

Apple TV 4K (gen 3)

Jellyfin server version

10.11.11

Media (if a playback bug)

N/A

Anything else

• Relevant code: DependencyContainer.listRememberedUsers / forgetUser (keychain rememberedUsers blob), SessionRestorer.restore() (local-only), UserPickerView.loadUsers() (/Users/Public, add-only), DependencyContainer.probeActiveUser() (active-user-only 401 prune, server-switch-only), refreshActiveUserDetails() (swallows errors).
• Suggested fix: when building the launch/Settings profile grid (or on cold launch), fetch /Users/Public once and drop any remembered profile whose ID is absent from the server's list; record the removal through the existing forgottenUsers mechanism so it propagates via cloud sync. Separately: show the "press and hold to remove" hint in the launch picker too, and allow manual removal of the active profile (falling back to Logout when it's the last one).

[superuser404notfound]

Fixed on main in 8d2ad5f. Thanks for the write-up, the code pointers in it were exactly the right ones and saved a full pass through the session layer.

One deviation from the suggested fix, and it is the load-bearing part: the reconcile asks /Users, not /Users/Public. /Users/Public is a login-screen list, and Jellyfin filters it (UserController.GetPublicUsers calls Get(false, false, true, true)): no IsHidden users, no IsDisabled users, filtered by device access, and, whenever the request does not come from the local network, filtered down to users with EnableRemoteAccess. A profile missing from that list is therefore not evidence that the account is gone, and pruning on it would have deleted real profiles for anyone with a hidden user, a temporarily disabled one, or a device signing in from outside the LAN. Since the removal is recorded through the existing forgottenUsers tombstone and travels to every synced device, a wrong verdict there is expensive. /Users needs a token but no admin rights ([Authorize], verified on 10.10.7 and 10.11.11) and hides nobody.

What the reconcile does now:

• Holds the active server's remembered profiles against /Users and drops the ones the server no longer has, through the same forgetUser a manual removal takes: tombstone, Seerr session, cached password, default-profile pin.
• Withholds a verdict when the answer is not one to act on: an empty listing, or one that does not carry the session's own user (a proxy, a different backend behind the same URL). A failed request changes nothing.
• Runs on cold launch, when either profile grid appears, and after a server switch, throttled so the launch pass and the picker behind it do not each ask. Only for the active server, since it rides that session's token.

The 401 side is now one path as well. checkActiveSession asks /Users/Me, mints a fresh token from that profile's own stored password when there is one, and only then drops the profile and the session pointers with it. A refusal is read off a 401 alone, so a re-login that fails on the transport leaves every credential where it is. AppRouter, the launch picker and Settings act on that verdict instead of discarding it, so picking a profile whose token is dead lands back on the picker with a message naming it, rather than entering a session that fails one request at a time.

Both points from the second half are in too: the launch picker now names the long-press removal it never pointed at, and the profile you are signed in as can be removed there and in Settings. It ends that session and re-resolves to the server's picker, which is the difference between it and Log Out, which takes every server on the device.

A retest on the reported setup would be welcome, in particular the case where the deleted user is the active profile, and the case of a hidden or disabled user, which must survive every pass.

[classicjazz]

Confirming that the previously deleted inactive user was automatically removed after I installed Testflight 1.0.0 build 24.

I then created a new user in Jellyfin and added that user profile to Sodalite. It worked as normal.

Next, I deleted the user profile in Sodalite but it remained while it was the active profile. Exiting Sodalite and returning, I switched to another user profile (so the deleted user profile was no longer active). After it was inactive, it was deleted from Sodalite automatically.

Therefore, I think there is still a remaining issue with the deleted Jellyfin user who is active profile in Sodalite.

[superuser404notfound]

Thanks for taking it back through the whole loop, the second half is a real hole and the write-up isolates it precisely: while active nothing happens, inactive it goes.

Fixed on main in e438d10.

The cause is a rule from the first round. The reconcile holds the remembered cards against /Users, and it withholds a verdict whenever that table does not carry the session's own user. That was written for a table belonging to somebody else (a proxy, a different backend behind the same URL, a server mid-restore), where dropping profiles would be wrong and expensive, since the removal travels to every synced device as a tombstone. It is also, word for word, the signature of the active profile being the user that was deleted. So the pass abstained exactly where it should have acted, and the card only fell the moment another profile took over the session, which is what you measured.

There is a second shape of the same case. Deleting a user takes its access tokens with it, so /Users can come back refused rather than come back without the user in it, and that 401 was swallowed by a try? in the same function.

Nothing in the table itself tells a deleted user apart from a foreign table, so the reconcile stops trying to and asks the token instead. Both shapes now go through checkActiveSession, the single place a refusal is acted on: it asks /Users/Me, tries the profile's own stored password for a fresh token, and only a second 401 drops the profile, with the tombstone, the cached password, the Seerr session and the session pointers that entails. Once the session is over, the remaining cards are held against the same table in the same pass, so a second stale profile no longer waits for another launch.

The protection stays: a token that still resolves against a table that does not list it decides nothing, and neither does an empty table or a request that fails on the transport. A profile is only ever dropped on a 401 the stored password could not recover.

A retest on your setup would be welcome, in particular:

• the reported case, the deleted Jellyfin user is the active profile in Sodalite, both from a cold launch (profile picker) and from Settings > Profile
• a hidden or disabled Jellyfin user, which must survive every pass untouched
• a deleted user that is not the active profile, which the build 24 behaviour already covered

[classicjazz]

In Testflight 1.0.0 build 25, if you delete a user from Jellyfin, I see the following:

If the user is the active Sodafin user, and you are on the profile picker screen, nothing happens. But as soon as you attempt to access the Jellyfin library, the connection is refused and you are returned to the profile picker with the following modal dialog box:

"Profile removed ("the server refused the saved sign-in for...")"

Dismiss that and it shows the other active user or allows you to select another server.

This behavior seems to address the core issues.

I don't fully understand the other tests that you want me to do. But I think you have solved the major issues and I am good with closing this topic. Thanks.

If you need additional testing please let me know more specifically what next.