SchedulesDirect: JF 10.10.5 ignoring response when requesting images

[rkulagow]

[I'm the developer that manages the JSON service on SchedulesDirect.]

A trial user may download 10 images in a day.

A subscriber may download 5000 images in a day.

There are two codes that we provide when a client makes a request that would indicate that they have maxed out the number of images that can be downloaded.

code 5002: "Maximum image downloads reached. Counter resets every 24h. Post message to http://forums.schedulesdirect.org/viewforum.php?f=6"
code 5003: "Maximum image downloads for trial user reached. Counter resets every 24h. Post message to http://forums.schedulesdirect.org/viewforum.php?f=6"

JF 10.10.5 is ignoring the response codes and continues making the same requests for images over and over again, at a rate of 200-400 requests per second per user.

If a developer can contact me, I can coordinate with you to have your requests go to a debug server for testing of any code fixes.

[Shadowghost]

Hey, thank you for raising the issue!
When I implemented the initial "fix" it seems like I did a wrong assumption on how the pre-fetch works which is now causing these excessive amouts of requests (this should only happen once at the beginning and after that only fetch new entries).
Since I do not have any LiveTV setup myself I was and am flying somewhat blind in testing changes properly. I've pulled up https://github.com/jellyfin/jellyfin/pull/13469 which should a) lessen the amount of requests siginificantly by only fetching for updated and new EPG entries b) recognizing updated and new entries more reliably. I have some people on the team at hand which can test it, but it depends on their availability.

Implementing handling of custom response codes will require more changes which are out of scope for that PR (see the initial fix for what we'd need to change to properly fix these kind of limitations).

[rkulagow]

Hey, thank you for raising the issue!
When I implemented the initial "fix" it seems like I did a wrong assumption on how the pre-fetch works which is now causing these excessive amouts of requests (this should only happen once at the beginning and after that only fetch new entries).
Since I do not have any LiveTV setup myself I was and am flying somewhat blind in testing changes properly. I've pulled up https://github.com/jellyfin/jellyfin/pull/13469 which should a) lessen the amount of requests siginificantly by only fetching for updated and new EPG entries b) recognizing updated and new entries more reliably. I have some people on the team at hand which can test it, but it depends on their availability.

Implementing handling of custom response codes will require more changes which are out of scope for that PR (see the initial fix for what we'd need to change to properly fix these kind of limitations).

Please send me a private message, and we can coordinate on any testing you want to perform. Our debug servers have more logging and relaxed restrictions.

[Shadowghost]

@rkulagow sorry, currently a bit busy. We released a new version with the aforementioned PR merged, is the load decreasing? If not I actually need to find some time to create a proper LiveTV setup.

[rkulagow]

Users that are on 10.10.6 are still getting blocked; we're sending back code 5002 / 5003 and JF is ignoring the "stop" message and keeps making download requests.

[myrddin]

This is impacting me. I find myself with some time on my hands. Happy to take a look if somebody can point me in the right direction (the schedules direct code in Jellyfin).

[myrddin]

@rkulagow why not use response code 429 with retry-after set to however long clients should back off for?

[mdastous]

This is still an ongoing issue...

Is there an official GitHub issue to track it?

[theguymadmax]

https://github.com/jellyfin/jellyfin/issues/13147