Recording method

[majstang]

Hi!

 

I'm wondering about which approach the RS uses when recording transport streams? There are two ways afaik to write a recording:

Method 1: writes the recorded stream as soon as available.

Method 2: reserves big chunks of disk space (say 50 or 100 MByte) at a time and then fills the reserved space with data.

The latter approach reduces disk fragmentation.

 

regards

majstang

[Lars_MQ]

it normally uses an internal buffer and writes chunks of about 512 kb at once.

[majstang]

Thanks for the swift answer Lars, much appreciated

Got the honor to help Comskip Erik out with information about the DVBViewer recording engine. He is trying to figure out why ongoing TS files recorded with the DVBViewer system doesn't work when launching Comskip Live-TV processing on them. Comskip aborts prematurely every time after a "incomplete frame" message. The incomplete frames error message seem to point to something with the audio part in the transport stream.

 

Comskip seem to do alright with ts files recorded with other systems though. I suppose the DVBViewer recording engine doesn't do any alterations in the written stream that can provoke such a error, right? The TS stream is being read by the ffmpeg TS reader. Just asking about your opinion, since your knowledge is very vast. I don't expect any answer, thanks again

[majstang]

Ok, we found out why Comskip LiveTV detection processing works on every other recording systems producing ts recordings, but not DVBViewer ts recordings. Turns out DVBViewer recording engine busy oneself with the bad habit of NOT updating the "Modification Time" property/variable during an ongoing recording at all. The update occurs when DVBViewer finishes the recording at first. Comskip LiveTV processing are dependent on this property value getting updated continuously during a recording and when it's not, comskip aborts prematurely and fails.

 

So, the question now is, is this easy changeable? If DVBViewer recording engine writes chunks of about 512 kb at once shouldn't a Modification Timestamp update occur at end of every write interval? Perhaps this logic step has been removed to reduce CPU load?

Grateful for an answer

[Griga]

Turns out DVBViewer recording engine busy oneself with the bad habit of NOT updating the "Modification Time" property/variable during an ongoing recording at all.

DVBViewer opens the file, writes the data and closes the file. It's just normal file handling. Everything else (particularly taking care of timestamps) is up to the OS.

[Lars_MQ]

Open - write - Close changes the modification time. Changing the time with every (ongoing) write would be silly.

 

Just use the filesize to see if a file is still growing (within a sensible timedelta)...

[majstang]

Thanks for your answers guys!

 

Open - write - Close changes the modification time. Changing the time with every (ongoing) write would be silly.

 

Just use the filesize to see if a file is still growing (within a sensible timedelta)...

I'm not entirely sure why Erik uses the modification time for LiveTV processing. Although it's open source but written in a language I'm not familiar with, so I haven't looked it up He is also retrieving the filesize, but I'm sure he have good reasons for retrieving the modification time as well. Hopefully he can solve it with some workaround, we'll see.

[majstang]

Open - write - Close changes the modification time. Changing the time with every (ongoing) write would be silly.

 

Just use the filesize to see if a file is still growing (within a sensible timedelta)...

Hi Lars!

 

Erik has some questions in order to get Comskip LiveTV processing to work on DVBViewer recordings. Perhaps you could help out with some more information?

 

Could you ask the developer

 

1: What is the size of writes?

2: What would be the time to wait for the file no longer growing to be sure the recording has finished.

3: I need to find out the size of the buffer that DVBViewer uses and how long it takes to fill such a buffer before a new chunk is allocated.

 

I believe question 1 has already been answered...writes chunks of about 512 kb at once.

 

Regards

majstang