EPG123 guide display changes cause Long Display Time?

[redmed]

When opening the guide the first time of that day, the guide will take 4-7 minutes to display. After the first display the guide will open up normally within seconds the rest of the day. Then the next day the first guide display will again take a long time. I load guide data from Zap2it every three days. The first guide display takes just as long whether new Zap2it data was loaded that morning or not. I used EPG123 to modify how the guide is displayed. I extended the time range to 3 hours and 8 channels at a time. I wonder if changing the number of channels and time range displayed from the standard WMC setup is causing the long first display?

I have been using WMC on this laptop for 3+ years and at first thought the long first display could possibly be caused by a large WMC file. I cleared the WMC History and deleted all the scheduled series. Hoping that would clear out large WMC files but the first guide display still takes just as long as before. I also used CCleaner to clear the registry and clean up program files. Still the first guide display still takes 4-7 minutes.

[garyan2]

No, the geometry of the guide won't impact your time to display. To test that theory, just open the Tweak WMC form and click the [Default] button which will return it to the default WMC geometries.

When you say you are loading data from Zap2it, does that mean you are not using EPG123/SD for your data?

[redmed]

I use this bat file to load the Zap2it data
cd C:\epg
zap2xml -u XXXXX@XXX.net -p XXXX -d 13
java -Dfile.encoding=UTF-8 -jar xmltv-to-mxf-0.0.2-SNAPSHOT.jar xmltv.xml
C:\Windows\ehome\loadmxf -i mxf.xml
%SystemRoot%\ehome\ehPrivJob.exe /DoReindexSearchRoot
-------------------------------
I have had WMC get slow before (similar to now) after using it for 4+ years. I reloaded a fresh W7 and reinitialized WMC and things perked back up. I'm hesitant to reload W7 now that it's working so well, except for the initial load of the guide. It's been a slow process trying to fix this. I do something and think I fixed it then the next morning I find the first guide display slow again. I used to schedule the WMC optimize at 3am then run the Zip2it at 5am. Then I changed to run the Zip2it bat @5am then the WMC optimize @7am. Still the first guide display is slow. Today I turned off the WMC Optimize process. Tomorrow morning I'll know if not running Optimize changes things. I'm going to start checking the ehome directory for a large file (Log file?) and start editing things I find file by file.

[garyan2]

That would have been my first suggestion... to turn off the optimization. My experience says using that increases the likelyhood of a database crash.

You do have the guide indexing being performed (which would have been my first if not for the optimization above), but not the pvr indexing (you'll want to add that). That is all the suggestions I would have.

[Gripweed]

I think Gary is being very gracious considering he is not the author of the program that is causing you problems. What does the author of zap2xml have to say?

My suggestion is spend the $25 and get the first class data that SD provides and then process it with Gary's excellent program.

[redmed]

I think I found what is causing the guide to take a long time to load/display the first time each day. I suspected it was a large file and I think I found it. I found the C:\program data\microsoft\ehome\mcepg2-0.db file to be over a half of a gig. From what I can find mcepg2-0.db maps a tuner to each channel which is used to schedule each recording to a tuner. I have two antennas one antenna is pointed SE to Detroit and the other pointed SW to Lansing. I have been switching tuners between these antennas and changing channel priorities quite often. Plus in the last couple years I have had 3 different tuners fail and had to replace them. With each new tuner I went through a new process of prioritizing 6 channels. This probably explains why my mcepg2-0.db file is so huge. I would suspect that most other people setup their tuners and leave them be, so their mcepg.db file are much smaller. This probably explains why I have been having this problem and not others. Now I have to figure out how to edit or replace this huge mcepg2-0.db file. Does anybody know how to edit this file?

[garyan2]

Sorry, that file is not just your tuners, it is your tuners, your guide, your favorite lineups, your scheduled recordings, your recording history... 500MB isn't too unreasonable.

If you think it is that file, you can run "START /WAIT c:\windows\ehome\mcupdate.exe -uf -dbgc" to run a garbage collector. This client maintenance is supposed to be run every 5 days by WMC, but if you turned it off or it is not working, your db will become less efficient.

[TGBFAN]

but if you turned it off

Gary, where would one turn the "automatic every-five-day garbage collection" on or off?

[redmed]

Gary you the Man! T H A N K S
I created a bat file with your garbage collector script and mcepg2-0.db dropped from over 500,000 to 127,000 kb. The guide is much snappier now. Mcupdate.exe -uf -dbgc looks familiar from years ago. I have used mcupdate in the past. Before I ran it, I spent hours scouring the web looking for what the switches do and could not find anything. I know on a different computer in the past I had a file describing all the switches. I’m surprised that I could not find any documentation on mcupdate.

For now I scheduled the mcupdate bat file to run daily. I update the guide three times a week Sunday, Tuesday and Thursday and have scheduled mcupdate to run separately after the guide load time. I’m pretty sure you expected me to add the mcupdate to the guide load bat file with the Wait command. Is it better to run mcupdate before a guide load or after? Should I schedule mcupdate once a week or daily?

[garyan2]

Below are the switches for mcupdate.exe. You should not run this on a schedule. It can take some time to complete and could interrupt any recordings in progress. The equivalent to this should be run automatically by your WMC every 5 days as "Client Maintenance". I would only run it manually when you see there may be an issue, otherwise let it be.

[garyan2]

but if you turned it off

Gary, where would one turn the "automatic every-five-day garbage collection" on or off?

I think I knew this at one point, but I don't recall right now. I thought it was a task in the task scheduler, but a quick scan didn't pop it out for me. Maybe someone else can answer more quickly than I.

[garyan2]

but if you turned it off

Gary, where would one turn the "automatic every-five-day garbage collection" on or off?

I believe it is the mcupdate_scheduled task. When it runs, it will look at a registry entry to determine the last time the client maintenance was run. If it was 5 days or more, it will perform the maintenance.

[TGBFAN]

This is the only task I can find:

%SystemRoot%\ehome\mcupdate -crl -hms -pscn 15

Do these arguments include running the every-five-day garbage collection, or do I need to create a new (additional) task?

[stuartm]

I believe it is the mcupdate_scheduled task. When it runs, it will look at a registry entry to determine the last time the client maintenance was run. If it was 5 days or more, it will perform the maintenance.

I think that is right. I have 3 HTPCs and on one of them I had disabled that task and on that machine the DB grew to > 1 gig and the guide got a little sluggish, on the other 2 machines the DB stayed at about 500 meg and performance was fine. It's a bit of a shame that task has to run every day just to run a DB garbage collect every 5 days, as it wakes up the PC to do it. Might be worth disabling it and making a separate task that just does the GC every 5 days.

[Space]

I've run, pretty much from day one, three tasks to do the updates and the garbage collection.

I wanted the updates to happen at a specific time and the garbage collection to happen at another specific time of the day (because it took much longer to run), so I set it up to do so.

Since the update task was controlled by WMC, I was unable to set it to run at a specific time, so I did it this way...

I disabled the update tasks "wake up" ability and then set a second task who's sole purpose was to wake up the machine at a specific time.

I was not usually using WMC (or recording) during the morning hours, so I set the update task (using the setting within WMC) to run between 7am-noon (a time period when my machine was usually sleeping). Then I set another task to wake up the machine around 7:30pm. The update task would then run exactly at 7:30pm as it would realize that it missed it's regular time and run immediately when the machine woke up.

The separate garbage collection task I just had run every 5 days at 4pm (it usually took about an hour or so).

Now that I am using EPG123, I have gotten rid of the two tasks that did the update and woke the machine and just use the garbage collection task.

[redmed]

It's been four days since I ran the garbage collection and the guide display is still fast! Thanks Gary!

Something I have noticed the last few months is that after a guide load i will do a "view scheduled" and see what the last day scheduled is. Then open the guide for the first time and the guide will not display the last day that shows with "view scheduled". It will be a day or two short. I will then close the guide and then open the guide for the second time then the guide will show the same last day that showed in "view schedule". There was a difference I've never seen before after this tuesday morning load. The "view scheduled" showed the schedule until 5\11 but the guide would only show up to 5\10 no matter how many times I open & closed the guide. This had me worried that the garbage collection did not go as smoothly as I had thought. But this morning after the thursday load the "view schedule" showed the schedule until 5\13. The first open of the guide only went to 5\12 but the second time I opened the guide it opened to 5\13 matching the schedule again. Does opening the guide trigger additional guide processing?

[rimmel]

I have a new windows7/WMC build and when the mcupdate_scheduled task (mcupdate -crl -hms -pscn 15) runs it returns in the event log the message "The MCEClientMaintenance package is not available". I can still do garbage collection by running mcupdate from the command line with the -dbgc switch. I have an older build that runs client maintenance fine off the mcupdate_scheduled task. On both systems the mcepg2-0.db is under 500 megs and the guides load pretty fast. Does any one know how to make this package available?

[stuartm]

It's been four days since I ran the garbage collection and the guide display is still fast! Thanks Gary!

You will need to make sure you have a scheduled task enabled to periodically do the garbage collection or it will eventually degrade again. Either via the mcupdate_scheduled task WMC created or by adding a task yourself.

[TGBFAN]

This is the only task I can find:

%SystemRoot%\ehome\mcupdate -crl -hms -pscn 15

Do these arguments include running the every-five-day garbage collection, or do I need to create a new (additional) task?

Gary, my mcupdate_scheduled task (which has never been altered or edited) does not contain "-dbgc" or "-uf"

How is the every-five-day garbage collection accomplished without these switches included in the mcupdate_scheduled task?

[stuartm]

Running mcupdate with these arguments causes mcupdate to check the registry(as Gary described above) and if it has not run a garbage collect in 5 days it then will do a garbage collect. Presumably by spawning an additional mcupdate with the appropriate arguments.