You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey!
Not sure whether it's expected behaviour (because everyone is fine with current implementation) or not, but
when synchronisation happens, this script fetches all the "watched" entries from trakt, which is IMO not great:
it means that the more you scrobble to trakt, the more load you'll introduce on the service even if your collection is of manageable size,
it'll take longer and longer for sync to happen because it's just more stuff to do,
only shows/movies that are available in local db are being synced from trakt,
history of scrobbles doesn't affect performance of the sync on its own,
scrobbles are not copied between shows with identical names
Current Behavior
performance of the sync becomes worse the longer is your scrobble history,
scrobbles can be copied between shows with identical names if you have scrobble_fallback option (which is enabled by default)
Possible Solution
I see no reason to fetch all the watched entries, perhaps just fetching data for shows/movies that are present in local db.
I briefly glanced over trakt API and it doesn't seem like there's a way to fetch only entries with given ids (AFAIU there's only "fetch by id" for single entry), which is probably a blocker for this suggested solution (and maybe there are other reasons to fetch everything?)
Other approach could be to forbid matching of local show that was already matched to remote show A, to a different show B.
Steps to Reproduce (for bugs)
See example below.
find a show with identical name to one of the shows in your collection,
mark episode from that duplicate show as watched,
ensure that episode with same number isn't watched in local collection,
perform sync,
observe your local episode to suddenly become watched 🙄
Context
I've been experience wrongful scrobbles between shows with identical names (Doctor Who 1963 <-> Doctor Who 2005, The Office (US) <-> The Office (UK)) within following flow:
you have some time ago watched "show A", scrobbled it and it's no longer in your local collection,
you have "show B" in your local collection,
you have enabled by default option scrobble_fallback,
after sync you suddenly have scrobbles within "show B" both in local db and in trakt,
even if you manually unscrobble it— it'll come back during next sync.
Basically, what happens within ☝️ flow is:
this script downloads all the watched shows you have,
it construct then different "difference sets", like "updates to send from local db to trakt", "updates to apply to local db from trakt",
when it's constructing "updates to apply to local db from trakt", if you have scrobble_fallback option enabled:
script fails to find local copy of "show A", so it fallsback to "title + year" search, and after this to just "title" search, and therefore matches "show B" which shares same title,
It warrants to update local db with scrobbles from "show A" being transffered to "show B",
and after this, when "updates to send to trakt" is being constructed, script sees all these new scrobbles on "show B" and diligently sends them to trakt
this took me a while to figure out and was driving me crazy
Your Environment
Don't think it matters 🤷
The text was updated successfully, but these errors were encountered:
Hey!
Not sure whether it's expected behaviour (because everyone is fine with current implementation) or not, but
when synchronisation happens, this script fetches all the "watched" entries from trakt, which is IMO not great:
Expected Behavior
Current Behavior
scrobble_fallback
option (which is enabled by default)Possible Solution
I see no reason to fetch all the watched entries, perhaps just fetching data for shows/movies that are present in local db.
I briefly glanced over trakt API and it doesn't seem like there's a way to fetch only entries with given ids (AFAIU there's only "fetch by id" for single entry), which is probably a blocker for this suggested solution (and maybe there are other reasons to fetch everything?)
Other approach could be to forbid matching of local show that was already matched to remote show A, to a different show B.
Steps to Reproduce (for bugs)
See example below.
Context
I've been experience wrongful scrobbles between shows with identical names (Doctor Who 1963 <-> Doctor Who 2005, The Office (US) <-> The Office (UK)) within following flow:
scrobble_fallback
,Basically, what happens within ☝️ flow is:
scrobble_fallback
option enabled:this took me a while to figure out and was driving me crazy
Your Environment
Don't think it matters 🤷
The text was updated successfully, but these errors were encountered: