EPG123 - Whole Home Configuration

[glorp]

I followed the steps @ http://epg123.garyan2.net exactly. Each WMC went flawlessly. Guide is installed for 14 days on each. All channels mapped. All plugins untouched.

You should be able to get between 25 to 30 days of schedule data, depending on the station. Since EPG123 uses the delta algorithm in our API, it will only update channels that have been updated since the last download, so it's not necessarily going to add all that much to the download once the initial pull has been done. (So a 30 day window isn't going to cause the download to be 2x the size of the 14 day download)

I'd vote for a future EPG123 "Whole Home" option where one MC could get schedule data, manage the cache, and create the MXF and other MCs could just load the MXF file from there. My channel configurations are all exactly the same, only one lineup. That would cut down your traffic from me by 3X.

[Moderator note: topic split from main EPG123 thread]

[garyan2]

I followed the steps @ http://epg123.garyan2.net exactly. Each WMC went flawlessly. Guide is installed for 14 days on each. All channels mapped. All plugins untouched.

You should be able to get between 25 to 30 days of schedule data, depending on the station. Since EPG123 uses the delta algorithm in our API, it will only update channels that have been updated since the last download, so it's not necessarily going to add all that much to the download once the initial pull has been done. (So a 30 day window isn't going to cause the download to be 2x the size of the 14 day download)

I'd vote for a future EPG123 "Whole Home" option where one MC could get schedule data, manage the cache, and create the MXF and other MCs could just load the MXF file from there. My channel configurations are all exactly the same, only one lineup. That would cut down your traffic from me by 3X.

I'm actually using your "Whole Home" solution already. I have a WHS 2011 server on my network which is scheduled to run epg123 nightly which is why I included the option to not automatically import guide data into WMC (WHS 2011 is based off Server 2008 and doesn't have WMC). All my laptops/computers have scheduled tasks to import the generated mxf file off the server and start the reindex task.

[glorp]

I'm actually using your "Whole Home" solution already. I have a WHS 2011 server on my network which is scheduled to run epg123 nightly which is why I included the option to not automatically import guide data into WMC (WHS 2011 is based off Server 2008 and doesn't have WMC). All my laptops/computers have scheduled tasks to import the generated mxf file off the server and start the reindex task.

Are you just running the loadmxf directly on the clients from a scheduled task with a UNC path to the file then? Not sure how to do that part, or more specifically not sure about the CL for loadmxf or how to kick off reindexing if I'm not using the GUI. And there's no "load only" option in the GUI.

[garyan2]

I'm actually using your "Whole Home" solution already. I have a WHS 2011 server on my network which is scheduled to run epg123 nightly which is why I included the option to not automatically import guide data into WMC (WHS 2011 is based off Server 2008 and doesn't have WMC). All my laptops/computers have scheduled tasks to import the generated mxf file off the server and start the reindex task.

Are you just running the loadmxf directly on the clients from a scheduled task with a UNC path to the file then? Not sure how to do that part, or more specifically not sure about the CL for loadmxf. And there's no "load only" option in the GUI.

Yup, the clients are running the loadmxf. Here is the script and epg123 doesn't reside on the clients.

Code: Select all

    @ECHO OFF
    ECHO Importing guide data
    START /WAIT %SYSTEMROOT%\ehome\loadmxf.exe -i \\THEBLACKBOX\epg123\epg123.mxf

    ECHO Initializing the reindex task of the guide data
    START /WAIT schtasks.exe /run /tn "Microsoft\Windows\Media Center\ReindexSearchRoot"

    EXIT

[glorp]

Yup, the clients are running the loadmxf. Here is the script and epg123 doesn't reside on the clients.

Perfect! Thank you man!

I'll give it a try in a few days. Want to make sure the set up works on the newly done WMCs for a few days anyway.

I have essentially the same set up. Windows Server Essentials 2012 R2. So there's nothing to worry about as long as every MC has the same lineup channel config or does that even matter? I mean the stuff that LineUpSelector and Guide Tool do are totally unimportant on the server and the set up done on the client dictates what gets loaded? As long as the server has the full lineup the loadmxf is happy I guess ?

