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

Include ProviderIds in /sync/watched/ #363

Open
ginjaninja1 opened this issue Aug 7, 2022 · 6 comments
Open

Include ProviderIds in /sync/watched/ #363

ginjaninja1 opened this issue Aug 7, 2022 · 6 comments
Labels
Question Help requested

Comments

@ginjaninja1
Copy link

might it be possible to include the providerids (tvdb in particular) for episodes in the response. So that when the index on trakt does not match the index on the application it is still possible to map watched events to episodes with same providerids. The need is particularly prevalent on specials eg https://trakt.tv/shows/crazy-ex-girlfriend/seasons/0/episodes/2 does not agree with the index on tvdb (and my app) but does agree with the tvdbid.

thanks for considering
this is a feature request but havent worked out how to specify that (yet)

@rectifyer
Copy link
Contributor

The various IDs are included in method such as https://trakt.docs.apiary.io/#reference/episodes/summary/get-a-single-episode-for-a-show and several other methods as well.

@rectifyer rectifyer added the Question Help requested label Aug 7, 2022
@ginjaninja1
Copy link
Author

The various IDs are included in method such as https://trakt.docs.apiary.io/#reference/episodes/summary/get-a-single-episode-for-a-show and several other methods as well.

thanks, is there an endpoint suited to reading a users a Entire watched history which includes episode tvdbids?
am i right to say with
https://api.trakt.tv/sync/history/episode?start_at=1980-06-01T00%3A00%3A00.000Z&end_at=2022-07-01T23%3A59%3A59.000Z (from the apiary example)
is not expected to work (across ALL episodes and ALL time)..(i havent made it work yet)

@tysonkerridge
Copy link

You may be using the wrong type in /users/:id/history/:type
eg. GET https://api.trakt.tv/users/me/history/episodes should return all the auth user's episodes, paginated. These episode objects would include the tvdb ID.

@ginjaninja1
Copy link
Author

You may be using the wrong type in /users/:id/history/:type eg. GET https://api.trakt.tv/users/me/history/episodes should return all the auth user's episodes, paginated. These episode objects would include the tvdb ID.

thank you..thats working for me and providing the info as you say. but i dont think its efficient for a full sync of a users watched status on epsiodes...not least because every instance of a watched action is communicated.rather than a single watched for each index.

so undeterred i used what you showed about /users and tried https://api.trakt.tv/users/me/watched/episodes. This showed the episodes and ids but not the show the episode belonged to
plays : 8 last_watched_at : 27/07/2019 23:46:42 last_updated_at : 27/07/2019 23:46:42 episode : @{season=1; number=14; title=Law and Disorder in Lagos; ids=}

so i tried https://api.trakt.tv/users/me/watched/shows and that provides the show and the episode indexes but not the tvdbids.

so it maybe that i will have to iterate through each individual known show to get an efficient watched list with ids for a known show? (if you havent guessed yet im very unfamiliar with trakt api so appreciate all the pointers i can get)

to a ley man it doesnt an unreasonable feature request to get the episode providerids added to the /watched endpoint[s]?

@tysonkerridge
Copy link

Yeah your suggestion of a way to get episode ids from the /watched/shows endpoint may be the way around those issues though still doesn't really solve the inefficiency either, I imagine.

@Zippy79
Copy link

Zippy79 commented Jan 13, 2023

Are there currently any plans to add episode ids to /watched/shows?

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

No branches or pull requests

4 participants