Normal
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). 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.
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).
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.