[garyan2]

Yup, the clients are running the loadmxf. Here is the script and epg123 doesn't reside on the clients.

Perfect! Thank you man!

I'll give it a try in a few days. Want to make sure the set up works on the newly done WMCs for a few days anyway.

I have essentially the same set up. Windows Server Essentials 2012 R2. So there's nothing to worry about as long as every MC has the same lineup channel config or does that even matter? I mean the stuff that LineUpSelector and Guide Tool do are totally unimportant on the server and the set up done on the client dictates what gets loaded? As long as the server has the full lineup the loadmxf is happy I guess ?

Right. Basically to break it down ... if you have a MC with ATSC tuners, and another MC with CableCARD, then as long as the generated mxf file on the server contains both lineups it will work for both MCs. The Lineup Selector and Guide Tools will still need to be used for setup of each MC just like a stand-alone.

I will also note, the script I posted actually resides on the server as well as "ClientUpdate.cmd" file and the scheduled tasks are just calling that file. This way, I could actually change the updates for the whole house in one location if necessary.

[glorp]

I will also note, the script I posted actually resides on the server as well as "ClientUpdate.cmd" file and the scheduled tasks are just calling that file. This way, I could actually change the updates for the whole house in one location if necessary.

I see. I didn't think to do it that way. Is there any reason why you have the script run the ReindexSearchRoot task instead of just executing the same ehPrivJob the task itself runs?

One thing that I might suggest for a future release is the ability to set the location of the output MXF file. I would typically not put the epg123.exe in a share on the server but would have to for this since it has to also share the .mxf that can only be in the same directory as the .exe. Never-the-less, it's a cute network solution and I'm going to try it. Probably give the current set up another week of test runs first to insure there aren't any surprises first.

Can I just move the entire setup (.exe/.dll, .cfg, and .\cache) from one machine to another? I basically did that for my WMC set ups today but wimped out and didn't copy the .\cache or that guideImages.xml file and instead let them be re-created on first run.

[garyan2]

I will also note, the script I posted actually resides on the server as well as "ClientUpdate.cmd" file and the scheduled tasks are just calling that file. This way, I could actually change the updates for the whole house in one location if necessary.

I see. I didn't think to do it that way. Is there any reason why you have the script run the ReindexSearchRoot task instead of just executing the same ehPrivJob the task itself runs?

One thing that I might suggest for a future release is the ability to set the location of the output MXF file. I would typically not put the epg123.exe in a share on the server but would have to for this since it has to also share the .mxf that can only be in the same directory as the .exe. Never-the-less, it's a cute network solution and I'm going to try it. Probably give the current set up another week of test runs first to insure there aren't any surprises first.

Can I just move the entire setup (.exe/.dll, .cfg, and .\cache) from one machine to another? I basically did that for my WMC set ups today but wimped out and didn't copy the .\cache or that guideImages.xml file and instead let them be re-created on first run.

You can copy the cache and xml files no problem. Nothing unique about them. Everything that was used in the cache directory and is referenced in the xml file was used to create the current mxf file. Missing somthing? it will be downloaded. Have something extra? it will be deleted ... simple as that.

As far as ehPrivJob vs schtasks ... no reason. It was the first thing I tried, it worked, I kept it.

[glorp]

If I disable your epg_update task in Task Scheduler manually there is nothing that will re-enable it by running the GUI again correct? Except of course for deleting the task then recreating it from the GUI.

I'm adding a new task to load from the server via the cmd script. I disabled the existing epg_update task. I don't want it to run again but rather not delete it if I don't need to.

[garyan2]

Correct. No harm in disabling the task. epg123 doesn't care one way or the other, it just looks at task scheduler to see if the task exists and the last run status.

[glorp]

Plan to include option to only import a pre-generated mxf file and perform automatch feature for "Whole Home" configurations. (but this looks like it might be what I need to do if I were to use v0.9.0??)

Is this actually in 0.9.0 GUI or is it planned? The reason I ask is that although the mechanism discussed here works, it's hard to get any real indication that the MXF load was done and reindexing kicked off successfully other than checking the actual schedule. The GUI could/does log that. I was also considering tweaking the cmd file with some ECHOs to at least output the return values from the MXF load. That's kind of tricky because with multiple WMC I also need to log the computer name or something to ID the machine and then I suppose write the log across the network share back to the server. Doable. Messy.

[garyan2]

This feature is for both you and I, glorp ... and anyone who wants to duplicate our setup. It is not incorporated in the GUI just yet, so we have a bit of freedom yet. The client running epg123 will be necessary in order to take advantage of the automatch feature in v0.9.0, so that will be the recommended method. I was planning on having another switch to the CLI such as -i "\\server\folder\epg123.mxf". Not sure about modification to the GUI.

Any preference/suggestions?

[glorp]

A couple of things:

Since you have to add some way to define the location of epg123.mxf for this why not just make it an option regardless of whether it's for a client/server config set up or just in general? That way we can relocate the mxf file out of the local directory no matter how epg123 runs? I'd tell ya' to do that for the log and cache too but I don't think I'll get any traction on that one

I ran into some minor trouble setting up the sched task for the client imports running the cmd file. I don't think this is really something you need to do anything about. In fact I think it was trouble I created for myself but as a reminder or maybe food for thought... I set up my client import tasks to run as NETWORK SERVICE. The clients are not in a domain with the server and the server is an Essentials 2012 R2, not a Home Server version. So it turns out NETWORK SERVICE on a non-domain client is not the same as NETWORK SERVICE on a domain controller. I had share permission issues and loadmxf would not, load . Of course I could run it as my Admin user account but then I had to add my PW to the task. It would be a bit trickier for non-Admin accounts too I think. No real "fix" I can suggest and it won't happen often but you are likely to see this as a support issue as people try different configurations of clients and servers, and since you are creating the task with wahtever permissions the person running at the time has ... It might be useful to try and log something. Perhaps explicitly check for file access at the client first and log a permission error rather than just report a generic return value "1" for loadmxf ? Dunno. Just a thought.

I've been running client/server most of this week after I solved the permissions issue. Didn't realize this was going to be added or probably would have just waited. It would be nice to do it all from one GUI I think. In any case I like it and it works, so far flawlessly with the remote cmd file route.

[glorp]

