-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
[Plugin Disabled] Issue with spamming Trakt API #174
Comments
Is there a time window when you noticed the hammering start? |
It's somewhere in the vicinity of the end of August. It starts ramping up around 8/20. I am basing this guess on overall hits on the api endpoint and not specific to the Jellyfin api key, unfortunately. Can you give me a basic scrobble flow for the plugin? As we dig in, we're noticing more than just the Jellyfin plugin are hitting the scrobble/start endpoint more than once during a play. |
@rudf0rd While SenorSmartyPants has contributed to this repo, they're not on the team proper. I believe our server and plugin folks are aware of this issue atm, I'm not sure when they'll have a moment to comment on the flow. It's interesting to note if traffic ramps up as of Aug 20th. The last two releases of the plugin would have been Sep 2nd (version 20), and before that was May 28th (version 19). So nothing that directly lines up. |
That's true I'm not on the team proper, but I thought it was a good question to ask. And I was curious to see if the time lined up with any changes I might have contributed so I could help fixing them. Big Thanks to the JF and Trakt teams! |
Looks like events might be pushed at most every 10s? jellyfin-plugin-trakt/Trakt/Helpers/LibraryManagerEventsHelper.cs Lines 52 to 56 in 70a3c3a
But that probably also means it's updating playback position every 10s. |
I am not a Jellyfin team member nor on a trakt plugin team. Just trying to add my 2 cents here to try to help resolve this issue. Here it seems that this plugin is calling /scrobble/start endpoint with a currnet progress % every time the media progresses in playback (in my case every 6 seconds): jellyfin-plugin-trakt/Trakt/ServerMediator.cs Lines 363 to 368 in 70a3c3a
After reviewing my old logs I can see all the requests and the log messages. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This looks like an interesting log call to watch for when debugging, along with whatever follows jellyfin-plugin-trakt/Trakt/ServerMediator.cs Line 317 in 70a3c3a
|
My server which is still running Jellyfin 10.7.7 with Trakt plugin v12 seems to be behaving just fine (which makes sense, as this was released long before the issue started happening) Log from 10.7.7
|
Seems like I'm late to the party. I rewrote the syncing to actually do what it was intended to do.
I guess the latter point is where things are going wrong:
We are also sending a pause event instead of a stop event if a user interrupts playback before finishing the media: jellyfin-plugin-trakt/Trakt/ServerMediator.cs Line 495 in 1ed81ff
The 10 second timer mentioned earlier is for library events (addition/removal of media) and not for playback tracking. jellyfin-plugin-trakt/Trakt/Api/TraktApi.cs Line 292 in 70a3c3a
My guess is that something in the skip calculation (the 5 seconds mentioned earlier) is going wrong but I was quite sure I did test this to not happen - exactly because I didn't want to hammer the API... I will look into this more over the week but it may take some time. |
@Gylesie are you seeing |
@Shadowghost Just to make sure I'm understanding, the scrobble event is intentionally sent every 5s? If so, that can be removed and this would be fixed I think. We only require one start event to be sent. Apologies if I misunderstood! |
@rudford Since I handle all our API keys and 3rd party accounts, I figure I should ask this: I don't see a way to generate a new ID/Secret from the Applications page. Is there a way we can arrange this? |
As I understand it, the intent is to send an explicit update if the playback position jumps more than 5s (user skipped a section, the intro/credits or some such). It's possible the logic around this isn't 100% sane, but it could also be possible that the server isn't getting the position updates from the client often enough not to trigger the skip detection (I haven't completely wrapped my head around this code yet) |
It should only be sent if the difference between the saved and the event runtimeticks is more than 5 seconds. From taking a quick look on how those events are fired from the Jellyfin side it seems like it depends on how frequent the clients send the update event. So increasing the buffer to like 10 or 15 seconds might solve it. |
@Shadowghost I see! So this is strictly to be accurate on the progress indicator on Trakt. If it makes sense to you, maybe 60s would be better? I don't know the architecture like you do, but it seems to me that the need for that kind of accuracy doesn't match the impact it can have on the API. Of course I'm being overprotective of the API resources :D @anthonylavado I was thinking the same. If it's cool with you, I can regenerate the API key and you can grab it off your app settings. |
@rudf0rd re:API Key - Sounds good. Re: updating progress - we're currently exploring how this is working across all our different clients. We'll sort something out soon. |
@anthonylavado updated |
Yes, exactly, even though the playback was continuous. As @Shadowghost pointed out, maybe the client is too slow with the update events. In this particular case it was the Jellyfin Media Player client. Logs:
There were no skips. |
Progress intervals of some of our apps (sourced from our Matrix chat):
#175 will compare the timestamp difference of the events to the difference between runtime ticks to check for skips (min. 15 seconds). |
@rudf0rd I see we got a new Client ID, but not a new Client Secret. Was that intentional? Our auth tests are currently failing. |
Apologies. Forgot to approve the app. Should be good now.
|
I ended up creating a fork to mitigate the rate limit issues. You can find it here this will be updates from time to time.the only difference is that it has my own creds |
Would it be worth allowing people to provide their own API keys to avoid this in the future? |
I don't think it's a good idea. If another issue appears with the code, there will be a lot of keys out there, and Trakt won't be able to invalidate them all easily. |
None of the proposed solutions would fix the underlying problem. The fork @zaourzag created only changes the keys. While this would allow the forked plugin to work if Trakt disabled the Jellyfin key again, it wouldn't fix the problem that the plugin is hammering the Trakt API. |
What hammering are you talking about? This issue was fixed 11 days ago on version 21. |
It is fixed now. But if there would still be a problem, the fork or allowing people to provide their own keys would do absolutely nothing. |
Note: This was fixed in v21 of the plugin, available for Jellyfin 10.8.5+
Original message:
Hey we've been tracking an issue on our API that an app is hammering the scrobble/start endpoint and concluded it's the Jellyfin plugin. We just revoked the Jellyfin API key and everything leveled out on the servers.
Can you guys help explain what's going on with the high frequency of scrobble/start calls? Please let us know how we can help get your plugin back online.
The text was updated successfully, but these errors were encountered: