schedules direct EPG

[goerdi]

Hi !

I setup now my Live tv with a m3u playlist and also i setup EPG via schedules direct..
its not really finished.. but in the jellyfin log i have tons of these messages

Code:

[2025-01-24 12:06:15.197 +01:00] [WRN] Unable to pre-cache "https://json.schedulesdirect.org/20141201/image/9b398ced31be09445ec12974e0e3b4a193d9134d5038ff99a310bfb71c893449.jpg?token={censored token - TDP}"
System.InvalidOperationException: Unable to convert any images to local
  at Emby.Server.Implementations.Library.LibraryManager.ConvertImageToLocal(BaseItem item, ItemImageInfo image, Int32 imageIndex, Boolean removeOnFailure)
  at Jellyfin.LiveTv.Guide.GuideManager.<>c__DisplayClass24_0.<<PreCacheImages>b__2>d.MoveNext()

Is this a problem ?

Ciao Gerd

[TheDreadPirate]

My understanding of that error is that the client tried to retrieve an image from the server, but the server didn't have one.

I've seen this error for local content, so it isn't specific to SD and isn't anything to worry about. It would just cause some items on the page to not have an image.

With the changes made in 10.10.4 with how Jellyfin connects to SchedulesDirect, I wouldn't be surprised if those changes are the cause. There is an ongoing effort to improve how Jellyfin works with SchedulesDirect after the recent changes on SD's end.

[theguymadmax]

That issue should be fixed in the master branch, but it won't be released until the next major update (10.11). However, the guide should still work; you'll just see those warnings.

[rkulagow]

My understanding of that error is that the client tried to retrieve an image from the server, but the server didn't have one.

