Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronisation is fetching information from trakt about shows/movies that are absent in local db #656

Open
MPogoda opened this issue Aug 21, 2024 · 0 comments

Comments

@MPogoda
Copy link

MPogoda commented Aug 21, 2024

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,
  • it opens door for behaviours like Show not synching correctly to Trakt #601

Expected Behavior

  • 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 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant