Systemhadbeenworkingfineformonthswhenon10/18/20theloadstartedtofail. WhenImanualranit, afteritloadedthemxffileintothedatabase, WMCwouldgeneratedapopupsayingthatmcupdatehadfailed. TheoutputfromEPGCwouldshowNOerrors. Ihadbeenrunningfixpack24, butIupgradedto27andthatdidn't fix the problem. What I found was that guide was being updated, but the scheduling was messed up. Mcupdate.exe would run for hours until I killed it, and WMC would only schedule 14 of 96 shows.Afterspendingahugeamountoftimetrackingdowntheerrorandpossiblesolutions, Idiscoveredthatthemxffilewasfine. TheproblemwaswhenEPGCrantheWMCtasksafterimportingthexmffile. OnceIturnoffthe"run standard tasks after import"feature, EPGCwouldloadthefile, andexitwithouterror, Icouldthenstartupthetwodatabasetaskwithouterror(IdoPvrSchedulefirst, thenDoReindexSearchRoot). Mcupdatewouldthencorrectlydotheupdate(finishin5minutesorso)andschedulealloftheshows.
Fromerrorrun
LoadMXF message: Loading... 98%
LoadMXF message: Loading... 100%
Windows Media Centre import utility LoadMXF has completed: exit code 0
Running Windows Media Centre standard task 'Private job reindex'
Windows Media Centre standard task has started
Running Windows Media Centre standard task 'WMC update PVR schedule'
Windows Media Centre standard task has started
<c> Finished - output 6064 EPG entries
<c> Exiting with code = 0</c></c>
What happens if you run the 2 database tasks in the same order as EPGC ie reindex then PVR schedule. Does that fail?
Steve
From: Carl Fosler [mailto:crf@users.sourceforge.net]
Sent: Tuesday, 20 October 2020 7:18 p.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] mcupdate.exe crashing when running standard tasks after import
Steve,
System had been working fine for months when on 10/18/20 the load started to fail. When I manual ran it, after it loaded the mxf file into the database, WMC would generated a popup saying that mcupdate had failed. The output from EPGC would show NO errors. I had been running fixpack 24, but I upgraded to 27 and that didn't fix the problem. What I found was that guide was being updated, but the scheduling was messed up. Mcupdate.exe would run for hours until I killed it, and WMC would only schedule 14 of 96 shows.
After spending a huge amount of time tracking down the error and possible solutions, I discovered that the mxf file was fine. The problem was when EPGC ran the WMC tasks after importing the xmf file. Once I turn off the "run standard tasks after import" feature, EPGC would load the file, and exit without error, I could then start up the two database task without error (I do PvrSchedule first, then DoReindexSearchRoot). Mcupdate would then correctly do the update (finish in 5 minutes or so) and schedule all of the shows.
From error run
LoadMXF message: Loading... 98%
LoadMXF message: Loading... 100%
Windows Media Centre import utility LoadMXF has completed: exit code 0
Running Windows Media Centre standard task 'Private job reindex'
Windows Media Centre standard task has started
Running Windows Media Centre standard task 'WMC update PVR schedule'
Windows Media Centre standard task has started
<c> Finished - output 6064 EPG entries
<c> Exiting with code = 0</c></c>
Try doing what Carl did and don't get EPGC to run the WMC task. Run them
manually after EPGC finishes.
From: Guy M [mailto:fluxtx@users.sourceforge.net]
Sent: Wednesday, 21 October 2020 11:44 a.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] mcupdate.exe crashing when running
standard tasks after import
Hey Steve,
Having the same issue here. WMC also immediatly crashes if I try to record,
add scheduled recording, or cancel a scheduled recording.
I did a complete ehome folder wipe and WMC reinstall, and the issue remains.
Oh, and it started immediatly after an EPGC run. My guess is there is some
malformed data in the zap2xml download...
Anyway, I just wanted to provide some additional data from my side.
HerethecommandsI'm using. I'mprettysurethatEPGCdoesn't do the "/WAIT", but it not clear if it makes a difference. On my system, the Schedule only takes a minute or two, but the Indexing can take 5 to 10 minutes.START/WAIT%SystemRoot%\ehome\mcupdate.exe-PvrScheduleSTART/WAIT%SystemRoot%\ehome\ehPrivJob.exe/DoReindexSearchRootBTWSteve, onfailure, mcupdate.exewillscheduleafewprograms, butthenseemstogointoaloop, takingup50%ofmycpucycles. Afterkillingmcupdate.exe, redoingthepvrandindexing(inthereverseorder)doesnotfixtheproblem. TheonlywaythatIfoundtofixtheproblemwastorebuildtheWMCdatabase(viaepg123utility).
Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Carl - I also noticed a 'loop' of sorts, the task scheduler's 'PvrRecoveryTask' appeared to run over and over again continuously... I adjusted the task to stop it from doing that - but that appears to be the reason for my 'recording' difficulties (and maybe even the mcupdate crashes?). After setting it back to original config, it 'looped' for a while, but then eventually stopped on its own, and I was able to set recordings again.
BTW, this is what sent me down the rabbit hole in the first place (along w/ seeing the mcupdate failure popups) - I went to 'Scheduled Recordings' and wasn't able to navigate the list (kept hearing the WMC scrollover sound and focus kept being switched to the menu) - this stopped when I stopped 'PvrRecoveryTask'.
Steve - Carl's steps appear to work after undoing my change to the 'PvrRecoveryTask'. Note that I am on my second iteration of a full WMC reset (not including EPG123 instigated "resets" and my own separate hamfisted attempts at various 'fixes'). That is to say I manually added back the channels and scheduled recordings (wasn't sure if I could simply load just that one file back from the 'mcupdate -b' without also doing the lineup and subscriptions as well).
What I should have done initially is slow down and take a look here first, then patiently go from there...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Carl or Guy - can I have a look at the EPGC log when you try it with EPGC running the tasks.
Looking at the code EPGC first tries to run ehPrivJob.exe /DoReindexSearchRoot (without the wait). If that fails to run then it tries to run the same job again but uses Task Scheduler this time using schtasks.exe /run /tn etc etc.
It does the same for mcupdate pvrschedule.
So I'm wondering if, for some reason, the first attempt indicates it failed even though it may not have and the job is initiated again using Task Scheduler.
Anyway the log should show what is happening.
In the meantime just don't use EPGC to run these tasks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Inmyinitialposting, Iincludethelastlinesofthelogofarunthatfailed, initEPGCisdoingthetwotasks. Ican't see any errors being return. EPGC only takes two minutes to run my configuration, the DoReindexSearchRoot takes 4 or 5 when I start it, so EPGC can'tbedoingawaitonthatjob, soitreturncodewouldn't reflect any error condition.OK, theorderofthetwotasksmightnotbethemainproblem. WhenIfirstdiscoveredtheproblem, Iwaspulling14daysofshows, buttosimpifymydebugging, Ireduceditto7days. Itwaswithonly7daysthatIfoundswitchingthetaskorderworked. OnceIwhenbackto14days, Idiscoveredthatevenwiththechangeorder, theproblemcameback. Aftermuchwork, IwasabletofigureoutthatitdatafromNovember1thatcausingtheproblem. IwasabletoloaddatatoNov11:00amwithoutaproblem, butwhenItryupto2:00am, thenthemcupate.exeproblemshowsup. Iloadedthe2:00amload, butdidn't start the two tasks. I then pulled up the guide. What I found was that 14 channels showed data, 4 channels showed "NO data available", and 9 channels show only the blue background. To me, it looks like there something wrong with the guide entries, and once the schedule starts running, it finds the corrupted guide and can only match a few programs.Atfirst, IthoughtthattheNovermber1datewastheproblem, butIfoundthatitwouldloadtheschedulewhentherewere10midnightshows.
Ihaveattachedthexmltvfilewiththeerror. IhavelookedattheentriesforNovember1, butIcan't see anything wrong with them, maybe a binary character?Carl
Nov 1st you say? Then likely a glitch having to do with the handling of "daylight saving time." Conflicting timestamps or the like? This lines up with Friday's DL working here then Mon's DL causing the issue, which included Nov 1st. Bet I wouldn't have seen any issue at all if my DL was Tue or Wed instead of Monday - in fact, my currently working 14-Day DL is from Wed the 21st.
Wish I still had Monday's xml or mxf to take a look at, alas they have been overwritten. Maybe Carl still has his?
I am back to getting 14 days (w/ manual end tasks), and WMC is running great. Keeping my hands off it for the time being...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Additional note, if I go into the guide in WMC and advance to the Nov1 1AM area, the guide gets glitchy- sporadically showing no data for some channels through the entire schedule, but resolves when I close and reopen the guide within WMC. And just like the zap2it web site, it has 12:30AM-1AM-1:30AM-1AM-1:30AM-2AM (reflecting the 1hr gain from DST).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mine quit updating when the scheduled update ran on Monday as well. WMC had the same message that the update failed. I ran the EPG Collector manually, the listings were populated, but it stopped at the line "LoadMXFmessage: Loading...99%". It never completed. If I close the program manually, the listings dissapeared and the WMC message is displayed again. I ran the TPG Collector again with the same results. So this time I just minimized the program so the listings would be saved. It also kills scheduled recordings except manually created ones when the listings are not there. Steve's program was working flawlessly since March. I will close the window Sunday night and see what happens when the scheduled update happens on Monday. The update worked fine on another computer of mine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like Guy is right, is something to do with DST.
Here are two "Paid Programming" entrie from the bad xml file. Note that the stop date/time is before the start. The problem is that EPGC generates a negative duration in the mxf file (see ScheduleEntry down at the bottom). In looking at the bad mxf file, I find 8 -1800 durations, all that start at 05:30 or 05:32. I see other with 0 durations, but I'm guessing they don't cause a problem. I think all the times from zapit are in GMT, I'm in Eastern, so 4 hours off GMT.
Actually thinking about it there will be a problem when you go back the other way in 6 months time. The durations over the change will all be 1 hour too long.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The program tag might be the answer as it has the time offset from GMT. Adjusting the duration by the start time offset - the end time offset would work.
In your example above -4 - -5 will add an hour to the duration and in 6 months time -5 - -4 will reduce the duration by an hour.
I'll take a look at changing the code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure how WMC does/would handle it, but maybe if its <0 (i.e. negative) just make the duration 0?? Then only the offending entries are affected? Or maybe only do the offset fix if the offsets differ? Bah, if the offsets are the same, the formula will equal zero anyway - so not the best input from me :)
Last edit: Guy M 2020-10-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been using EPGC before DST in the spring and it didn't blow up then, so I'm guessing that EPGC added an extra hour in the spring and WMC was able to handle it. It only shown a problem now since we lose an hour and for 30 minute shows, the duration goes negative. I'm guessing that that why the GMT offset is included in the program tag, it only needed twice a year. There are some area of the US where DST doesn't exist, so I'm guessing that zap2it handles that via the GMT offset.
Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Iwhenandhandeditthemxffile, changedthe-1800to1800. Thenloadeditwithloadmxf, butIgotthemcupdateerror. Iwhenandpulluptheguide, andInowseetheguidedisplay12:30, 1:00, 1:30, 1:00, 1:30, 2:00amalongthetopforNov1. Halfoftheprogramsareloadedinthefirst1:00am, thesecondhalfareloadedinthesecond1:00slot. Themissingdataisfilledwith"No data available", andtherestoftheguideisfilledout. Thescheduleismessedup, sothatdidn't fix all of the problems.Iguessyoudon't have DST down there, so this is something that doesn'thappentoyou.
Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, Iwasrightandwrong. Imadeanotherattemptbyhandeditingthemxffile, thistimeIdeletealltheScheduleEntrywiththe-1800values, andIalsofoundanumberofentrieswithdurationof"0", whichIdeletedaswell. ALLofScheduleEntryfortheshowsintheDSTzonearenowgoneandthenreloadedit. Thistimeitloadedwithouterror, andIdidn't get an mcupdate error. When I look at the guide, all the shows in the DST zone are "no data available", and the guide for the next couple of days loaded as well. I can see programs scheduled for Nov 1 and after, so in my mind, it was successful, and an indacation that the problem is with DST entries.Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been having a problem with sourceforge drop the connect to me. I will try to load the mxf file that generated with the version that you just posted.
Yes it looks like my change doesn't work in the real DST situation even though it didn't generate any -ve or zero durations when I tested it with your zap2 file here. They are still there in the mxf file you just posted.
I'll take another look.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve,
LoadMXF message: Loading... 98%
LoadMXF message: Loading... 100%
Windows Media Centre import utility LoadMXF has completed: exit code 0
Running Windows Media Centre standard task 'Private job reindex'
Windows Media Centre standard task has started
Running Windows Media Centre standard task 'WMC update PVR schedule'
Windows Media Centre standard task has started
<c> Finished - output 6064 EPG entries
<c> Exiting with code = 0</c></c>
Carl
Hi Carl,
What happens if you run the 2 database tasks in the same order as EPGC ie reindex then PVR schedule. Does that fail?
Steve
From: Carl Fosler [mailto:crf@users.sourceforge.net]
Sent: Tuesday, 20 October 2020 7:18 p.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] mcupdate.exe crashing when running standard tasks after import
Steve,
System had been working fine for months when on 10/18/20 the load started to fail. When I manual ran it, after it loaded the mxf file into the database, WMC would generated a popup saying that mcupdate had failed. The output from EPGC would show NO errors. I had been running fixpack 24, but I upgraded to 27 and that didn't fix the problem. What I found was that guide was being updated, but the scheduling was messed up. Mcupdate.exe would run for hours until I killed it, and WMC would only schedule 14 of 96 shows.
After spending a huge amount of time tracking down the error and possible solutions, I discovered that the mxf file was fine. The problem was when EPGC ran the WMC tasks after importing the xmf file. Once I turn off the "run standard tasks after import" feature, EPGC would load the file, and exit without error, I could then start up the two database task without error (I do PvrSchedule first, then DoReindexSearchRoot). Mcupdate would then correctly do the update (finish in 5 minutes or so) and schedule all of the shows.
From error run
LoadMXF message: Loading... 98%
LoadMXF message: Loading... 100%
Windows Media Centre import utility LoadMXF has completed: exit code 0
Running Windows Media Centre standard task 'Private job reindex'
Windows Media Centre standard task has started
Running Windows Media Centre standard task 'WMC update PVR schedule'
Windows Media Centre standard task has started
<c> Finished - output 6064 EPG entries
<c> Exiting with code = 0</c></c>
Carl
mcupdate.exe crashing when running standard tasks after import https://sourceforge.net/p/epgcollector/discussion/1125946/thread/6f429cfa3c/?limit=25#98a0
Sent from sourceforge.net because stevebickell@xtra.co.nz is subscribed to https://sourceforge.net/p/epgcollector/discussion/1125946/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/epgcollector/admin/discussion/forums. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Hey Steve,
Having the same issue here. WMC also immediatly crashes if I try to record, add scheduled recording, or cancel a scheduled recording.
I did a complete ehome folder wipe and WMC reinstall, and the issue remains.
Oh, and it started immediatly after an EPGC run. My guess is there is some malformed data in the zap2xml download...
Anyway, I just wanted to provide some additional data from my side.
Try doing what Carl did and don't get EPGC to run the WMC task. Run them
manually after EPGC finishes.
From: Guy M [mailto:fluxtx@users.sourceforge.net]
Sent: Wednesday, 21 October 2020 11:44 a.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] mcupdate.exe crashing when running
standard tasks after import
Hey Steve,
Having the same issue here. WMC also immediatly crashes if I try to record,
add scheduled recording, or cancel a scheduled recording.
I did a complete ehome folder wipe and WMC reinstall, and the issue remains.
Oh, and it started immediatly after an EPGC run. My guess is there is some
malformed data in the zap2xml download...
Anyway, I just wanted to provide some additional data from my side.
mcupdate.exe crashing when running standard tasks after import
https://sourceforge.net/p/epgcollector/discussion/1125946/thread/6f429cfa3c /?limit=25#dcec
Sent from sourceforge.net because stevebickell@xtra.co.nz is subscribed to
https://sourceforge.net/p/epgcollector/discussion/1125946/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/epgcollector/admin/discussion/forums. Or, if this
is a mailing list, you can unsubscribe from the mailing list.
Steve,
Guy,
Carl
Carl - I also noticed a 'loop' of sorts, the task scheduler's 'PvrRecoveryTask' appeared to run over and over again continuously... I adjusted the task to stop it from doing that - but that appears to be the reason for my 'recording' difficulties (and maybe even the mcupdate crashes?). After setting it back to original config, it 'looped' for a while, but then eventually stopped on its own, and I was able to set recordings again.
BTW, this is what sent me down the rabbit hole in the first place (along w/ seeing the mcupdate failure popups) - I went to 'Scheduled Recordings' and wasn't able to navigate the list (kept hearing the WMC scrollover sound and focus kept being switched to the menu) - this stopped when I stopped 'PvrRecoveryTask'.
Steve - Carl's steps appear to work after undoing my change to the 'PvrRecoveryTask'. Note that I am on my second iteration of a full WMC reset (not including EPG123 instigated "resets" and my own separate hamfisted attempts at various 'fixes'). That is to say I manually added back the channels and scheduled recordings (wasn't sure if I could simply load just that one file back from the 'mcupdate -b' without also doing the lineup and subscriptions as well).
What I should have done initially is slow down and take a look here first, then patiently go from there...
Carl or Guy - can I have a look at the EPGC log when you try it with EPGC running the tasks.
Looking at the code EPGC first tries to run ehPrivJob.exe /DoReindexSearchRoot (without the wait). If that fails to run then it tries to run the same job again but uses Task Scheduler this time using schtasks.exe /run /tn etc etc.
It does the same for mcupdate pvrschedule.
So I'm wondering if, for some reason, the first attempt indicates it failed even though it may not have and the job is initiated again using Task Scheduler.
Anyway the log should show what is happening.
In the meantime just don't use EPGC to run these tasks.
Steve,
Nov 1st you say? Then likely a glitch having to do with the handling of "daylight saving time." Conflicting timestamps or the like? This lines up with Friday's DL working here then Mon's DL causing the issue, which included Nov 1st. Bet I wouldn't have seen any issue at all if my DL was Tue or Wed instead of Monday - in fact, my currently working 14-Day DL is from Wed the 21st.
Wish I still had Monday's xml or mxf to take a look at, alas they have been overwritten. Maybe Carl still has his?
I am back to getting 14 days (w/ manual end tasks), and WMC is running great. Keeping my hands off it for the time being...
Additional note, if I go into the guide in WMC and advance to the Nov1 1AM area, the guide gets glitchy- sporadically showing no data for some channels through the entire schedule, but resolves when I close and reopen the guide within WMC. And just like the zap2it web site, it has 12:30AM-1AM-1:30AM-1AM-1:30AM-2AM (reflecting the 1hr gain from DST).
Mine quit updating when the scheduled update ran on Monday as well. WMC had the same message that the update failed. I ran the EPG Collector manually, the listings were populated, but it stopped at the line "LoadMXFmessage: Loading...99%". It never completed. If I close the program manually, the listings dissapeared and the WMC message is displayed again. I ran the TPG Collector again with the same results. So this time I just minimized the program so the listings would be saved. It also kills scheduled recordings except manually created ones when the listings are not there. Steve's program was working flawlessly since March. I will close the window Sunday night and see what happens when the scheduled update happens on Monday. The update worked fine on another computer of mine.
Steve,
Looks like Guy is right, is something to do with DST.
Here are two "Paid Programming" entrie from the bad xml file. Note that the stop date/time is before the start. The problem is that EPGC generates a negative duration in the mxf file (see ScheduleEntry down at the bottom). In looking at the bad mxf file, I find 8 -1800 durations, all that start at 05:30 or 05:32. I see other with 0 durations, but I'm guessing they don't cause a problem. I think all the times from zapit are in GMT, I'm in Eastern, so 4 hours off GMT.
Carl
I wonder if it would be OK to just add 1 hour to the duration if it is not > 0?
Actually thinking about it there will be a problem when you go back the other way in 6 months time. The durations over the change will all be 1 hour too long.
The program tag might be the answer as it has the time offset from GMT. Adjusting the duration by the start time offset - the end time offset would work.
In your example above -4 - -5 will add an hour to the duration and in 6 months time -5 - -4 will reduce the duration by an hour.
I'll take a look at changing the code.
Not sure how WMC does/would handle it, but maybe if its <0 (i.e. negative) just make the duration 0?? Then only the offending entries are affected? Or maybe only do the offset fix if the offsets differ? Bah, if the offsets are the same, the formula will equal zero anyway - so not the best input from me :)
Last edit: Guy M 2020-10-23
I have been using EPGC before DST in the spring and it didn't blow up then, so I'm guessing that EPGC added an extra hour in the spring and WMC was able to handle it. It only shown a problem now since we lose an hour and for 30 minute shows, the duration goes negative. I'm guessing that that why the GMT offset is included in the program tag, it only needed twice a year. There are some area of the US where DST doesn't exist, so I'm guessing that zap2it handles that via the GMT offset.
Carl
Try the attached version.
It creates the correct duration for programmes over the DST change.
Steve,
Steve,
Carl
Are you saying the MXF file still had negative durations in the schedule entries with the version I posted above.
It didn't when I tried the new version with the xml file you first posted.
We do use DST - changed to summertime about 3 weeks ago.
Steve,
I have been having a problem with sourceforge drop the connect to me. I will try to load the mxf file that generated with the version that you just posted.
Steve,
Here my log file from my run.
Carl
Yes it looks like my change doesn't work in the real DST situation even though it didn't generate any -ve or zero durations when I tested it with your zap2 file here. They are still there in the mxf file you just posted.
I'll take another look.