So in summary:
You are using version 1.6 of mc2xml, so you are, and have always been, using the XMLTV method in MC, running mc2xml as an external program, and importing the resulting XMLTV file into MC. (I do the same, but with "EPG Collector" instead of mc2xml.)
If I was you, I would explicitly specify all the information that mc2xml needs since you are running it externally, as per Yaobing's post:
-c us -g "<zipcode>" -o "C:\MC2XML\xmltv.xml" -D "C:\MC2XML\mc2cml.dat" -U
As you are running a program external to MC, even though it is a version of mc2xml, you need to give it all information it needs. So add in the -g parameter. It also makes far more sense to explicitly point to the correct dat file, and the correct output location for the xml file.
Just do it.And even more puzzling - Why did it work (without the -g switch) on the 11th, 12th, and 13th, then failed on the 14th?
I guess for now, I have created a Windows Scheduled Task that runs mc2xml and creates xml file at 3:15am. I set MC to only load data from file at 3:30am (do not run executable).
How long does mc2xml take to run? You have it starting at 3:15 am, and then importing the resulting file at 3:30am, now that you are running using Task Scheduler. Are you sure that it
always takes less than 15 minutes? My "EPG Collector" runs can take anywhere from 5 to 55 minutes, mostly depending on whether there have been many changes, but sometimes it just takes longer, usually once a week.
What do you think would happen if MC started importing the mc2xml.xml file before mc2xml finished running? I would think it would produce unexpected results. The xmltv.xml file is written as the last step in the mc2xml process, I believe, overwriting the previous version. It uses a temporary xml file until it is finished, and then does the overwrite. So if mc2xml is still being run when MC starts its import, MC would import the existing old xmltv.xml file.
What I don't understand is why it worked (without the -g option) for so many months/years... Then I do a complete uninstall of MC (including registry), re-install MC and restore library backup plus do manual tv settings from scratch, and suddenly it stops working!?
mc2xml is a "Black Box" piece of software, and while there is a bunch of information about how it works, not all is known. If it was working without the -g parameter explicitly being set before, it was getting it from somewhere. If you don't specify where to find the dat file, mc2xml just look in the same directory as the executable file, because that is where it is saved by default when it is created. That is why it works for many people. However, the dat file does seem to get corrupted at times, and if it is corrupted, mc2xml reports errors but may still look elsewhere. For example, in the registry. So when you did a complete uninstall of MC including the registry, a default -g parameter created by MC may have been deleted. You did a lot of setup when you first started using MC for TV. You could have easily tried the internal version of mc2xml (version 1.4), which could have written the parameter to the registry. Now that fallback parameter is gone, so mc2xml needs the parameter explicitly assigned.
MC runs an external program correctly every time for me. Using that method ensures that the mc2xml run finishes before the import process starts. Not specifying the -g parameter means that mc2xml must either be assuming a value, or getting it from the registry or elsewhere. When a new week of EPG data is added at the source, mc2xml may take some extra time to finish, breaking your current process. Or maybe when the -g parameter isn't specified, mc2xml does some additional checks every few days, delaying the process.
Put the mc2xml run back into MC, extend the "Timeout minutes" to 60, and explicitly specify all parameters that the external version of mc2xml you are using needs, into the command line parameters for mc2xml in MC. Check if that always works, then if you like, experiment with reducing that timeout to a shorter value.
