[vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Klaus.Schmidinger at cadsoft.de
Mon Mar 23 16:59:53 CET 2009
On 23.03.2009 08:35, Klaus Schmidinger wrote:
> On 23.03.2009 01:09, Niedermeier Günter wrote:
>>> There must be an other problem that's causing this, but since this doesn't
>>> happen here on my system, I'm afraid you'll need to do the debugging ;-)
>> Which changes have been made between 1.7.2 and 1.7.3 in
>> file writing mechanism?
>> Not codechanges, because I dont understand them, but in words please.
>> E.g. blocksize changed from xxx to yyy changed algo. changed cache or
>> something else which can influence the performance.
>> I found out, that in 172 the most time up to 20 stream data blocks are
>> transmitted via NFS between one "NFS WRITE CALL / WRITE REPLAY" and
>> "NFS COMMIT CALL / COMMIT REPLAY" combination and the next one.
>> In 173/174 the number of stream data blocks decreases to an amount of
>> 5 blocks maximal. Therefor the number of "NFS WRITE CALL / WRITE REPLAY"
>> and "NFS COMMIT CALL / COMMIT REPLAY" combinations increases up to
>> 4 to 5 times higher than in 172.
>> This produces an enormous overhead, and this overhead could be
>> reasonable for the two MegaByte/s networkoverload above the normal
>> load with 1 MB/s per stream.
>> Perhaps Klaus, you have an idea.
> I believe I do. With PES recordings, data was written to the file
> in larger chunks, while with TS recordings it is written in blocks
> of 188 byte (TS_SIZE). I'll chnage cFrameDetector::Analyze() to
> handle more data at once.
> Will try to provide a patch for testing tonight.
Here's a quick shot - totally untested (no time, sorry).
Please try it and let me know if it helps.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2350 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20090323/366552d2/attachment-0001.bin
More information about the vdr