Please remember: XMLTV import plugin will try to import tvguile.xml once its "modified date" changes. If you have your grabber write the file directly to the xmltv directory, XMLTV import plugin will start importing before the grabber finishes writing to the file (which means it may try to import a partial or even empty file). As a result, grabbing to a temporary file and then moving the file to the proper location (xmltv directory) is MANDATORY.
That is usually the best choice, unless ofc the xmltv grabber already incorporates such a feature. For example WebEPG inherently writes the new tvguide.xml in a temporary file. When finished, it deletes the original tvguide.xml and renames the temporary file to tvguide.xml. This way the change is instant (even copying can be caught in the middle if the file is to big, not to mention that copying is inefficient).How can I add this extra deployment step to my grabber process? I am currently using a task scheduler task to trigger the console version of xmltv gui. I guess I could change the task to run a batch file, but it all seems quite clumsy.
That could cause a lot of issues. Off the top of my head: if tvguide.xml resides in a location where xmltv import plugin has read-only access, it will never be able to get a write lock. Also a write lock requires opening the file in write mode which would essentially change its modified time. There are probably other issues that would surface should we implement this idea.My preference, though, would be for the XMLTV import plugin to wait (and keep retrying) until it could get an exclusive write lock on the entire file. This would ensure that the grabbers had finished before the plugin starts to read in the file.
Ok, but there must be some way to wait until the grabber has finished, like opening it in exclusive read mode as detailed here: http://stackoverflow.com/questions/685135/open-file-in-exclusive-mode-in-c-sharpThat could cause a lot of issues. Off the top of my head: if tvguide.xml resides in a location where xmltv import plugin has read-only access, it will never be able to get a write lock. Also a write lock requires opening the file in write mode which would essentially change its modified time. There are probably other issues that would surface should we implement this idea.My preference, though, would be for the XMLTV import plugin to wait (and keep retrying) until it could get an exclusive write lock on the entire file. This would ensure that the grabbers had finished before the plugin starts to read in the file.