The first sync no longer guesses profile 1 (#19), and Continue Watching removal reaches all three places it lives (#22).
#19 — where the other profile's data came from
Reported again after v1.0.11, still happening on Tizen. It is deterministic, and the repository already described it — in a comment next to the code that papers over it.
Every RPC in the sync cycle is per-profile: add-ons, credentials, progress, library, watched items, collections, settings, home catalogs. All of them carry p_profile_id. And the active profile starts at 1, becoming the real one only once somebody chooses.
So on an account with more than one profile and no choice saved on that TV, startup went: begin the sync immediately with profile 1 → pull the whole cycle for profile 1 → build the Home with profile 1's data → then notice a choice was needed → show the picker → second cycle → everything switches. That last switch is exactly what the video shows.
This was known. The comment on the code that runs the second cycle reads: "brings this profile's add-ons and progress, and not profile 1's, which the first cycle picked up for lack of a choice." The second pass fixed the data; it did not unfix what had already been on screen.
The cycle now stops right after reading the profile list when a choice is pending. An empty Home for a few seconds beats another profile's Home.
It costs nothing to anyone who has already chosen: with a saved profile there is no pending choice and the cycle runs in full, exactly as before.
Two theories ruled out before landing on this, recorded so nobody re-investigates them: it is not packaged data — the Tizen art stage is an allow-list and ships without .txt, .bin or the sample catalog, verified in the staged output. And it is not a filesystem race — the IndexedDB mount awaits its initial load, so the saved profile is readable by the time it is read.
#22 — removal was deleting one of three places
The resume row is the merge of three sources: the local record, Trakt's /sync/playback, and the Nuvio account's progress. Only the local one was being deleted, so with Trakt connected the entry returned on the next sync and removal could never stick.
Trakt deletes by the playback record's own id, not by the IMDb id. That id arrived when the list was read and was discarded on the spot; it is kept now. The account's sync_delete_watch_progress existed and was never called.
And a silence is gone. A separate report the same day — "I press mark as unwatched and nothing appears in the log" — was a genuinely mute failure path: the history call refused without a word when a previous request was still in flight, which can be 20 seconds. Every press in that window failed without attempting anything. It says so now. I did not fix what causes the wait; I made it impossible for it to be invisible.
Text appearing blank when a screen opens
Only two new text lines could be rasterised per frame, so opening a dialog left most of its text blank for several frames — on a slower device that reads as "the text disappears", which is how it was reported on Tizen.
Measured on an OLED65C9, same gesture both times:
before: texto 2.5ms em 2 linhas, worst frame 23.6 ms, 0 janks
after: texto 5.1ms em 4 linhas, worst frame 30.0 ms, 0 janks
Only on the frame where the screen opens; in steady state both read texto 0.0ms em 0 linhas. The jank counter decides whether this can go higher — if it leaves zero, the right move is three, not ignoring it.
Installing
Samsung Tizen 5.5+ — NuvioTV-1.0.23-tizen.wgt, unsigned; sign it with your own TV's DUID (steps in the v1.0.7 notes).
LG webOS 4.x — space.nuvio.native.legacy_1.0.23_arm.ipk. Everything from v1.0.21 and v1.0.22 is included.
Unofficial, and not affiliated with NuvioMedia.