Sorry for the late response. Thanks for doing the modification time check
It seems we are in the same boat and this is the normal way of windows file handling afaik. The usual file handling is open-write-close and modification time gets updated after close. Seems NPVR deviates from the standard. That should imply Comskip can't detect if a recording is ongoing if using Media Portal and DVBViewer as PVRs. Every recording status check returns as finished. It's here the recording engine behaviour comes into play. The inner workings of the DVBViewer recording engine is as follows:
"The whole file writing is threaded. If the disk load is too high and the data isn't written fast enough it might be buffered internally and written later."
That should mean as soon as Comskip starts to TS liveprocess, the file writing of DVBViewer stops (cuz load increases). This causes Comskip to think the recording is finished and close too early, because modification time check returns static. Comskip is probably coded to interpret a static modification time as recording is finished. It may be Media Portal uses a similar recording behaviour.
So, using timestamps as status indicator if recording is ongoing or finished simply isn't possible, because we have these file handling differences between our PVR softwares. Instead a common denominator has to be choosen, which regardless of PVR software behaves the same. The only one that springs to my mind would be filesize. Filesize never stays static if the recording is ongoing and if Comskip constantly monitor the filesize within a sensible timedelta, that would be the optimal recording-status-indicator, which would if still growing force Comskip to, regardless of threaded writing and write pause during high diskload, keep up and finish the liveprocessing properly.
We'll see what Erik comes up with. After all the Media Portal and DVBViewer PVRs has a huge amounts of users that would be very happy if Comskip liveprocessing of TS files could work alright.