Big change coming

[garyan2]

TBD. If caching is on, any image requests that would go to SD will go to the service. No communication with SD directly.

Currently with caching off, it will still go to the service, but the service will relay the redirect to the amazon servers to get the image. I think I am going to change that to having the service go ahead and grab the image as well and provide that to WMC. That way, even if you are not caching, once WMC downloads an image it won't request the same image over and over again.

Of course, any image request that would go to tmdb would still go directly to tmdb.

[Space]

I was going to say that for SD images, if it always went through the EPG23 service, shouldn't the WMC cache remain valid even if the token changes?
I mean the URL in WMC would point to the EPG123 service and therefore should not need to include the token for SD (the EPG123 service would add the token before it queried the image from SD).

If WMC has an image cache, why do you need the EPG123 service to have a separate cache?

[garyan2]

Right, I got there eventually... lack of sleep. For stand-alone Full Mode installs, there is no need to enable the cache. If you have multiple clients (WMC and/or XMLTV), then I would recommend the cache to be enabled to reduce the number of image requests to SD which counts against an image download limit SD is also looking at using.

[Space]

If the extra clients are WMC, then they should be able to work the same way as a Full mode WMC client as long as the URL image used in the guide includes the IP address or domain name of the EPG123 server machine (instead of localhost (i.e. the loopback address)) and they can communicate with each other (on the same subnet or are otherwise able to communicate with each other using the internal IP address).

This would mean that you would have one machine that is the EPG123 HTTP server and all the others would use that server to get the images in real time. They would each have their own WMC cache, so yes, if they all requested the same image you would have to get it from SD each time separately (unless you implement the cache for the HTTP server), but they still would only have to get that image once each (until the WMC cache expired or, I assume, the image is updated on the SD server).

You could also have it so that a WMC machine at one location can use the EPG123 HTTP server at another location (routed over the Internet), but that would require using external IP addresses or domain names in the image URL in the guide data and then setting up the NAT rules in your firewall for whatever port you will use for the server. One caution with this is it allows someone to set up a public EPG123 HTTP server which may be something that shouldn't be allowed, although there is nothing preventing someone from doing this now if they know a little programming...
This possibility may be one of the reasons SD is considering limits on the number of images that can be downloaded within a certain time period.

EDIT: One other thing I forgot to add is that if you use a public IP or public domain name in the URL so that you can have remote clients use a local server, the local client may not be able to access the local server unless your router supports "hairpin NAT" which allows you to access your public IP address from within your local LAN.

I don't know if many consumer routers support this, so another option is to use the local host file to assign a different IP address for the domain name you use in the URL. In the local machine (the one with the EPG123 HTTP server) you set that domain in the hosts file to point to the loopback or local IP address and on the remote systems you set it to the public (Internet) IP address of the router at the site where that EPG123 HTTP server is.

In this way you can use the same MXF file on both local and remote clients.

[garyan2]

I just published the "beta" version 1.7.0.0 with the service included. Though I think I've tested it out pretty well, I'm sure there are some users' networks that may identify needed improvements, which is why I published it as a pre-release beta. I only included the setup package and not the standalone package for various reasons discussed here, but will look into the feasibility of a portable package before fully releasing it.

In the configuration GUI, there is a new tab for 'Service'. I would recommend enabling the automatically refresh token.

To configure your clients to use HTTP to download and import the remote mxf file, you will need to delete your current task, click the text box showing the path to the mxf file, and then select the "server" on your network. Of course, the server would have to be already running on another computer in order to be seen. Then create the task again.

RemoteServers.PNG (10.23 KiB) Viewed 495 times

There will be no need to modify the scheduled task to change the user in order for the client mode to work if using HTTP.

[adam1991]

Interesting... Pretty cool surprise!

Now that you have an HTTP server, maybe you can look in to simulating the Microsoft extended guide data server? This would act like a local proxy that takes the queries from WMC for extended guide data and then queries the needed data from an external site (not sure which sites would be best to provide this info).

man, this is deja vu all over again.

This is EXACTLY how ReplayTV did it after the shutdown, with WiRNS.

Still does, no doubt.