(I'm the SchedulesDirect JSON service developer)

That particular image ("9b398ced31be09445ec12974e0e3b4a193d9134d5038ff99a310bfb71c893449.jpg") does exist on our servers; you can generate a token and retrieve it by using the URL that's in the error message.

If you do retrieve it, it's showing the cast of "WaPo Bodensee"

So the image not existing on our side isn't the cause of the warning message.

[rkulagow]

Once you're able to successfully "manually" download an image using a regular browser with the token at the end (or in the header), just change one of the digits in the filename of the JPG and make another request. If the image isn't available on our side, you'll get a JSON error response with code:5000 in it.

[theguymadmax]

My understanding of that error is that the client tried to retrieve an image from the server, but the server didn't have one.

(I'm the SchedulesDirect JSON service developer)

That particular image ("9b398ced31be09445ec12974e0e3b4a193d9134d5038ff99a310bfb71c893449.jpg") does exist on our servers; you can generate a token and retrieve it by using the URL that's in the error message.

If you do retrieve it, it's showing the cast of "WaPo Bodensee"

So the image not existing on our side isn't the cause of the warning message.

Thanks for clarifying that point.

That pre-cache warning happens when the system can't read the Content-Type header of the file to determine its image type. This issue also affects other guide data images. There is now a fallback mechanism that uses the file's URL extension to determine the image type, which is available in the master branch. You can find the relevant PR I linked above.

[rkulagow]

I just looked at the object in S3, and then also ran the same request with Postman. Both show that AWS is setting the Content-Type to image/jpg

(I understand that you've got a workaround in place, but if the reason for the workaround is that there's no Content-Type, then I think we are sending it on the image requests.)

I re-read what you wrote, and I now realize that you're talking about the header of the downloaded _file_, and not the HTTP transaction.

When I run "file" against the image that we've been discussing, I get:

JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 480x720, components 3

So this particular image does seem to have a valid JPEG header?

Anyway, if this is all a moot point, then please let me know. If there's additional troubleshooting that you'd like to perform, then please let me know that too.

[theguymadmax]

I'm only able to test with the data I have. So, based on my XML file:

Example 1: Jellyfin processes this correctly without throwing any exceptions in the logs.

Code:

curl -I https://zap2it.tmsimg.com/assets/p28311369_b_v13_ab.jpg
HTTP/2 200
content-type: image/jpeg
content-length: 1907753
date: Thu, 16 Jan 2025 22:19:35 GMT
server: nginx/1.18.0 (Ubuntu)

Example 2: Content-type isn't included in the header.

Code:

curl -I https://zap2it.tmsimg.com/assets/p11334917_st_v9_aa.jpg
HTTP/2 200
content-length: 440691
date: Tue, 21 Jan 2025 16:50:01 GMT
server: nginx/1.18.0 (Ubuntu)

In this case, Jellyfin encounters an issue:

Code:

[2025-01-24 03:21:48.767 +00:00] [WRN] [121] Jellyfin.LiveTv.Guide.GuideManager: Unable to pre-cache "https://zap2it.tmsimg.com/assets/p11334917_st_v9_aa.jpg"
System.Net.Http.HttpRequestException: Invalid image received: contentType not set.
  at MediaBrowser.Providers.Manager.ProviderManager.SaveImage(BaseItem item, String url, ImageType type, Nullable`1 imageIndex, CancellationToken cancellationToken)
  at Emby.Server.Implementations.Library.LibraryManager.ConvertImageToLocal(BaseItem item, ItemImageInfo image, Int32 imageIndex, Boolean removeOnFailure)
  at Jellyfin.LiveTv.Guide.GuideManager.<>c__DisplayClass24_0.<<PreCacheImages>b__2>d.MoveNext()

Jellyfin is unable to determine the content-type because it’s not provided in the response. In the future, the system will fall back to determining the content-type based on the url file extension, preventing this exception from being thrown.

If your images are sending a content-type header like the first example, please open an issue on the GitHub repo.

[rkulagow]

I'm only able to test with the data I have. So, based on my XML file:

Example 1: Jellyfin processes this correctly without throwing any exceptions in the logs.

Code:

curl -I https://zap2it.tmsimg.com/assets/p28311369_b_v13_ab.jpg
HTTP/2 200
content-type: image/jpeg
content-length: 1907753
date: Thu, 16 Jan 2025 22:19:35 GMT
server: nginx/1.18.0 (Ubuntu)

Example 2: Content-type isn't included in the header.

Code:

curl -I https://zap2it.tmsimg.com/assets/p11334917_st_v9_aa.jpg
HTTP/2 200
content-length: 440691
date: Tue, 21 Jan 2025 16:50:01 GMT
server: nginx/1.18.0 (Ubuntu)

In this case, Jellyfin encounters an issue:

Code:

[2025-01-24 03:21:48.767 +00:00] [WRN] [121] Jellyfin.LiveTv.Guide.GuideManager: Unable to pre-cache "https://zap2it.tmsimg.com/assets/p11334917_st_v9_aa.jpg"
System.Net.Http.HttpRequestException: Invalid image received: contentType not set.
  at MediaBrowser.Providers.Manager.ProviderManager.SaveImage(BaseItem item, String url, ImageType type, Nullable`1 imageIndex, CancellationToken cancellationToken)
  at Emby.Server.Implementations.Library.LibraryManager.ConvertImageToLocal(BaseItem item, ItemImageInfo image, Int32 imageIndex, Boolean removeOnFailure)
  at Jellyfin.LiveTv.Guide.GuideManager.<>c__DisplayClass24_0.<<PreCacheImages>b__2>d.MoveNext()

Jellyfin is unable to determine the content-type because it’s not provided in the response. In the future, the system will fall back to determining the content-type based on the url file extension, preventing this exception from being thrown.

If your images are sending a content-type header like the first example, please open an issue on the GitHub repo.

Since SchedulesDirect isn't Zap2It, I don't have any control over what they're doing.

But from your second example, p11334917_st_v9_aa.jpg -> "882a86de40012ed1b119084d73098130ab25ff29b144d1402a3c000e07cdf8bb.jpg" on SchedulesDirect, and if you request 882a... you'll see that we're sending a correct Content-Type of image/jpg

[theguymadmax]

It looks like I misread the user log. Upon reviewing it again, I don't see the "Invalid image received: contentType not set" message. So, it seems like the issue must be something else.

That error message looks more like this issue.

@goerdi Can you post more of the logs? Looking to see if there are any additional error codes.

Edit: updated link