mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Schedules Direct Guide Data No Longer Working - Country/Regions listed as "Undefined" in the setup guide is broken. #6539
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @junobomb on GitHub (Dec 3, 2024).
This issue respects the following points:
Description of the bug
<html>SchedulesDirect: request that a Jellyfin developer contact me
Junior Member
Posts:1
Threads:1
Joined:2024 Dec
Reputation:0
Country:United States
#1Yesterday, 08:58 PM
Hi -
I'm the developer that created and manage the JSON service at SchedulesDirect. Can someone from Jellyfin please contact me regarding an issue between the Jellyfin client and the SchedulesDirect service?
I can be reached at rkulagow @ schedulesdirect.org
Thanks.
Reproduction steps
Schedules Direct - program data is broken and all of the Country/Regions are "Undefined"
What is the current bug behavior?
"Underfined" Coutry Region under Schedules Direct guide setup as well as no guide data.
What is the expected correct behavior?
Guide Data
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.10.3
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@junobomb commented on GitHub (Dec 3, 2024):
https://forum.jellyfin.org/t-schedulesdirect-request-that-a-jellyfin-developer-contact-me
@joshjones1980 commented on GitHub (Dec 3, 2024):
Thank you for posting this, Junobomb; I came here to do the same.
Obviously, I too am experiencing this issue.
@anthonylavado commented on GitHub (Dec 3, 2024):
We responded on the forum thread, we're aware and are looking into it.
@rkulagowski commented on GitHub (Dec 4, 2024):
(I'm the SchedulesDirect JSON developer.)
It appears that something within Jellyfin is caching old tokens, and then presenting them, even after the token has expired. That trips our fraud system, and therefore is blocking Jellyfin users.
Here's what an example log looks like:
|2024-12-01T05:19:18Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:18Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:18Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:19Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:22Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:22Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:22Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:22Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:22Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:27Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:27Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:27Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:28Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:29Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:34Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:34Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:34Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:34Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
|2024-12-01T05:19:34Z|check_for_valid_token(24.3.175.118):client sent old token.|token:0fe0a83c70b5f4971ce87990bc12a7d8
(etc)
So multiple times per second, this particular IP address was connecting to the service with a stale token.
If I lookup that 0fe0.... token, it was issued to a user on: 2024-11-23 05:04:02
However, when I check the current token which that user has been granted, it was generated on 2024-12-01 05:04:02
Something inside of Jellyfin is presenting old tokens, and because those tokens aren't current, the requests are getting rejected and that causes the account lock out.
In addition, when Jellyfin presents the old token, the response from our API is an error, code 4003: "Invalid username or token has expired." But it looks like Jellyfin is ignoring that error; when it gets code 4003 Jellyfin should request a new token and then use it.
If there's multiple processes involved in a Jellyfin system (grabbing images? refreshing celebrity data?), at least one of them seems to not realize that the token has been rotated; a token is only valid for 24 hours or until a new token is requested.
The above is just a single user; our fraud detectors are seeing this for over 500 Jellyfin clients, so it's 1000's of requests per second.
@socphoenix commented on GitHub (Dec 4, 2024):
Rkulagowski, were you seeing this before the most recent update? I tried rolling back the most recent upgrade before this GitHub issue went live and it didn’t fix the failure to pull data from schedules direct.
@greyspace07 commented on GitHub (Dec 4, 2024):
socphoenix, did you check the Jellyfin log after you rolled back for any reference to schedulesdirect token? The error in my log has changed from a bad token (deadbeef) and looks to be pointing to my SD account being disabled/locked. I tried to pull an XMLTV file from SD as a workaround until this issue is fixed, but got rejected. I think JF is causing all of our SD accounts to get disabled. Just a thought... I deleted my LiveTV schedules config and hope my account resets after a period.
@b3p3k0 commented on GitHub (Dec 4, 2024):
I am still using JFin 10.9.11 and I am experiencing the same issue. I haven't upgraded at all (so no rollback). I've experienced the same outage for about two days.
@b3p3k0 commented on GitHub (Dec 4, 2024):
I'm not the person you asked, but I found this thread while troubleshooting a s imilar issue. These are the most recent logs I have, hope they help shed some light for tohers:
[2024-12-04 12:34:34.182 +00:00] [ERR] Error adding metadata
System.ArgumentNullException: Value cannot be null. (Parameter 'listingsId')
at System.ArgumentNullException.Throw(String paramName)
at System.ArgumentNullException.ThrowIfNull(Object argument, String paramName)
at System.ArgumentException.ThrowNullOrEmptyException(String argument, String paramName)
at Jellyfin.LiveTv.Listings.SchedulesDirect.GetChannels(ListingsProviderInfo info, CancellationToken cancellationToken)
at Jellyfin.LiveTv.Listings.ListingsManager.GetEpgChannels(IListingsProvider provider, ListingsProviderInfo info, Boolean enableCache, CancellationToken cancellationToken)
at Jellyfin.LiveTv.Listings.ListingsManager.AddMetadata(IListingsProvider provider, ListingsProviderInfo info, IEnumerable
1 tunerChannels, Boolean enableCache, CancellationToken cancellationToken) at Jellyfin.LiveTv.Listings.ListingsManager.AddProviderMetadata(IList1 channels, Boolean enableCache, CancellationToken cancellationToken)EDIT TO ADD: with regard to JFin causing accounts to be loced at SD: I am able to log in to the SD webpage and my status shows as "active", so I am not sure if that is the cause. Far from an expert but happy to help with logs or testing.
@davew723 commented on GitHub (Dec 4, 2024):
I'm observing the same issue with 10.10.3. I also confirmed my schedules direct account if valid. All country codes in jellyfin settings are also listed as undefined. The root of my problem looks to be this...
... Interesting that it reporting my token as CAFEDEADBEEF. That seems like some debug value not the real SHA1 token. I haven't had much time to dig into the problem this morning. I do see that string in the Jellyfin test code but I don't really see it in the normal code paths. So I'm assuming the SD service is returning this instead of the token we provided. Of JF is passing something really bad.
@greyspace07 commented on GitHub (Dec 4, 2024):
Yep, I'm seeing/seen exactly what you both sent. Initially, I was seeing the classic fake-hex DEADBEEF token and now the cancellation token error. Interesting that this stopped working for some users who haven't upgraded in the last few weeks, if I'm reading that correctly.
I also see my SD account as active, and I found a test URL in a support page for SD which behaved as though I'm not blocked. But I'm getting a 4005 account disabled back from SD when I try to pull an XMLTV file. If that helps anyone with a lot more skills than I have.
@jeff-gooch commented on GitHub (Dec 4, 2024):
I can confirm that the account block is with SD, as attempting to connect via EPG123 instead of JF produces a failed login message with the same ACCOUNT_DISABLED error.
@socphoenix commented on GitHub (Dec 4, 2024):
I hadn’t, but looking at the log file for the first attempted refresh after rollback I also see a cancellation token:
My web account shows active so it appears schedule direct disabled Jellyfin pulling data at the moment. I deleted the schedules direct accounts from Jellyfin for now, hopefully that will be enough to undo the cancellation token once this is fixed.
@b3p3k0 commented on GitHub (Dec 4, 2024):
It appears that SD is aware of the issue, I received this response earlier:
There is an issue with how Jellyfin is interacting with the Schedules Direct service; I've asked that a Jellyfin developer contact me:
https://forum.jellyfin.org/t-schedulesdirect-request-that-a-jellyfin-developer-contact-me
Our system is disabling accounts that are using the Jellyfin client in order to keep the service operational for everyone else. If you provide your IP address then I can remove the block as long as you're using something other than Jellyfin, but if your Jellyfin client connects then it's just going to cause the same condition that is triggering the block.
@nandarray commented on GitHub (Dec 4, 2024):
I deleted SchedulesDirect from the TV Guide data provider section in JellyFin and removed all "refresh guide" triggers from scheduled tasks; then let it sit for 24 hours. I re-added SchedulesDirect the next day and it's working for me now. I think this was just long enough for the locked out account to reset. I wish I still had the log file, but I'm pretty sure I saw where it was Precaching images, the URL had a "?token=" tacked on to the end of it with a token that was different that the one it just got (shown earlier in the log file next to the phrase "Authenticated with Schedules direct". ) Maybe it's using an old token stored with image url?
@greyspace07 commented on GitHub (Dec 5, 2024):
That's very interesting, nandarray. I removed my SD config from JF last last night and will try re-adding tomorrow. I wonder what would cause caching of old tokens across multiple versions and roughly the same time and then seemingly stop doing it. I'm by no means a dev, but my type-A curiosity needs a dumbed-down answer.
@rmeden commented on GitHub (Dec 5, 2024):
I deal with the old DataDirect service and account stuff at SD and I can explain this.
Both SD-DD and SD-JSON query the main webserver for authentication. The main SD web page doesn't have a concept of blocking. That must be something unique to the SD-JSON service. The /getdata URL predates SD-JSON so it uses the SD-DD service to return "what's on now" in the DataDirect XML format.
There are multiple XMLTV grabbers, tv_grab_na_dd uses the SD-DD service so can provide data for US/Canada in XMLTV format. (although it's missing things like images and is only updated once a day).
Hope that explains things. Glad to see progress is being made to solve this!
RobertE
@treddy73 commented on GitHub (Dec 5, 2024):
I'm not a C# developer, but I'm wondering if this bit of code in
SchedulesDirect.csis the culprit:My Jellyfin logs are showing a
Forbiddenresponse ... not aBadRequest... I feel like any 4xx error should just clear the_tokensregardless. Thoughts?@PrplHaz4 commented on GitHub (Dec 5, 2024):
That looks to be what EPG123 is doing:
https://github.com/garyan2/epg123/blob/master/src/GaRyan2.SchedulesDirect/SchedulesDirectApi.cs#L25
If the old token is persisted in image URLs, and never updated, it will prob keep triggering the deactivation though..
@rmeden commented on GitHub (Dec 5, 2024):
@rkulagowski can probably speak to this better, but one thing you may want to add is an exponential back-off on errors. I think the reason why @rkulagowski needed to add the block was because of the instant retries causing server problems.
@ajb142 commented on GitHub (Dec 8, 2024):
For anyone coming here, looking for a quick fix, I thought I would share my work around:
I run Jellyfin in a container, on a linux system.
I created a new ubuntu image and installed
nginxas well asxmltv-utilGet a shell session to this new container and run
tv_grab_zz_sdjson --configureand follow the stepsRun
tv_grab_zz_sdjson --output /var/www/html/tvxml.xmlYou should now be able to access the xml file via http
In Jelyfin, configure a new XML provider and use the url tested in the last step.
And Walla! Setting up a cron job to update the schedule once a day is probably a good idea, or do it manually if you wish.
full docker file below:
This could be done without docker and I can confirm it works just fine.
I am slammed at the moment but if I find the time to turn this into a proper image I will come back and update this thread
@jimevt commented on GitHub (Dec 9, 2024):
I am running a Windows based jellyfin server and am seeing the same issue.
I tried deleting Schedules Direct and adding it again after 24 hours, but I'm still seeing the same issue.\
Is there any data I can collect to assist in debugging this issue?
Thanks!
JimE.
@ajb142 commented on GitHub (Dec 9, 2024):
It sounds like epg123 is the quick fix for windows for those who need something fast.
I found the tvxml format works better in Jellyfin.
Not tried myself but have heard others having success.
@johnpc commented on GitHub (Dec 10, 2024):
confirmed @ajb142's workaround fixed it for me
@rmeden commented on GitHub (Dec 10, 2024):
BTW.. if you want a command line solution on windows XMLTV has a windows executable that can run tv_grab_zz_sdjson and tv_grab_zz_sdjson_sqlite Personally, I find that easier than using EPG123 just to generate an XMLTV file.
@greyspace07 commented on GitHub (Dec 10, 2024):
Like @nandarray , I removed my SD configuration completely and didn't try to access my account for more than 24 hours. Initially, this did not work, and I continued to use the XMLTV file. I waited another 48 hours or so without any attempt to access my SD account. This morning I was pleasantly surprised that when I added my SD config back into Live TV the countries were there. I removed the XML config and let JF rebuild the schedule with the JSON info. My scheduled recordings also rebuilt (expected, but still nice).
I guess I'll wait and see if JF causes my SD account to get disabled again.
@bobhruska commented on GitHub (Dec 10, 2024):
Another data point here. I was having the same issue last week. I deleted my schedules direct entry in the jellyfin guide and decided to wait for a fix.
After reading here today that someone got it working after having it deleted for 24+ hours, I decided to try again. It works! Mine was deleted for much longer than 24 hours, more like 4-5 days.
@kpfleming commented on GitHub (Dec 10, 2024):
OK, even more bizarre... I did nothing at all, and my schedule is populated again.
@sean-gray commented on GitHub (Dec 10, 2024):
yeah looks like it started working again
@rmeden commented on GitHub (Dec 11, 2024):
In an email with RobertK yesterday about giving me access to remove blocks (I respond to the main SD support email), he mentioned the current block was longer than the 1 day I expected, but he was going to remove them all. They will automatically be recreated when I think there are 5000 login failures from an IP. (that's the symptom we see on the SD side). Based on this thread, I think the root cause is authentication tokens stored in image URLs.
@BSmith7760 commented on GitHub (Dec 11, 2024):
I added SD Direct last night and it worked fine. This morning I deleted SD Direct, and I tried to add it again, and it had nothing in the Lineup...
@BSmith7760 commented on GitHub (Dec 11, 2024):
Now it is fixed...
@belfour commented on GitHub (Dec 13, 2024):
Hi,
I found this thread after it stopped working for me today. I logged in to SD 7 days ago and selected country, zip, and lineup without issue. TV worked fine throughout the weekend. I didn't look at Monday until now . All I get is undefined for the country list. I'll wait 48 hours and see what happens.
@redaters commented on GitHub (Dec 13, 2024):
While my account started working again a few days ago, as of this morning it has locked again. The Jellyfin logs say:
Account has been disabled. Please contact Schedules Direct support: service@schedulesdirect.org for more information.
@BSmith7760 commented on GitHub (Dec 13, 2024):
I have both SD Direct and XMLTV via epg123 for just this situation...
@rmeden commented on GitHub (Dec 13, 2024):
That means you're still using Jellyfin to talk to SD and had over 5000 login failures. (what we consider a DDOS attack). Until a dev fixes JellyFin, you really need to use something else.
@dathbe commented on GitHub (Dec 22, 2024):
Schedules Direct is suggesting that we switch (at least temporarily) to SD-DD XMLTV source. If I'm looking at it correctly, that requires me to download the schedule in an xml file to my computer...does anyone know how I would do that? There does not seem to be an option to do this in my SD account.
To answer my own question, I found this https://github.com/XMLTV/xmltv
@b3p3k0 commented on GitHub (Dec 22, 2024):
dathbe, I have been using the following since these issues began:
in /etc/crontab:
00 01 * * * kevin tv_grab_na_dd >/opt/SchedulesDirect/lineup.xmlThen in Jellyfin settings, just add the local path to lineup.xml:
Also make sure you add a lineup beforehand.
@dathbe commented on GitHub (Dec 22, 2024):
Thanks. Interestingly, Schedules Direct support's first recommendation is moving entirely away from Schedules Direct:
@Dleewee commented on GitHub (Dec 22, 2024):
This comment from 2 weeks ago provides a solid workaround: https://github.com/jellyfin/jellyfin/issues/13147#issuecomment-2526231828
You don't have to use Docker. For instance I used the same steps to set up a LXC on Proxmox and it's working great.
@dathbe commented on GitHub (Dec 22, 2024):
That's basically what I've done, except I'm using
'tv_grab_na_dd --days 10 --output /path/file.xml'And I'm not using the web server since the file is being saved to the device that runs Jellyfin. I haven't read enough about XMLTV to know what the difference is between
tv_grab_na_ddandtv_grab_zz_sdjson. I gather "na" is regional (North America).Edit: looks like the different commands are purely regional - https://github.com/XMLTV/xmltv/blob/master/doc/QuickStartI misread the docs. There is some regionality to the files, but both
tv_grab_na_ddandtv_grab_zz_sdjsonwork in the US. There's a difference between the data when you use Schedule Direct's DD format and SDJSON format.Edit 2:
There are some issues with the
tv_grab_na_ddcommand, as described in this post. I have started using the following command instead, which seems to work better:tv_grab_zz_sdjson --days 10 --output /path/file.xmlI've found that I have to remap my channels for some reason, and I also had to reschedule my series recordings. But at least those are one-time issues.
@Pfuenzle commented on GitHub (Dec 23, 2024):
Do you have EPG Images for the series when using the xmltv command? Or is it only for the pure EPG?
@dathbe commented on GitHub (Dec 23, 2024):
There are no images downloaded with my command above. Do you really download images for every show on every channel for two weeks? I'm reasonably certain I was not downloading that many images before I switch to XMLTV.
@Pfuenzle commented on GitHub (Dec 23, 2024):
I don't, currently I'm using Guide2Go to get the xmltv from Schedules Direct and it doesn't support images from what I know, and I thought the Jellyfin Schedules Direct implementation also doesn't pull images since it didn't work when I tried it a few years ago and I saw some issues that it has been broken for some time. But I only have ~10 channels my family likes to watch, so I wouldn't mind downloading the images for it.
@noixaaxion commented on GitHub (Dec 24, 2024):
Non-coder here but I think the bug may be introduced in this commit:
06923cbf2b (diff-066646fcd1a65d06583a1b0bda9860399fe80fee7325e341472b1670a943617c)Line 80 in src/Jellyfin.LiveTv/Channels/RefreshChannelsScheduledTask.cs should be:
new TaskTriggerInfoTypeand Line 67 in src/Jellyfin.LiveTv/Guide/RefreshGuideScheduledTask.cs should have the same change.
There are a few more similar changes in that commit that need the same fix, if this is indeed the problem.
Again I am sorry I don’t have the tooling setup to actually make the change and test it.
@fishcharlie commented on GitHub (Dec 25, 2024):
Maybe @LePips should look at that? https://github.com/jellyfin/jellyfin/issues/13147#issuecomment-2561374049
@LePips commented on GitHub (Dec 25, 2024):
That is incorrect, as
newis for constructing objects and these areenums.@mattvisa commented on GitHub (Dec 29, 2024):
I'm having the same issue after updating TrueNAS to latest version and Jellyfin to latest version available. Schedules direct stopped working after upgrade but was working fine before.
@EFFXCT290 commented on GitHub (Dec 30, 2024):
Same but im on a ubuntu vps oracle cloud using docker and portainer
@felix920506 commented on GitHub (Dec 30, 2024):
please stop confirming in the comments to avoid clutter. We already confirmed the issue.
@hearts1137 commented on GitHub (Jan 5, 2025):
I was able to pull down guide data from schedules direct for a short time but now I am back to
When is a fix going to be released? I guess I don't understand why this is taking so long. Schedules Direct is a paid service, roll back the change that broke the subscription and work on the permanent fix? Seems to be the way DevOps works; everything is committed to code, tested, approved, merged into main, then released. Roll backs are not ideal but an available tool to use.
@JacobHenner commented on GitHub (Jan 5, 2025):
The issue was introduced in Jellyfin, not in Schedules Direct.
@ajb142 commented on GitHub (Jan 5, 2025):
This needs someone to fix the Jellyfin code. It is effectively DDOSing schedules direct and they don’t have the resource to handle the traffic being generated by all the Jellyfin clients out there.
Personally, I do not know enough about this area of the code to start digging confidently. I know C# and would be able to look but it’s a chunk of time I don’t have spare at the moment, and I am quite happy with the workaround I have shared above.
Schedules Direct are non-profit and are protecting their resources. Jellyfin is opensource so anyone can fix this.
All the posts on this thread stating “it’s working now” or “it worked for a while, then broke” are really not helpful anymore. We know the auth is going wrong. We know it’s DOSing schedules direct and their protection kicks in and bans your IP for a while.
Sorry if I come across grumpy but the truth is we need a hero with the time and knowledge to fix it. In the meantime, there are workarounds.
Kind Regards
Alex Brown
07708 939 764
From: Jacob Henner @.>
Sent: Sunday, January 5, 2025 3:07:15 PM
To: jellyfin/jellyfin @.>
Cc: Alex Brown @.>; Mention @.>
Subject: Re: [jellyfin/jellyfin] Schedules Direct Guide Data No Longer Working - Country/Regions listed as "Undefined" in the setup guide is broken. (Issue #13147)
Schedules Direct is a paid service, roll back the change that broke the subscription and work on the permanent fix?
The issue was introduced in Jellyfin, not in Schedules Direct.
—
Reply to this email directly, view it on GitHubhttps://github.com/jellyfin/jellyfin/issues/13147#issuecomment-2571656799, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHELBPJ24GCZCL6OBLIJZP32JFDCHAVCNFSM6AAAAABS4RFZMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGY2TMNZZHE.
You are receiving this because you were mentioned.Message ID: @.***>
@JacobHenner commented on GitHub (Jan 6, 2025):
If I understand correctly, the root cause is fixed by https://github.com/jellyfin/jellyfin/pull/13227, but a new release is required before the change is available to users (unless the users are running a custom pre-release build from the git repo).
@felix920506 commented on GitHub (Jan 6, 2025):
Closing as fixed by #13227
Will be out in next 10.10.z release
@hearts1137 commented on GitHub (Jan 7, 2025):
This issue should honestly stay open until a fix is released and verified. Users are unable to use a paid service due to a bug introduced by the Jellyfin team so I can't fathom why this is resolved when nobody can verify the fix solves the issue.
@skug67 commented on GitHub (Jan 7, 2025):
The details of whether an issue is marked open or closed seems relatively unimportant to me. But it does seem like if a fix has been incorporated into the code that it would be a good idea to prioritize/accelerate a bug-fix release so that users can benefit from it....
@johnpc commented on GitHub (Jan 8, 2025):
There's lots of reasons this wouldn't be rush released as there are a lot of other changed merged to main that still need to be stress tested before production release.
If you want to try this before it's released in 10.10.4, you can always switch to the
unstabletag:https://hub.docker.com/layers/jellyfin/jellyfin/unstable/images/sha256-50ff8fd6cac9945bf16440d3344632ef333c75c61017844598a1595c3d90e152
@marstr commented on GitHub (Jan 8, 2025):
@johnpc, do you happen to know the anticipated release date for v10.10.4? I imagine the answer is available elsewhere, but others finding this thread may have the same question.
@felix920506 commented on GitHub (Jan 8, 2025):
@marstr please do not ping random people in the thread. Your question is answered in our FAQ. https://jellyfin.org/docs/general/faq#when-will-release-x-happen-when-will-feature-x-be-available
@AndBurns commented on GitHub (Jan 19, 2025):
This is the kind of really unhelpful comment that generates ill-will. Jellyfin has become unusuable for more than a month for a large number of users. The JFin response is "we have fixed it but we wont tell you when we will roll out the fix". We do not have any suggestions for work arounds while you wait.
Translation: please find another project that meets your needs better.
@solidsnake1298 commented on GitHub (Jan 19, 2025):
Jellyfin is an all volunteer project. Zero full time or paid developers. Everything is "best effort" when the dev team has time outside of their actual jobs, families, and other responsibilities.
They understand the scale of the problem. But, at the end of the day, you are not entitled to their free time nor are you aware of what is actually happening behind the scenes. There could be other, unrelated, problems that are blocking a new release with the Schedules Direct fix.
@skug67 commented on GitHub (Jan 19, 2025):
IMO, the vitriol in each direction is quite unwarranted. I fully recognize that the project is run by volunteers and that they "owe" the user base exactly nothing. On the other hand, anger/outrage toward people who basically just want some hint as to when will this major/breaking issue be resolved seems like quite an overreaction.
@hearts1137 commented on GitHub (Jan 19, 2025):
It's not personal. This is a open source project we all love more than Plex. The fact that the devs introduced a major electronic program guide (EPG) breaking bug and didn't roll back the release is what we are discussing. It's a shame. To those that say we aren't owed volunteers hours and we get what we pay for you're absolutely right. Making a release roll back couldn't be easier on a platform like GitHub so in my opinion there is NO excuse to why this is still an ongoing issue.
I only use Jellyfin for the EPG so I can record my shows via rabbit ears. I have been unable to do that, coupled with a premium paid service like SchedulesDirect I can't utilize. Major let down to have this thread full of apologizers and meanies. Roll the release back and fix the bugs as you get time. We understand the constraints, time is precious. Put it back the way it was with the tools you are provided, please and thank you.
@johnpc commented on GitHub (Jan 19, 2025):
@hearts1137 Since jellyfin is self-hosted I think you can resolve this by rolling back your version to the last version that was working or rolling forward to
unstable. It might take a while to start working if you're still running the latest build, since SchedulesDirect will continue throwing 429 exceptions for a few hours, but once the SchedulesDirect recovers it should work well if you roll back your server.@jurgenhaas commented on GitHub (Jan 19, 2025):
What's all that fuzz? There are simple workarounds described above. Why do some have to create pressure?
@Shadowghost commented on GitHub (Jan 19, 2025):
Just as a heads up: This issue has nothing to do with something we changed in EPG handling, so rolling back would not fix it for anyone. SD is enforcing more strict rate limits and API key checks which makes our implementation break. Noone to blame, just bad timing and a shitty implementation on our side since SD support was implemented years ago.
@arazilsongweaver commented on GitHub (Jan 19, 2025):
Important Information Regarding The Current Status Of This Issue:
The current "unstable" builds of Jellyfin do not contain the fix. At this time, the fix is only applies to the "release-10.10.z" branch. (#13227) As far as I know, the "release-10.10.z" branch has to be built from source. (additional help)
Running an older version of Jellyfin will not resolve this issue. This issue stems from an October 2022 change to the Schedules Direct API that requires new code to fix.
Furthermore, it looks like the "unstable" branch development is currently on hold pending resolution of the library.db to jellyfin.db SQLite merge (#13047) so waiting for the fix on the "unstable" branch may take awhile. I would recommend staying away from "unstable" until they finish the database migration as that work has a high potential of leading to data loss and other severe issues.
@AndBurns commented on GitHub (Jan 19, 2025):
A quick effort at a Howto for a workaround on this problem.
The below is written for a unix system with python installed but should be fairly easily transferable to a Windows system with python installed. The only differences would be to use a batch file instead of a bash script and to use windows scheduler instead of cron.
The work around
As noted by others, JellyFin has the option to use xmltv schedules instead of schedules direct JSON format until the fix to JellyFin's problem is published. After some googling around I found that an XMLTV.xml file can be generated using the free zap2it.com web site and a python routine written by arantius and downloadable here here.
**NB: ** If you use the zap2it.com web site interactively, it will ask you to create a (free) account. As far as I can see you do not need one to use this work around.
Steps to take
python3 zap2xml.py -z xxxxxxwhere you replace xxxx with your zip code.
I did this under ubuntu by
a. Creating a bash script that executed the python script and then copied the xml file to the location where I wanted it on my system. I called it update.sh.
@BrickHardmeat commented on GitHub (Jan 20, 2025):
I suppose you can expect it to a certain degree with a site like github but this notion that there are "simple workarounds" probably only helps the tiny percentage of the Jellyfin user base that are technically proficient enough to actually do them.
I tried for days to get some kind of workaround going on my Synology NAS but ultimately had to give up and go back to Plex. I'm not stupid by any means (at least I don't think so..) but the level of "help" available for someone like me amounted to "Atta boy, you go get 'em champ!" to "Well why can't you compile XXX and run it in YYY container ?".
@jurgenhaas commented on GitHub (Jan 20, 2025):
@BrickHardmeat asking for help in such scenarios normally helps. The workaround I introduced with minimal effort was to install
xmltv(see https://github.com/XMLTV/xmltv?tab=readme-ov-file#installation-package) and then run the following command regularly (in my case with a cron) after configuration:The file
/datadisk/jellyfin/xmltv/data.xmlgets updated, and then I configured JellyFin to load the TV schedules from that file instead of from SD directly. It works so well, I will probably keep that workflow even if JellyFin eventually provides a bug fix.@felix920506 commented on GitHub (Jan 20, 2025):
We are planning for 10.10.4 in about a week which will contain the fix.
@rmeden commented on GitHub (Jan 20, 2025):
One of the problems with Open Source is poor documentation. Not only are devs not good at documentation (they know too much to document it for those that don't), it's not "fun" or satisfy their "itch to scratch" that keeps them developing. A major way non-devs can give back to a project... write Wiki articles or other documentation to help others.
@BrickHardmeat commented on GitHub (Jan 20, 2025):
And reading the posts you're replying to also helps. As I wrote, I was asking for help and if I wasn't getting an "atta boy!" I was getting replies assuming a level of technical knowledge I just didn't have which is kind of proven by your "minimal effort workaround".
@dathbe commented on GitHub (Jan 20, 2025):
I've found that the xmltv script is not as good at grabbing episode information as the built-in Jellyfin module was. Neither was perfect, but when it comes to not recording old episodes/episodes that are already recorded, the built-in method seemed to be more reliable.
@drorem commented on GitHub (Jan 22, 2025):
I downloaded v10.10.4 (released last night) and everything's looking good so far with SchedulesDirect. Thanks!!
@BrickHardmeat commented on GitHub (Jan 22, 2025):
I've sent off a request to Schedules Direct to clear any blocks on my account just in case. I'd only recently tried it as I thought I'd managed to install the unstable version but no such luck so it's good to know 10.10.4 looks like it's working well.
Thankyou Devs, your work, as always, is greatly appreciated.
@arazilsongweaver commented on GitHub (Jan 22, 2025):
My account was banned from previous testing attempts when I tried it again this morning. I will test out the new release once my account gets fixed up by Schedules Direct support. We should have final results in about 3-4 days after I get my account set up again on the Jellyfin side.
@timangus commented on GitHub (Jan 22, 2025):
Works now, having updated to 10.10.4 and submitted a support ticket to SD to get unblocked.
@shawnhaywood commented on GitHub (Jan 23, 2025):
I wonder if there are still some connection issues. I upgraded to 10.10.4, but still get the download error message. SD indicated that my IP was not blocked.
EDIT: It just started working! I did do one thing differently. When viewing the SD Live TV setup page, I didn't re-enter my SD password, but instead filled in the fields below and the "Select Listing" field populated with options. Not sure if this was just a coincidence.
@mattvisa commented on GitHub (Jan 23, 2025):
You may have to go in and refresh the connection, which is what I did and the data synced again. Forgive me if you've already done this.
From: shawnhaywood @.>
Sent: Wednesday, January 22, 2025 7:06:05 PM
To: jellyfin/jellyfin @.>
Cc: Matt Visaggio @.>; Comment @.>
Subject: Re: [jellyfin/jellyfin] Schedules Direct Guide Data No Longer Working - Country/Regions listed as "Undefined" in the setup guide is broken. (Issue #13147)
I wonder if there are still some connection issues. I upgraded to 10.10.4, but still get the download error message. SD indicated that my IP was not blocked.
—
Reply to this email directly, view it on GitHubhttps://github.com/jellyfin/jellyfin/issues/13147#issuecomment-2608524161, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A7DO2OXZY2WAOHZFZ7SJLVD2MAW63AVCNFSM6AAAAABS4RFZMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGUZDIMJWGE.
You are receiving this because you commented.Message ID: @.***>
@drorem commented on GitHub (Jan 23, 2025):
I downloaded v10.10.4 this morning (as I indicated earlier). I guess the acid test for me will be tomorrow sometime (24 hrs after I re-configured my SchedulesDirect account w/ jellyfin) when jellyfin refreshes my TV guide data. As I understand the issue previously, the tokens associated with SchedulesDirect's JSON API expire every 24 hrs and jellyfin needs to re-authenticate and use the new ones. The issue was Jellyfin kept using the old token for some? TV guide images. It retried using the old token repeatedly which SchedulesDirect interpreted as a DOS (Denial of Service) attack and disabled your account (and IP address).
@Shadowghost commented on GitHub (Jan 23, 2025):
A short rundown on how this issue manifested:
Current fix:
Future fix: See outline on #13227
@herbiejhopkins commented on GitHub (Jan 26, 2025):
I upgraded to jellyfin v10.10.4 on 22nd - got my SD account unblocked and re-setup live tv schedules. I can see in the logs that I was getting a lot of the familiar: "Unable to pre-cache ..." warnings by the 24th.
[2025-01-24 06:00:03.610 +00:00] [INF] [61] Jellyfin.LiveTv.Listings.SchedulesDirect: Authenticated with Schedules Direct token: "ada0a23c1b88791231c0e7eb3d2f21da"
...
[2025-01-24 06:04:14.468 +00:00] [WRN] [66] Jellyfin.LiveTv.Guide.GuideManager: Unable to pre-cache "https://json.schedulesdirect.org/20141201/image/89a8cf7451cdaf83a45e770ac72894cbff71edab45907d11cc85fdfca6a6d0c8.jpg?token=4f91d333652986d145d348b4cba8bc49"
So it seems it's still fetching images using a token that's not the same as the token generated that day.
Today, 26th I can see token requests to SD are returning: "Access to account via JSON has been disabled. If you are running Jellyfin, upgrade to v10.10.4 or higher". So it seems my SD account has been blocked again.
Did this fix not get included in v10.10.4 after all?
@shawnhaywood commented on GitHub (Jan 26, 2025):
I had a similar experience. I did the upgrade to 10.10.4 but it seemed to still be blocked. SD indicated my IP wasn't blocked. But, after a while it started working and has worked fine since.
@felix920506 commented on GitHub (Jan 26, 2025):
I think we have enough confirmation that it should start working in a few days if it doesn't immediately start working after unblocking and updating. Please stop commenting if you don't have any info to add. Instead please use thumbs up emote.
@BrickHardmeat commented on GitHub (Jan 27, 2025):
I hope it's ok to ask this here. I did ask in the Jellyfin forum but I didn't get a response. I understand the explanation of the fix up thread which says ..
" Do not save any images beyond 2 days for SD (this also means, you don't have EPG images beyond 2 days)"
So, at least as I understand it, the EPG will only ever contain 2 days worth of thumbnails and images. Fair enough. But I went to the EPG on Thursday night at 10pm, assuming that I'd be able to get thumbnails up to Saturday at 10pm but it wasn't the case as the thumbnails seemed to be only generated up to Saturday morning at around 10:30am, so around 36 hours' worth rather than 2 days.
The next day, on Friday morning, the thumbnails had still only been generated until Saturday morning at 10:30am. I did go out for a few hours on Friday and when I got back, it did seem that the EPG had updated as I was getting thumbnails up to Sunday.
So I was wondering how it works in a practical sense ?. Is there a point where the EPG is automatically updated to refresh the thumbnails for the next day/two days ?
@Dleewee commented on GitHub (Jan 27, 2025):
Dashboard > scheduled tasks > live TV
Here you will find the task to refresh guide and can adjust it's schedule.
@redaters commented on GitHub (Jan 29, 2025):
I switched to Jellyfin 10.10.4 on 22 January. The Schedules Direct guide built into Jellyfin immediately started working (I had removed it since the guide problem started). for a week or so I had a guide available in Jellyfin but today noticed that my guide is now empty.
Starting 0300 GMT this morning I started getting the "Forbidden" error. I manually updated and the task ended after a few seconds with lots more "Forbidden" errors in my log. My Guide update task is scheduled for 3am daily.
here is an example for the error in the logs:
It appears that the 10.10.4 update did not fix the problem.
@BrickHardmeat commented on GitHub (Jan 29, 2025):
Have you raised a ticket with Schedules Direct ?. You may well still have a ban on your account that needs clearing ?
@eglia commented on GitHub (Jan 29, 2025):
I updated to Jellyfin 10.10.4 on 24 January and while it initially worked, during channel mapping my account was banned again. After contacting SD support to unblock it, the guide Data was working correctly until today, when my account was banned again.
2 Days ago I updated to jellyfin 10.10.5.
So it looks to me like the issue is still present
@Shadowghost commented on GitHub (Jan 29, 2025):
I wonder if this is because you still have some remaining "remote image references" from previous syncs in the database which include old API keys. Can you try removing the EPG source, clearing the EPG and then re-adding it?
@eglia commented on GitHub (Jan 29, 2025):
Before upgrading to 10.10.4 the SD source was completely removed and I added it freshly in 10.10.4 (thus having to remap all channels). There should be nothing in the database created pre-10.10.4.
@redaters commented on GitHub (Jan 29, 2025):
I can also confirm that I removed the SD source for several weeks before adding it again after the upgrade.
@dathbe commented on GitHub (Jan 29, 2025):
I disabled my SD, had them unblock my account, and was using scripts successfully for weeks until 10.10.4/10.10.5 came out. Then when I upgraded to 10.10.5, things were fine. This morning I woke up to an error message:
from my scripts:
In Jellyfin:
@redaters commented on GitHub (Feb 6, 2025):
I cleared the ban. Schedule worked for 1 week. It is now blocked again with the "Forbidden" message. Unfortunately, it appears that this bug is not fixed....
@dathbe commented on GitHub (Feb 6, 2025):
I had a similar issue where I was banned again after ~1 week or so. I unblocked it again, and the SD admins told me to keep and eye on it and see if it happens again.
@treddy73 commented on GitHub (Feb 6, 2025):
Mine was working also and now I've been banned again. I've removed the SD Guide plugin from JF. It would be really nice if I could still tune to a TV channel without the guide tho. At this point, I'm about ready to give up because it is affecting EPG123 for my WMC setup. And incidentally, EPG123 has never had a problem pulling guide data and it behaves itself.
@arazilsongweaver commented on GitHub (Feb 6, 2025):
Theory: This new wave of bans is caused by pre-fix EPG data triggering the ban mechanism over time. From what I understand, the fix only applied to newly acquired assets. This would mean that the old buggy assets would still be around until Jellyfin got around to purging or updating them.
I am not able to verify this theory. My EPG is working fine with no errors in the logs. I did perform a through purge of the LiveTV section after upgrading to the fixed Jellyfin release.
@thornygravy commented on GitHub (Feb 6, 2025):
"02/04Update: The issue with Jellyfin wasn't fixed in 10.10.4 (or 10.10.5). JellyFin is still ignoring the "back pressure" responses that we send once they've hit a limit and just keep going at 20-100 requests per second." -SD
@dathbe commented on GitHub (Feb 6, 2025):
What's the temporary solution? Should we be disabling the guide in Jellyfin, or should we just request unblocks when we get blocked?
@Dleewee commented on GitHub (Feb 6, 2025):
Workaround posted higher up in this thread.
https://github.com/jellyfin/jellyfin/issues/13147#issuecomment-2526231828
@dathbe commented on GitHub (Feb 6, 2025):
I know how I could disable the guide in Jellyfin and still get guide data through another method. The question was whether I should disable the guide in Jellyfin and still get guide data through another method while this new bug is being resolved.
@timangus commented on GitHub (Feb 6, 2025):
Sounds like we all risk getting banned again if we don't. I've now got mine using XMLTV on a cronjob.
@treddy73 commented on GitHub (Feb 7, 2025):
For those of us who are also using EPG123, this thread describes an issue with certain versions of EPG123 that causes the same problem. The developer strongly recommends updating to the latest version. Apparently I've been slapping the SD servers on multiple fronts. 😂
https://www.thegreenbutton.tv/forums/viewtopic.php?t=14906
@williamthrilliam commented on GitHub (Feb 9, 2025):
For some reason I'm only getting a few channels with lineups on xmltv tv_grab_zz_sdjson.
I've run
tv_grab_zz_sdjson --configurewith defaults and selected "all" on the lineups. I then runtv_grab_zz_sdjson --output /opt/SchedulesDirect/tv_grab_zz_sdjson.xml(my user is the owner of that folder, and jellyfin is the group). I add the xml file to jellyfin and only a few channels show lineups. tv_grab_na_dd works much better for lineups, but I don't have any images.Has anyone else experienced this?
@Dleewee commented on GitHub (Feb 9, 2025):
If you're running in a lightweight VM/LXC check if it's running out of RAM. I had a similar issue at first and upped the ram a couple of times until it was finishing comfortably.
@williamthrilliam commented on GitHub (Feb 9, 2025):
I have 31gigs on bare metal. So it shouldn't be running out of RAM.
@timangus commented on GitHub (Feb 19, 2025):
I'm guessing that https://github.com/jellyfin/jellyfin/pull/13469 fixes the (hopefully) last of the problems. It's in 10.10.6.
@timangus commented on GitHub (Feb 21, 2025):
Retract that. Got blocked again.
@Jeffofmany commented on GitHub (Feb 22, 2025):
I just checked https://www.schedulesdirect.org and they indicate the https://github.com/jellyfin/jellyfin/pull/13469 problem is still there themselves. I will wait until I see them announce it is fixed before using it again. In the mean time I'm happy with getting EPG updates myself. I wrote a little script and stuck it in crontab. It even emails me the run results.
@dathbe commented on GitHub (Feb 22, 2025):
My only issue with get script pulling of the EPG data was that the season and episode numbers seemed to be less reliable. Otherwise, I agree it was a pretty good solution.
@rmeden commented on GitHub (Feb 22, 2025):
Are you pulling from the old Schedules Direct DataDirect (tv_grab_na_dd) or JSON (tv_grab_zz_sdjson and others) service? The datadirect service doesn't provide true Season/Episode info. Jellyfin uses the JSON service and the data should be the same with all JSON clients.
@dathbe commented on GitHub (Feb 22, 2025):
I was using tv_grab_zz_sdjson. It did have episode number information, but it was far less reliable than the native Jellyfin pull for whatever reason. And it also seemed to be in a slightly different format where my series recordings were not picking up on the fact that any given episode had already been recorded.
I probably could have tinkered with it to get it better, but the Jellyfin fixes seem to be MOSTLY working for me. We'll see if that holds up.
@vicebooster commented on GitHub (Mar 21, 2025):
Bumpy bump.
@johnpc commented on GitHub (Mar 21, 2025):
if people are still having problems with this I switched to use a dockerized version of the SD fetch/serve script here: https://github.com/johnpc/schedules-direct-update-and-serve
Then I use ThreadFin to consume that. It's a better setup than what I had originally with the normal jellyfin connection.
@williamthrilliam commented on GitHub (Mar 21, 2025):
I hesitate to say anything, but the native SD integration has been working for me since 10.10.6. I did have to ask that my IP be allow listed again, but I haven't had problems since. SD still thinks it's an issue though, so IDK.
@eglia commented on GitHub (Mar 27, 2025):
I was just banned again by SD tonight, after everything was working fine for more than a month (since 10.10.6) with the native Jellyfin SD data download.
@Jeffofmany commented on GitHub (Mar 27, 2025):
Jellyfin 10.10.6 still causes problems as I've indicated on Feb 21 here. Using the native EPG download may seem to work but it is still pounding Schedules Direct with requests using expired tokens. Eventually you will get locked out. This is a complex problem for the Jellyfin devs who are all non-paid contributors. It will get fixed at some point. I, as many others, are using the XMLTV method for "TV Guide Data Providers" and provide the EPG XML data ourselves. Please read the statement on the Schedules Direct site that indicates the Jellyfin problem, it explains it better. Jellyfin and SD are both working together on this issue.
@redaters commented on GitHub (Apr 3, 2025):
I just got banned again by Schedules Direct. 10.10.6 is not fixed....
@arazilsongweaver commented on GitHub (Apr 3, 2025):
I got banned after running 10.10.6 on Schedules Direct for about a month. I think the root problem here is that Jellyfin doesn't have a good solution for refreshing tokens once they get "baked" into the image cache system. Unfortunately, the development team is currently busy rewriting the database subsystem so it might be some time before this issue gets resolved.
In the mean time, I am using this system to extract the non-image schedule data from Schedules Direct and dump it to an XMLTV file that is bind mounted into the Jellyfin container:
https://github.com/arazilsongweaver/docker-xmltv-sdingest
You will need to use
docker execordocker runto initialize and configure the.xmltvfolder before using this setup.@tfan1980 commented on GitHub (May 23, 2025):
If you have a few minutes, would love some more info on how I get Jellyfin to get the data from ThreadFin. I think I'm close, but can't quite get that working :(
@theshoeshiner commented on GitHub (Jul 15, 2025):
I'm looking into fixing this, and just want to lay out some details. There are a few things to note here:
The first two items potentially require different fixes because:
There are a few different ways to address this, some of which may fit more with the JF way of doing things. And I'm just spit balling here, I still need to look deeper into the image processing to understand level of effort for these.
Solution 3 Seemed the most straightforward to me, but admittedly that could be because I know less about the image retriever internals, and it seems to involve a more narrow set of changes to the API. Even if it feels a little hacky, maybe it will work as a temporary solution given that this issue completely breaks the SD integration.
@arazilsongweaver commented on GitHub (Jul 15, 2025):
Option 3 was described by another developer in pull request #13227. They did not implement the full interface solution at the time due to the EFCore refactor that is still being worked on for 10.11.0 release candidate series (see #13047 and #14350).
@tfan1980 commented on GitHub (Jul 15, 2025):
I'm not sure how the developer of EPG123 resolves this issue but I haven't had any issues with using EPG123 as a proxy for getting the guide data from Schedules Direct and not hitting the lockout issue that JF has run into. I'd be curious how they solved the problem or avoided it to begin with.
@theshoeshiner commented on GitHub (Jul 15, 2025):
@arazilsongweaver
Thanks for the link. I knew someone had worked on it but couldn't find the PR. It looks like that mostly solves it for now, albeit by dropping some of the SD image data. The guide data is the more important part for me anyway, so I'll likely wait to work on a fix.
@tfan1980
The issue is very much related to Jellyfin internals. It only exists in JF because the SD integration wasn't built with rate limiting and token refreshes fully baked in. The resolution in terms of how to hit the SD APIs pretty straightforward. The complex part is choosing how to apply that to the JF internals.
@madscientist42 commented on GitHub (Jul 15, 2025):
This is 6 months, guys...one should think it'd be resolved by now.
@theshoeshiner commented on GitHub (Jul 15, 2025):
I know right. What are we even paying for?
@rmeden commented on GitHub (Jul 15, 2025):
Images are where the problem is noticed, but the core issue is error handling. Currently, when there is a problem (expired token for example), my understanding is Jellyfin retries immediately with the same credentials.... hundreds of times a minute! That's why Schedules Direct blocks it. Imagine all the Jellyfin users attacking the JSON service all at once.... basically a denial of service attack. IP blocking is our only defense.
Jellyfin should parse the SD return code...
I'm not very familiar with the issue (I do account management and the datadirect service at Schedules Direct), but that's my understanding of the problem.
EDIT: I just noticed @theshoeshiner pretty much summed up the issue... I didn't notice it in my email notifications...
@troycarpenter commented on GitHub (Jul 19, 2025):
This problem is NOT limited to the SD EPG provider. I am currently using a custom xmltv.xml generator which also includes artwork with the current token appended and processed with the generic XMLTV process in JF. Jellyfin will "blindly" download all the artwork URLs which works as long as the token is valid.
However, the problem is the cached images that use an older token from when they were first downloaded. Jellyfin could still lock up your SD account in that case. I've been trying different approaches to work around that problem. The latest modification to my process is deleting all cached xml files from cache/xmltv directory. Still working to see if there will be a problem.
@rmeden and others have outlined approaches like checking return codes and renewing tokens. It would seem the SD token needs to be managed and not imbedded into URLS. The SD API documentation for getting an image says the token can be embedded in the headers and doesn't need to be appended to the URL:
https://github.com/SchedulesDirect/JSON-Service/wiki/API-20141201#retrieving-an-image
So the images do not need to be cached with token, but instead an "SD downloader" as proposed would need to recognize an SD image download and use the token at the time of download. Maybe this SD downloader could also be used for generic xmltv files if a SD URL is in the file (not sure where the SD creds will come from to get the token in that case...)
@Jeffofmany commented on GitHub (Jul 19, 2025):
It sounds like you're making good progress. The SD dev has expressed his desire to work with JF devs on resolving this problem. I'm just an end user but have been following this for a long time. But he could provide answers to any questions about the SD "under the hood" stuff. Hope this helps.
https://forum.jellyfin.org/t-schedulesdirect-request-that-a-jellyfin-developer-contact-me
@Sagetvmaster commented on GitHub (Aug 9, 2025):
SageTV user here. Sage has also been having problems regarding used tokens blocking access to SD servers for the same reasons. Jellyfin coders may be able to ask SD what Sage coders have done to fix the problem, which started at the same time as the Jellyfin problems, back in December when SD started blocking accounts where tokens were out of control. :)
@williamthrilliam commented on GitHub (Nov 11, 2025):
The previously mentioned work around using xmltv files is no longer working for me because of https://github.com/jellyfin/jellyfin/issues/6103. I now have no way of getting guide data.
@ashes00 commented on GitHub (Nov 13, 2025):
This issue is affecting me too. I know this is a volunteer group, and thank you. I'l like to +1 for getting JellyFin Live TV EPG and SchedulesDirect working.
@sneakrz commented on GitHub (Dec 1, 2025):
This issue just hit me now. Not sure why it happened all of a sudden.
@JRGonz commented on GitHub (Dec 28, 2025):
I've managed to pull the xmltv epg from sd using xmltv and just having jellyfin point to it but... obviously no images. Does anybody know a sane linux way to still periodically grab it with images and serve it to jellyfin? I guess this would require some sort of service running so that the epg could point it it. It would be nice if this could just point at local files.
@D-Rex3 commented on GitHub (Jan 5, 2026):
Is it possible to have this bugged guide retrieval at least removed from the dashboard guide options if it's not going to be repaired? I broke my account and have found myself in this rabbit hole and now I'm here. If it wasn't an option I would have figured out xmltv.
@Alliyance commented on GitHub (Jan 14, 2026):
Same issue, I was able to map my channels but after 10 min, I was lock out. Hope someone can fix this.
@JRGonz commented on GitHub (Jan 14, 2026):
There isn’t much you can do to fix this other than contacting sd to unlock or waiting out the unlock period. The best you can do for now is the above and use a different grabber. You will get the epg but it will lack images.
@Alliyance commented on GitHub (Jan 14, 2026):
Is there anyone working on it who are familiar with jellyfin codes?