WMC loadmxf.exe error on import

[garyan2]

Everyone,

I'm getting quite a few reports of loadmxf.exe failing to import updated guide listings with database errors. I've been running an experiment from when I got these first reports and it appears that since the MS servers are no longer online, the client maintenance package is not being downloaded and the database cleanup is no longer being run every 5 days as it was before. In fact, my experiments have shown that it never runs. Until I have something in place to take care of this for everyone, I would advise users to run the following from a command prompt at least once a week.

Code: Select all

start /wait c:\windows\ehome\mcupdate.exe -uf -dbgc

The first part (-uf) really won't do anything, but the -dbgc will perform a database garbage cleanup and should avoid the errors we have been seeing.

Stay tuned.

[Space]

From almost day one I had set up a separate task to run the garbage collection every 5 days at a specific time of the day. I did this because I wanted to control when things happen on my system instead of WMC controlling when they happen.

If I recall correctly, the daily update that is scheduled by WMC will normally do a regular guide update and automatically determine if it has been 5 days since the last garbage collection, and if it has, will run the garbage collection before it does the update.

Of course, now the update never happens due to the server being down/gone, but I guess it also somehow interferes with the garbage collection running every 5 days.

[garyan2]

Okay, running some code on trials right now, but EPG123 will use the registry to track when the database cleanup needs to run. It will also disable the option to "Automatically download Windows Media Center data" option in WMC settings. This is to avoid competing tasks to perform the client maintenance in case the user still has a valid functioning client maintenance package from before MS shutdown their server. Every fifth guide listings update from EPG123 will perform the database cleanup before the guide listings import.

Since it will be tied to when the client imports the MXF file on the scheduled task, you will still have control of when it happens.

[Space]

I currently have my system set to run client maintenance (garbage collection) every 5 days at 4pm. I have EPG123 set to run/import the MXF at 15 minutes before prime-time every day. I do not want maintenance to run 15 minutes before prime-time as that would have it running while I'm recording (it takes about an hour to run maintenance).

Since I already have a task that does the garbage collection, would it be possible to keep this task and disable this function in EPG123?

[garyan2]

That's part of the trial runs I'll be running. It looks like running garbage cleanup while watching TV is not an issue that I have been able to detect yet. If recording, it will still delay the import... don't know about GC though (depends on trial results). I know you love having a dial to tweak for everything, Space, but we'll see how everything turns out.

It appears that there were no restrictions on when the GC ran for WMC when left to handle it by itself, but I need to verify.

[Bunk_Tuppins]

I started having a problem yesterday which I thought was related to this but now I am not so sure. Seeing this, I ran the command line command as suggested and it finished after about 40 minutes. However I am still experiencing the problem: it gets to build schedules, stage I and almost immediately stops executing and epg123 quits. No update occurred. ???

[6/15/2020 3:58:58 AM] Exiting buildLineupServices(). SUCCESS.
[6/15/2020 3:58:58 AM] Entering getAllScheduleEntryMd5s() for 21 days on 16 stations.
[6/15/2020 3:58:59 AM] [ INFO] Successfully retrieved Md5s for 16 station's daily schedules. (0:00:00:00.8268015 / 29.456 KB)
[6/15/2020 3:59:11 AM] [ERROR] SD API Unknown exception thrown. Message: Unable to read data from the transport connection: The connection was closed.
[6/15/2020 3:59:11 AM] [ERROR] Did not receive a response from Schedules Direct for 16 station's daily schedules. (0:00:00:03.4788061)
[6/15/2020 3:59:11 AM] [ERROR] Problem occurred during getMd5ScheduleEntries(). Exiting.
[6/15/2020 3:59:11 AM] [ERROR] Failed to create MXF file. Exiting.
[6/15/2020 3:59:11 AM] [ INFO] epg123 update execution time was 00:00:15.4596271.

[Space]

This does not appear to have anything to do with the WMC database. It seems to be an issue with Schedules Direct, probably a temporary one. I would suggest to just try again after the problem is fixed (there are some other posts today regarding issues with SD).

