SeriesGuide
SeriesGuide copied to clipboard
UweTrottmann
Reports of too many watches sent to Trakt
Quoting from an email of a user:
The Following is what Sean from Trakt responded to me. It looks like SeriesGuide stuffed your account with 213k play history items. Your play history has been de-duplicated to the best of our ability, and your API access has been unlocked.
Before using Trakt's API again, make sure to find a fix from this third party applications developer, or disable it entirely.
Let me know if there's anything else I can help you with.”
Additional context Apparently the user has been manually triggering a sync. But AFAIK this shouldn't e.g. trigger a full data merge.
Note: it is expected that SeriesGuide sends watched episodes to Trakt that are not watched on Trakt when connecting on the first sync only. So if the sync/watched/shows API response does not contain the latest data SeriesGuide may send plays for already watched episodes.
Need to find more users affected by this. Also check if the TMDB migration has broken things (though did test at the time and found no issues).
It appears this can happen due to SeriesGuide re-sending plays (maybe also collects) due to a network or any other error, but the change was already applied at Trakt servers.
Maybe the assumption that a play/collect is not duplicated as long as the watchedAt/collectedAt timestamp is the same is no longer true. Emailed Sean (@rudf0rd) from Trakt to ask. If time, also try to verify this. https://github.com/UweTrottmann/SeriesGuide/blob/ac50cad579a133eec7b3f3c42889759652f75fa5/app/src/main/java/com/battlelancer/seriesguide/jobs/TraktEpisodeJob.kt#L123-L127
Yeap, confirmed. Trakt now adds another play, even if the timestamp is exactly the same.
Still, now need to figure out how to prevent sending a duplicate watch (e.g. download the whole history each time before sending a play?!).
Edit: sending multiple collects with the same timestamp is fine, no duplicate added.
It should be possible to check after failure with https://trakt.docs.apiary.io/#reference/sync/get-history/get-watched-history, then setting the Trakt ID for an episode (which would need to be resolved first) and setting start_at and end_at to the exact timestamp.
This is not really feasible. For every episode would have to currently do 2 network calls (look up Trakt ID, check history). So if e.g. sending a play for 20 episodes, that's 40 extra network calls.
Check if loading history for whole show would work, filtered by timestamp. Edit: should work. So only one extra network call as the code already has the Trakt show id.
Sean also mentioned duplicate watched entries ~ 40 seconds apart existed for the user. It's impossible these were triggered by job processing which stores the timestamp to send until success.
A possible scenario to explain is:
- user marks episode(s) watched,
- Trakt sync runs before job processing and marks episodes not watched again,
- watched entries get added multiple times at Trakt.
However, this is very unlikely. E.g. Trakt sync would have to be in progress, or job processing fails repeatedly, but sync succeeds. At this point it's also reasonable the user might actively troll, e.g. by restoring from a backup and marking episodes watched again.
#874 is available with SeriesGuide 65, now also rolling out to everyone.
No further reports, fix appears to work as intended in production as well.