Missing Channel Images

[NortherNerd 0]

I know this has been a topic that has been discussed before.  I have read those posts and do not see anything that applies.  Here is my situation:

• I am using an IPTV provider
• About 70% of my channels have guide data and channel images
• My m3u file contains links to channel images.  Here is one of the links that doesn't work in the guide:  1015theeagle.com/wp-content/uploads/2014/12/Depositphotos_57172771_original.jpg (you will need to put an https:// in front of that link. 
• As you can see, the jpg image really does exist and displays fine in a browser
• In Channels setup, if I edit the image and attempt to add that URL manually, I get the following error "There was an error processing the request. Please try again later"

The problem is that when the image load fails, it does not fall back to display the channel name, it just displays nothing.

Any help would be appreciated.

 

[Luke 37116]

Quote

• In Channels setup, if I edit the image and attempt to add that URL manually, I get the following error "There was an error processing the request. Please try again later"

Hi, please attach the emby server log from when you tried to do this:

How to Report a Problem

Thanks.

[NortherNerd 0]

Thanks for that Luke, I'm quite new to this forum.  Plus as I've learned, you really have to work hard to get the logs on a Synology NAS

You will see in the attached log that I went in and manually tried to add the image in the Channels section of Live TV setup.  I tailed the log to show just that interaction.

embyserver.txt

[Luke 37116]

On 8/7/2023 at 10:58 AM, NortherNerd said:

Thanks for that Luke, I'm quite new to this forum.  Plus as I've learned, you really have to work hard to get the logs on a Synology NAS

You will see in the attached log that I went in and manually tried to add the image in the Channels section of Live TV setup.  I tailed the log to show just that interaction.

embyserver.txt 20.8 kB · 0 downloads

@NortherNerdit looks like your server is having trouble reaching your domain where the images are hosted:

2023-08-07 10:50:41.582 Error HttpClient: Error getting response from https://themediaboxx.com/wp-content/uploads/2018/09/Sky_Cinema_Action_DE_Logo_2016.png
	*** Error Report ***
	Version: 4.7.11.0
	Command line: /volume1/@appstore/EmbyServer/system/EmbyServer.dll -programdata /var/packages/EmbyServer/var -ffdetect /var/packages/EmbyServer/target/bin/ffdetect -ffmpeg /var/packages/EmbyServer/target/bin/ffmpeg -ffprobe /var/packages/EmbyServer/target/bin/ffprobe -nolocalportconfig -ignore_vaapi_enabled_flag -pidfile /var/packages/EmbyServer/var/EmbyServer.pid -defaultdirectory /volume1/Public -updatepackage emby-server-synology7_{version}_x86_64.spk -noautorunwebapp
	Operating system: Linux version 4.4.180+ (root@build5) (gcc version 8.5.0 (GCC) ) #42962 SMP Sat Apr 8 00:15:03 CST 2023
	Framework: .NET 6.0.8
	OS/Process: x64/x64
	Runtime: volume1/@appstore/EmbyServer/system/System.Private.CoreLib.dll
	Processor count: 8
	Data path: /var/packages/EmbyServer/var
	Application path: /volume1/@appstore/EmbyServer/system
	System.Net.Http.HttpRequestException: System.Net.Http.HttpRequestException: Name or service not known (themediaboxx.com:443)

I'm guessing you'll probably say the machine can reach that url, but something is still blocking the emby server process from reaching it. Typical causes of this are firewall, security software or VPN. Can you check into this? Thanks.

[NortherNerd 0]

So you are right , I'm going to say that the machine has access.  And from the command line, I verified I had access to the image.   Still, I wanted to test your idea further so I downloaded the image to OneDrive and then created a share to this image.  Now, this actually failed because OneDrive puts scripts around the image to allow the user to easily download etc.  However, the interesting bit is that when this happened, the logs show an explicit error saying it could not download the file (see line 2).  This download error was not present in the first log.  In other words, in the first log, Emby did have access to the image.

embyserver.txt

[Luke 37116]

4 hours ago, NortherNerd said:

So you are right , I'm going to say that the machine has access.  And from the command line, I verified I had access to the image.   Still, I wanted to test your idea further so I downloaded the image to OneDrive and then created a share to this image.  Now, this actually failed because OneDrive puts scripts around the image to allow the user to easily download etc.  However, the interesting bit is that when this happened, the logs show an explicit error saying it could not download the file (see line 2).  This download error was not present in the first log.  In other words, in the first log, Emby did have access to the image.

embyserver.txt 4.31 kB · 0 downloads

This is a different problem. The server sending back the image is not specifying a content type in the response header, therefore the format of the image cannot be determined.

Does this help you proceed to resolve this? 

[NortherNerd 0]

To eliminate all question about access I've done the following:

• I spun up a web server on the same host that is running Emby Server.  The webserver is called 'chiwatest'.  Access is all local, no firewalls, no routers, no anti-virus
• I downloaded the image that won't load and called it channel.jpg
• As a control case, I also downloaded an image that was working.  It is the CNN logo and the file name is cnn.png
• Both channel.jpg and cnn.pgn were placed in the root directory of the webserver
• I verified I have access to both files using a browser
• I then changed the m3u file for these two channels such that tvg-logo="http://chiwatest/channel.jpg" and "http://chiwatest/cnn.pgn" respectively

The results were that the CNN logo loaded fine in the guide.  The channel.jpg logo did not load.  I've attached the log file.  The log file shows that Emby is throwing errors, but at least some of these errors are false.  For example "System.Net.Http.HttpRequestException: System.Net.Http.HttpRequestException: Name or service not known (chiwatest:80)" is not true, because the identical same service processed the CNN logo just fine.

embyserver.txt

[NortherNerd 0]

