Removing from Continue Watching now actually removes it (#22), and text stops appearing blank when a screen opens.
#22 — it 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. The menu deleted only the local one. With Trakt connected — which is the reporter's case — the entry came straight back on the next sync, so removal could never stick.
Trakt deletes by the playback record's own id, not by the IMDb id: DELETE /sync/playback/<id>. That id arrives when the list is read and was being discarded on the spot. It is now kept in a side table — deliberately not a new field on the catalog item, because sizeof(CatItem) is part of the on-disk cache header and growing the struct would invalidate every cached Home screen, which was only just repaired. The id is dropped from the table only when the server accepts; forgetting it on a 5xx would make the second attempt report "no id" and leave that item unremovable until the app restarted.
The account has its own RPC, sync_delete_watch_progress, which existed and was never called. Its p_keys takes the progress key, not the content id — sending the content id would delete every episode of the show.
Neither remote deletion is required: no Trakt means no id, no account means no RPC, and the local removal happens either way. Both say in the log what they did.
rede.c gained a real DELETE for this. Not a POST with an empty body — Trakt answers 404 to a POST on that path.
Every refusal from the history call now speaks
Reported the same day: "I press mark as unwatched and nothing appears in the log."
trakt_assistido_tipo had two silent exits: Trakt disconnected or an invalid id, and "a request is already in flight". The second is the one that misleads — the previous request can take up to 20 s to time out, and during that window every press returns failure without attempting anything and without writing any state, so the dialog looks exactly like a server refusal.
I did not fix what causes the wait; I made the silence impossible. Without a line in the log there is no way to tell three different causes apart, and the next report now arrives with the answer inside it.
Text appearing blank when a screen opens
Only two new text lines could be rasterized per frame. That ceiling exists for a real reason — rasterising costs, and a fresh screen asks for dozens of unseen lines at once — but with two, opening a dialog left most of the text blank for several frames. On a slower device that reads as "the text disappears", which is exactly how it was reported on Tizen, and it is what the photograph of the options dialog showed.
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
And only on the frame where the screen opens — in steady state the telemetry reads texto 0.0ms em 0 linhas in both cases. The jank counter is what decides whether this number can go higher; if it leaves zero while opening a screen, the right move is three, not ignoring it.
Installing
Samsung Tizen 5.5+ — NuvioTV-1.0.22-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.22_arm.ipk. Everything from v1.0.21 is included.
Unofficial, and not affiliated with NuvioMedia.