[mythtv] [PATCH] (experimental) hdtvrecorder - ringbuffer

[John Patrick Poet]

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