INTERACT FORUM
Windows => Television => Topic started by: avid on August 10, 2023, 02:09:08 am
-
I am controlling MC with MCWS. One aspect that doesn't work is the TV Logos.
I discovered that the URLs are cached in the "Cover Art/TV Logos" folder, which defaults to "C:\Users\XXXX\AppData\Roaming\J River\Media Center 31\Cover Art\TV Logos". This folder is not accessible to an external process (e.g. in IIS), but MCWS File/GetInfo for a channel returns an "Image File" property for the absolute path.
So ... I copied Cover Art to somewhere more public and changed the "Tools/Options/File Location" folder to point to that more public directory.
However, File/GetInfo for a channel still returns the old cached path.
My question is: how should I get MC to re-scan and re-cache the TV Logos in the new path? Can I safely delete the old "Cover Art" and get it to rebuild?
-
That was not a good move.!! The correct solution was to re-host my code in a process that has permission to access the files in Appdata.
HOWEVER I now have a problem as a result of moving that folder and then moving it back. MC now thinks that the channel logos are in a "Cover Art" path that doesn't exist. So the database is now corrupt - or at least incorrect. Is there any way to cause MC to re-build its TV Logos - fetching anew from my HDHomeRun and its EPG???
Thanks in advance
-
Panic over! My TV logo cache seems to have sorted itself out overnight (EPG update??) and the channels now return the original (and correct) web URLs.
-
I am glad it has sorted itself out. It has been a while since I worked on the stuff. MC looks for TV logos from "TV Logos" subfolder of the cover art folder. The Cover Art folder location is user selected. If the user does not select, a default location is used. I would have guessed that if you move the logos back to the configured location, it should work just fine, especially since MC would search the TV Logos folder for a matching channel logo based on channel name or channel key. I am not sure why it did not. EPG loading might have restored the channel logos.
-
While it is now working for me, I am uncomfortable that MCWS File/GetInfo on a TV channel is returning the "Image File" field which can either an external URL (in my case from HRHomeRun) or a stored cached local physical file path on the MC server machine.
This will work as long as the MCWS client is on the same machine as the media server and the client process runs as the same user as the media server process. And this is what I have done.
But it will fail for any access from outside the server machine (e.g. any web-based remote client).
To fix this I would propose a change, such that for a cached logo the "Image File" field is returned as "/MCWS/v1/Television/GetLogo?key=nnn" (i.e. always a URL) and you add a new GetLogo command to return the image bytes. This would work in all cases.
-
It will work on a remote computer too. I just tried it (and MC clients have been working fine too).
Enter this in a browser:
http://<IPAddress>:52199/MCWS/v1/File/GetFile?File=<######>&FileType=Key&Helper=ChannelLogo
where <######> is the library key of a channel on MC server, you will get the channel logo displayed.
-
Unfortunately ...MCWS/v1/File/GetFile... only works for a channel for which MC has cached the logo. In the case where it has not been cached (and "Image File" still has a img.hdhomerun.com URL), then the GetFile returns a 404.
So I still have to empirically try both. :-(
Either
- I try GetFile first, and if I get a 404 I try the "Image File" hoping it's a URL
or
- I try to determine the format of "Image File" (URL or local path). If I think it is a URL, I will use it, else try GetFile
Neither is nice
-
OK - I've gone for my second option, in a way that works now and should be immune to any future changes that you may make to GetInfo or GetFile for a channel:
var logoUrl = MC.Url + "File/GetFile?FileType=Key&Helper=ChannelLogo&File=" + Key;
if (Info.ContainsKey("Image File") && Info["Image File"].StartsWith("http"))
{
logoUrl = Info["Image File"];
}
It's definitely not elegant, but it works and should be robust.