[Bunk_Tuppins]

You are right, Space. I tried again just now and it has got past that point and appears to be running through to completion. Something must have been down at Schedules Direct.

[rimmel]

About 6 weeks ago we discussed this topic in the Windows 7 Media Center forum under the topic "The MCEClientMaintenance Package is not available". The bottom line is that on a fresh OS install done after the end of January 2020 when Microsoft turned off their WMC servers there is no client maintenance package available. I have two systems one built years ago (A) and one built just recently (B) due to a hardware failure. Both have "Automatically download Windows Media Center data" turned off. System A runs client maintenance every 5 days as usual. System B just gets a message in the WMC event log that says the client maintenance package is not available. On system B I run mcupdate as you suggested with the -dbgc option every 5 days.

So this should only be happening on fresh OS installs done after the end of January 2020.

I would strongly suggest that if you put something in EPG123 to address this issue that you make it optional and default to not happen. The user would have to check a box somewhere to enable this under EPG123. That way all of the old systems that do have the client maintenance package will function as they always have. But if I build a new system (fresh OS) I can turn it on.

This brings up another issue, The current step by step procedure for installing EPG123 assumes the user is converting from Rovi to EPG123. I would also assume that everyone who is converting from Rovi to Epg123 has already done so. So shouldn't there be a new procedure for those who are starting from a fresh OS install. For instance, on a fresh OS install what is purpose of install step 1.

[garyan2]

So far, I do not agree.

There is a registry key WMC will update after a client maintenance completes to identify when to run maintenance again. WMC does not set it to 5 days in advance, rather it sets it 5 days plus a random number of hours and minutes in advance. Interesting fact, if you run "mcupdate.exe -dbgc" manually, it also will set it 5 days plus a random number of hours and minutes in advance as well as put entries in the Event Log of "Starting Client Maintenance" and "Client Maintenance has completed."

For systems that do not have the MCEClientMaintenance package, and have downloads enabled, WMC will set that registry key to 1 day plus a random number of hours and minutes in advance to next maintenance to try and download the unavailable packages again. If downloads are not enabled, then that registry key will be blank/null. Regardless of having a maintenance package downloaded or not, running "mcupdate.exe -dbgc" will provide those client maintenance event log entries.

In my test runs, I am also seeing that running -dbgc manually will invoke the maintenance package if it is available, so there is no difference between WMC natively running the client maintenance or manually running it yourself. I can only guess what the maintenance package added before, but from a reliability standpoint I do not see a difference with or without it.

So running garbage cleanup will be in the next release and it will NOT be a selectable option in the client GUI. I am the one who has to support the ~9000 users and who knows how many WMC installs, and I don't really feel like explaining every other day that the database appears corrupt, explain how to run dbgc manually, and why. That being said, I will probably have a command line switch for the client to not run garbage cleanup. It will require the user to manually edit the scheduled task to add the switch. The only folks that will care and/or notice are users like yourself and Space and I won't need to explain how to do that.

[garyan2]

This brings up another issue, The current step by step procedure for installing EPG123 assumes the user is converting from Rovi to EPG123. I would also assume that everyone who is converting from Rovi to Epg123 has already done so. So shouldn't there be a new procedure for those who are starting from a fresh OS install. For instance, on a fresh OS install what is purpose of install step 1.

Step 1 still serves a purpose. From my perspective, starting from a known condition increases the probability of success. If I don't delete the existing databases, then there will probably be those cases where data existing in the database can cause problems. Even though MS/Rovi is gone, there are still these messed-up options people are trying out/experimenting with because they are "free" that can cause issues. Even if the database only has EPG123/SD data, if the user is moving from one cable system to another, there could be problems (though there are easier ways to handle that other than the clean start).

Prior to next release, I will however review that process to get rid of stuff like downloading packages from MS (-uf) which obviously isn't needed anymore. There may be some other small items I can get rid of and might speed up the process a little.

[rimmel]

