[Feature Request] Trakt Auth To retrieve custom lists

[starman2908]

Hiya,

KUDOS!!!

Absolutely love the new feature of the TMDB helper add-on. It works really well and hopefully will negate the use of extended info and beta skin helper service. I was wondering about the possibility of integrating Trakt, allowing for the authentication and retrieval of user watchlist and custom created lists.

There's a plethora of third party (questionably legal addons) that have integrated Trakt authentication and could probably have their code 'borrowed' lol. But it would be great to see a legit addon integration, even if it is only a link to search local library like that already exists in the TMDB addon online info dialogs.

Thanks for your consideration and all the time you spend on AZ2, it is really appreciated.

[jurialmunkey]

The issue with trakt is that it doesn't return images. So having images requires abusing another API and making a request for every single item in the list. I would like to respect other APIs and not abuse them.

[drinfernoo]

You could use the Trakt API just to retrieve the list, and then poll TMDb's API for the actual metadata/artwork on each item. That's how most video add-ons typically do it, from what I understand.

[starman2908]

Ah that makes sense... i thought it could be accessed on per user basis via authentication with the pull being user dependant on subscription. Thanks for looking into it.... the TMDB helper with AZ2 is fantastic and more than enough!!

[drinfernoo]

Another really cool side effect of this would be to possibly be able to manage Trakt content from the information dialog 👌

[jurialmunkey]

You could use the Trakt API just to retrieve the list, and then poll TMDb's API for the actual metadata/artwork on each item. That's how most video add-ons typically do it, from what I understand.

Yeah that's a request per every single item in the list. That's a massive amount of requests. One list of only 25 items = 25 requests. Currently I make one request for the whole TMDB list. Requesting for every single item would exponentially increase the number of requests that my API key is making. Considering that TMDb is already struggling with traffic, I would like to respect their API as much as possible so that they continue to exist.

[jurialmunkey]

Ah that makes sense... i thought it could be accessed on per user basis via authentication with the pull being user dependant on subscription. Thanks for looking into it.... the TMDB helper with AZ2 is fantastic and more than enough!!

Yeah for the initial trakt list it would be user based authentication. However, the trakt api doesn't return images so I need to use another api to get the images.

[drinfernoo]

At the risk of sounding insensitive regarding TMDb's recent server issues, basically every third party Kodi add-on functions as I mentioned previously, and I can only remember one or two times when TMDb couldn't handle the load. They deliberately throttle requests when they go over a certain threshold... and some add-ons definitely cross that threshold, depending on the way the user has them set up, but TMDb stays strong.

I don't think that using the API in a similar way would be "abusing" it, and at the very least, it likely wouldn't hurt them very much.

[jurialmunkey]

Increased hosting costs due to traffic from 3rd party kodi add-ons was a big part in why Trakt stopped exposing image paths via its API in the first place. Also, keep in mind that I also do look-ups to OMDb API, which is nowhere near as resilient as TMDb.

Regardless, my main issue is the way that my plugin is designed to be used by skinners. With a 3rd party streaming addon, requests are limited to a per directory basis. New requests are only made when the user browses to a new node in the directory tree. Even if the streaming addon is used in multiple widgets, those requests quickly becoming cached, thereby avoiding additional requests.

However, some features of my TMDb plugin are designed to provide additional lists based upon the currently focused item. For instance, in the library, the skinner might use my plugin to show an additional list of all the crew members in a movie. These lists can also be stacked (e.g. all movies that the focused crew member worked on and similar movies to the first movie in that list etc.).

So in my plugin, a new request for crew members will be made every time the user scrolls to a new item in the library. If there are four stacked lists, then that is four requests per item. HOWEVER, if it start also doing requests for each item in each list then that number gets massive very quickly. As a conservative estimate, lets say there are 25 items in each list on average. That's 104 requests PER ITEM that the user scrolls to. If the user then scrolls quickly through the library, you would suddenly have a flood of many thousands of requests in a matter of seconds.

To prevent getting throttled or even blocked completely, I add a rate limiter to online requests. MY default API key is heavily restricted to one request per 2 seconds, but if the user puts in their own key the rate limiting is set to one request per 0.2 seconds (i.e. x10 increase in request frequency). So even with a user api key, those 4 lists per item will take 21 seconds to load - that's a long wait, and with the default key it will be 3.5 mins.

The alternative is I remove my rate limiting and quickly get my API key disabled as happened with SkinHelper. The only way for skinhelper to exist with an included default API key was for marcelveldt to implement such heavy rate limiting. My rate limiting is not as heavy as skin helper, and I'd like to keep it that way.

[jurialmunkey]

@starman2908 @drinfernoo - I've ended up changing my mind on this matter and I've now added support for trakt lists with basic info look-ups from TMDb api.

I'm testing it out provisionally, so for now it will just be the github version. Once I've done more testing and I'm satisfied it isn't going to completely blow-out the number of requests to TMDb, then I'll submit the changes to official repo too.

You'll need script.module.trakt for this new version -- its also a dependency of the official trakt addon, so if you've installed that then you will have the module too.

EDIT: I'm re-opening this issue for further discussion/bugs/issues/suggestions regarding trakt support.