> 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