Maybe I am misunderstanding something here. Let me explain. After Microsoft shutdown their servers in late January I went to Tasks->General->Automatic Download Options and unchecked the two check boxes on that screen on my old system (A). From that day til now mcupdate no longer runs daily but every 5 days to do client maintenance and only that. I have no special started tasks or any other manual runs to account for this. I did nothing else to make this happen. There are three mcupdate entries in the Media Center Event Log every 5 days. Notice that the first event log entry (presented here) states the next run will be in 5 days. The next two entries in the event log simple state that client maintenance has started and completed respectively. So are you saying that since I unchecked the automatic download this client maintenance should not be happening at all on my old system (A)?

[garyan2]

The second checkbox controls your daily download (the first being the CD & Movie metadata that was shutdown quite a while ago), but there is still an mcupdate_scheduled task that runs to "check for media center updates." The task is set to run daily but if you look at yours, it probably says next run time is 6/21/2020 at 4:00:37 just like your event log says. Also, the registry key \\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\EPG "mcupdate:next run time" probably has the same time. If on system A you still had downloads enabled, that task will run daily but your 5 day interval for client maintenance will still be working every 5 days. If you disable that task in Task Scheduler, then you client maintenance will stop as well as your daily downloads.

So for systems with a downloaded MCEClientMaintenance package (your old system (A)), even though you disabled the downloads, the mcupdate_scheduled task will still run. When mcupdate runs, it checks that registry key to determine whether to perform maintenance or not. The result is client maintenance running around every 5 days.

For systems without the package (your new system (B)), with downloads enabled or disabled, the mcupdate_scheduled task will run daily. When it runs, it will try to download the maintenance package, fail, and never kicks of a maintenance task. The registry key is then set to 1 day +hours +minutes in the future and ends. It simply waits for the next day to try again to download the package. Running -dbgc bypasses the package download and goes straight to database maintenance.

[rimmel]

Thanks for the input Gary. I get it now. Sorry for the confusion.

[hockeyjod]

Gary, I am getting this error on updates...

[6/17/2020 5:00:21 PM] [ INFO] Error: The following error was encountered while processing the file. Aborting.
[6/17/2020 5:00:21 PM] [ INFO] RowSet::DeleteRow(Program_keywords Program_keywordsI_ParentChildKey) - DeleteRows() failed for handle 1 - HR = 0x80040e21, minor = 25104, 2049, 0, 0, "", "", ""
[6/17/2020 5:00:21 PM] [ERROR] Error using loadmxf.exe to import new guide information. Exit code: -1
[6/17/2020 5:00:21 PM] Exiting importMxfFile(). FAILURE.
[6/17/2020 5:00:21 PM] [ERROR] Failed to import .mxf file. Exiting.

I saw your post here and tried to run the command you suggested and this happens:

[garyan2]

Try without the -uf switch. I expect the same results, but never know.

Is there anything special about your setup? Looks like the error is with the mcstoredb or the database is reeeealy corrupted.

[hockeyjod]

I will try running without the -uf and see what happens. I think I disabled the mcupdate_scheduled task on 5/22/2020 (that's the last time it was run). The only thing special about my setup is that I have renumbered the majority of my channels, including assigning the same channel number to both the SD and HD versions of the channels. But I have been doing that for many years (first with GuideTool, then with epg123 when I switched in February) with no issues.

[garyan2]

Then options are few.

1) Reboot and try the command line database cleanup again. If that doesn't work,
2) Click the [Rebuild WMC Database] button in the client. It will preserve your favorites, custom numbers, and custom callsigns as well as your recording requests.

[hockeyjod]

Ran it again without the -uf with the same result. This was what I got from the problem details display:

Description:
Stopped working

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: mcupdate.exe
Problem Signature 02: 6.1.7601.24000
Problem Signature 03: 5a4995fb
Problem Signature 04: mcstoredb
Problem Signature 05: 6.1.0.0
Problem Signature 06: 4ce7c734
Problem Signature 07: ce
Problem Signature 08: 3
Problem Signature 09: System.InvalidOperationException
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid= ... cid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

[hockeyjod]

Gary, [Rebuild WMC Database] did the trick. Thank you.