FEATURE REQUEST: Cache station logos to server, parse to clients

There are several issues with station logos that have come to a head recently. For instance...


Android Clients cannot connect to Wikimedia Commons

Per this post and many other similar, the Android clients cannot seem to display images from Wikimedia Commons. I have rigorously tested with other websites, different formats from Wikimedia Commons (including letter casing), and even the same images with the same file names hosted locally. In every other situation and client interface (web, Feral HTPC, etc...), the station logos display with no problem. It is only the combination of Android Client + Wikimedia Commons link that make it not able to display.

As an aside, in the past I thought there was also a problem with Gracenote-provided logos, but have since discovered that another source was providing logo files that were connected to Wikimedia Commons, thus it was actually this same issue.


HTTPS web cannot see HTTP-only

Due to Docker-based providers like FastChannels being only unsecured (http) connections, stations in Channels have broken logos when making a secure (https) connection:

Image

The images load fine as an un-secure connection:

image

This seems to come down to how Channels web acts, not calling full paths, but only partial and filling in the rest from the location:

image


Clients don't understand localhost and similar paths

Since the clients try to load station logos directly, a source needs to reflect something they can read. As discussed here, this means that users must have sources like FastChannels use IP addresses or similar in order for the clients to load them, causing a lot of confusion as they will work in anything while connected on the server.


Remote connection cannot read local data

However, while putting in IP addresses and taking other similar measures work on the local network, they will not resolve in a remote situation. In order to do this, users either need to have their own hosted cloud files or a connection through TailScale, tunneling, VPN, etcetera. All of these are extra steps that add layers of technical complication.

And yes, it is understood that to work around this we could upload images to Channels and manage them there, but that is completely impractical when talking about hundreds of stations.


It seems like the easiest solution to all of this would be for Channels DVR to cache the station logos to the server so that when clients request them (whether at home or remote), that they could be delivered with no issues, no matter the consuming method.

5 Likes

Amen! :pray:t3:

1 Like

Yeah...this is a given. Too many problems with logos there. I think caching it is a good idea

Clients should not be requesting logos directly but through the server, similar to tuner sharing On. This would have the added benefit of not having each client on the LAN requesting the logos on its own. What would FancyBits do with this unused capacity?

Some user are using the client for hdhomerun and don't have a server.