[vdr] Thread priority of cutting thread in vdr

jori.hamalainen at teliasonera.com jori.hamalainen at teliasonera.com
Tue Oct 11 09:45:37 CEST 2005


> If you're using the current developer version, simply put a call to
> 
>    SetPriority(19);
> 
> at the beginning of cCuttingThread::Action().
> Let me know if this helps, the I'll add it to the official code.

I agree with the later messages stating that cutting queue is much better choice. Also one reader proposed that usleep could be used to limit 
bandwidth, and had 5MB/s reduction in cutting speed.

Cutting is IO bound operation with harddisk reads and writes. And reading or
writing to disk 'exits' from thread to kernel, so that thread waits for disk write to complete until thread code is scheduled to be run again (unless 
non-blocking disk IO is used).

So in theory this SetPriority would affect cutting speed a bit, because if 
there is something more important to do after disk IO is done, it would be
done first. But it depends in kernel scheduler, some schedulers increase
process priorities when they are at IO wait.

Cutting also trashes caching, I didn't check how VDR does cutting, but earlier (1-2 years ago) I think there was a thread on this list of using
special disk IO methods for reading disk without caching (data left behind).
Read ahead caching is ok.

And finally I think the "cut in place" -patch would remove the need of cutting queues because cutting is more like file renaming than hard copying.
So instead of copying 2GB of data (1h recording) perhaps 100MB data is copied, and rest of 1.9GB data is just 'moved' via file renaming. Very fast.

Best regards, Jori



More information about the vdr mailing list