Ooops, typo in my text above, the CNN logo file is cnn.png

[Luke 37116]

Complete log file? I don't see the cnn request in there. 

[NortherNerd 0]

I didn't include that part of the log because there is no error for the channels that work.  So for CNN is just said ...

 

2023-08-17 23:48:21.496 Info LiveTV: Found epg channel in XmlTV  USA CNN* cnn.us

[Luke 37116]

Please attach the complete emby server log. Thanks.

[NortherNerd 0]

Additional testing with the file (and others) that you requested:

• I shortened my M3u playlist to two channels.  I did this partly to make the test case easier, and partly to ensure that nothing before or after the Christmas Movie channel was causing an issue.  This M3u playlist is attached.  I've obfuscated my user-id/password.
• I verified that the guide showed two channels and that CNN logo displayed and that the Christmas Movie channel logo was again blank.  I've attached a screen shot.
• Incidentally, both channels work in that I can stream content
• As above, both graphic files for CNN and the Christmas Movie are local to the same server running Emby
• Finally, as per your request, I have sent the entire log

1691380765A30C88A - Test.m3u embyserver.txt

[NortherNerd 0]

Hey @Luke- here is the embyserver.txt file again.  I noticed another occurrence of my user-id/password contained in the log.  That stuff is everywhere 

embyserver.txt

[Luke 37116]

The log doesn't contain the http request for the cnn image so it seems like it must have already been in place. You may want to try doing your m3u by ip address instead of chiwatest domain name. See if that works.

[NortherNerd 0]

I tried using an IP address, but something inside the Emby processing gets confused.  Perhaps because the webserver and EmbyServer are running on the same machine.  Not sure, but the NAS that is hosting Emby can handle the URL GET with IP Address.

That said, I did a lot more testing.  Here's what I found:

1. There is a lot of caching going on.  I'm not exactly sure when it decides to cache or not.  For example, the CNN logo was being very persistent.  If the tvg-id tag was set, it used the image from the standard channel name and completely ignored the tvg-logo address.  In the case of CNN, the tvg-id was set to "CNN.US" and this will load that logo regardless of what URL tvg-logo points to
2. Also, if there was one successful image loaded for that channel at some point, and if the tvg-logo image subsequently cannot be used, it falls back to the cached entry.  The way to get rid of this is to use the Emby interface to edit the image for that channel and delete it.
3. So, all this caching was helping to obscure some of my testing.  Once I got rid of the caching issues, the testing became more clear
4. So @Lukepart of the reason you weren't seeing the CNN image load was that the tvg-id tag was set, and it was never going to load anything given that it had a valid tvg-id
5. I am certain I have connectivity to the website:  //1015theeagle.com/wp-content/uploads/2014/12/Depositphotos_57172771_original.jpg.  I tested this several ways on my Synology NAS, including using Download Manager to load some of the files that Emby says it cannot load.
6. I further put my Synology NAS in the DMZ of my home network to prove that no firewall or antivirus or frankly anything was blocking access
7. It was initially suggested that Emby didn't have access to the URL's of the missing images.  I did some more testing and the error Emby throws when it doesn't have access vs when it has access but still cannot download the image are VERY different.

Since my Synology NAS (which hosts Emby) has easy access to the dozens of images that Emby says it cannot load, I am convinced the problem lies in Emby.  The explanation that Emby doesn't have access simply does not hold water.  What is far more probable is that Emby's "HTTP GET" processing is a bit "precious" and it is having difficulty with the responses from some servers.  

I searched the web for the error "System.InvalidOperationException: System.InvalidOperationException: Operation is not valid due to the current state of the object." which is one of the errors Emby throws with an image it is having trouble with.  Note this is not an error that Emby throws when it doesn't have access to the image.  Low and behold, searching for this string, brought me to dozens of entries of Emby users having trouble loading images in the TV Guide.  Imagine that!

Unfortunately instead of having users spin up their own web server, putting NAS's in a DMZ and doing hours of testing, it would be nice if Emby admitted they had a problem and made their HTTP GET processing more robust.  The many dozens of other posts I found with this same problem further point to an Emby issue.

[Luke 37116]

Quote

 

There is a lot of caching going on.  I'm not exactly sure when it decides to cache or not.  For example, the CNN logo was being very persistent.  If the tvg-id tag was set, it used the image from the standard channel name and completely ignored the tvg-logo address.  In the case of CNN, the tvg-id was set to "CNN.US" and this will load that logo regardless of what URL tvg-logo points to

If the guide data has a logo then currently it will get priority of the tuner-specified logo. We will be making this configurable though. So that's why that was happening, because it was able to use the logo from the guide data.

[Luke 37116]

Quote

I tried using an IP address, but something inside the Emby processing gets confused.  

What do you mean exactly?

[NortherNerd 0]

This is the only test case Emby needs to solve.  This URL Christmas Movies Logo works on the Synology NAS.  It works with Download Manager.  It even works with a bit of Python code performing an HTTP GET that I wrote running on the Synology NAS.  The same NAS that hosts the Emby Server.

That URL does not work in Emby.  You can generate the error easily, by simply manually editing the logo for a channel and put that in as the URL.  It will fail there and generate the same error code in the log as it does when you are doing a guide refresh.

Once Emby solves why their HTTP GET code is being so precious with that URL, it is likely the dozens of other failed URL's will also work.

[Luke 37116]

@NortherNerdI don't really have an explanation for this because we're just passing in the url to the dotnet runtime's http client, and it's giving us that error back of host not reachable.

It usually means something is blocking the connection or it just can't resolve the domain. If you'd like to try installing 4.7.14 from our website, it has an updated .net runtime so there's always a chance that will help.

But that's why I think the most practical answer would be to build the url with the ip address.