[mythtv] [PATCH] (experimental) hdtvrecorder - ringbuffer
John Patrick Poet
john at BlueSkyTours.com
Sun Dec 12 06:22:52 UTC 2004
This patch adds a ringbuffer to hdtvrecorder. It virtually eliminates
all overruns from the HD-x000 device driver.
This patch assumes that Daniels hdtv-recorder-v38 patch is already
installed:
http://www.mrl.nyu.edu/~danielk/mythtv/
In this version, the ringbuffer size is 96MB, which is probably a
overkill. However, in severe situations I have seen it all used.
With this patch, I can record three shows simultaneously, while watching
a fourth. In this scenario, my backend starts to have some overruns
after 1.5 hours. If one of the three recording streams is stopped, the
other two will "recover" and continue to record perfectly.
Watching gkrellm during the above scenario, the disk writes are very
steady for the first 1.25 hours, then for some reason the writes become
jagged.
During the first 1.25 hours, the graph looks something like:
_____ _____ _______ ________ ___________
/ |_| |_| |_| |_|
After 1.25 hours, the graph looks something like:
__ __ __ __ __
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
___| |___| |____| |____| |____| |______
If anyone has any idea why the system goes through this transition, I
would love to hear them.
When just recording two streams, it seems to be able to go indefinitely
without entering that jagged disk write state.
The various read, write and sleeps took some testing to keep the threads
in balance. I am curious if this patch works for others as well as it
works for me.
Thanks,
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hdtvrecorder-ringbuffer.patch
Type: text/x-patch
Size: 17982 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20041211/60b6c276/hdtvrecorder-ringbuffer-0001.bin
More information about the mythtv-dev
mailing list