For anybody with multiple media centers who wants to try/use this right now, I modified the original cmd file in this thread a little to accommodate the epgAutomatch feature as well as do some logging to make sure its running daily and there aren't any obvious errors occurring. I know garyan2 will probably make this obsolete but in the meantime. Here's the cmd file. I locate it on the server and then all that's needed is a scheduled task on the client that runs it daily/whatever. Disable the one epg123 creates if you use this and coordinate timing so the server is finished before any clients run so they get the latest data. When you configure the scheduled task's "Run a program" "Action" you *must* set the "Start in" path (have it's default directory) as the *client's* epg123 path in order to correctly place the log and find the epgAutomatch.exe executable. If you don't want Automatching, then just REM out or delete the line in the cmd that does it. Been using it on 3 different MCs for a week now. Works like charm with only the server updating schedule data from SD and my 3 clients updating from that single MXF on the server.
clientupdate.cmd:

Code: Select all

@ECHO OFF

SETLOCAL ENABLEEXTENSIONS

REM Set LOGFILE name here as desired
SET LOGFILE=epgclient-%COMPUTERNAME%.log

ECHO %date% %time% Starting client schedule update on %COMPUTERNAME% >%LOGFILE%
ECHO. >>%LOGFILE%

REM Make sure path to epg123.mxf is correct for your network
ECHO %date% %time% Importing guide data >>%LOGFILE%
START /WAIT %SYSTEMROOT%\ehome\loadmxf.exe -i [YOUR-PATH-TO]epg123.mxf >>%LOGFILE% 2>&1
ECHO %date% %time% Return Code: %ERRORLEVEL% >>%LOGFILE%
ECHO. >>%LOGFILE%

ECHO %date% %time% Beginning channel match >>%LOGFILE%
START /WAIT epgAutomatch.exe -match >>%LOGFILE% 2>&1
ECHO %date% %time% Return Code: %ERRORLEVEL% >>%LOGFILE%
ECHO. >>%LOGFILE%

ECHO %date% %time% Initializing the reindex task of the guide data >>%LOGFILE%
rem START /WAIT %SystemRoot%\ehome\ehprivjob.exe /DoReindexSearchRoot >>%LOGFILE% 2>&1
START /WAIT schtasks.exe /run /tn "Microsoft\Windows\Media Center\ReindexSearchRoot" >>%LOGFILE% 2>&1
ECHO %date% %time% Return Code: %ERRORLEVEL% >>%LOGFILE%
ECHO. >>%LOGFILE%

ECHO %date% %time% End client schedule update on %COMPUTERNAME% >>%LOGFILE%
ECHO ------------------------------------------------------------------------------------------- >>%LOGFILE%
ECHO. >>%LOGFILE%
ECHO. >>%LOGFILE%

EXIT

Note the need to replace the [YOUR-PATH-TO] with a UNC path to the central epg123.mxf

Log looks like:
epgclient-HTPC2.log

Code: Select all

04/02/2016  8:00:00.49 Starting client schedule update on HTPC2 
 
04/02/2016  8:00:00.49 Importing guide data 
04/02/2016  8:01:39.39 Return Code: 0 
 
04/02/2016  8:01:39.39 Beginning channel match 
04/02/2016  8:01:44.21 Return Code: 0 
 
04/02/2016  8:01:44.21 Initializing the reindex task of the guide data 
04/02/2016  8:01:44.26 Return Code: 0 
 
04/02/2016  8:01:44.26 End client schedule update on HTPC2 
------------------------------------------------------------------------------------------- 

The cmd will overwrite every days' log so you can either rotate it yourself with a Windows logrotate clone utility or change the initial redirect from ">" to ">>". Then you'll just need to manage it's size growth manually.

[garyan2]

Nice ... I'll just add one thing. If you don't want automatch run on the client, I would suggest running "epgAutomatch.exe -refresh" instead of "-match". For those clients that WMC is always on, the -refresh will notify WMC that changes have been made; otherwise, the "days of guide data" and possibly the search won't update with the new data.

The -refresh is included in the -match functionality.

[glorp]

Good to know.

I probably also should have noted that you don't actually need a server/client relationship to do this. Multiple media centers where one of them is designated as master to do an "update and load" and then slaves that just do loads off the master will also work fine. The only caveat no matter how you do it is to make sure the MXF is built on the master/server with all lineups selected that you use for your home.

[garyan2]

There is also one other "quirk" ... if the user uses the .\logos directory for station logos, then the server will have to run the update using a UNC path to epg123. That way, the links to the logos will be the same for the server as all the clients.

[glorp]

My 3 clients that rely on the server-generated xmf still have the (now) several week old caches and .mxf files they created while they were last in use. At best those are completely out of date so I'm going to just remove the cache folder and the ~100 MB .mxf from all of them. I assume if I ever want to run EPG123 from the client(s) again it will just regenerate what it needs at that point and removal of those will not cause it an issue? I know it won't as EPG123 clients of the server, I'm just making sure if EPG123 is run locally again, absence of those is no problem to it. The plan is to leave the original .cfg file there from the last local runs weeks ago.

[garyan2]

No problem doing that at all. Hopefully next release will include something more friendly to a whole home setup.

[artm]

Yes, that would be welcomed. Right now I run three identical setups so do find it wasteful to update three times every night.

Two clients pulling the data from the "server" is very nice. The only inputs from the user should be: network login info, network location of server and a time to schedule the task. I think...