[mythtv-users] Realtime commflagging....was: How many simultaneous recordings on one drive?

Douglas Peale Douglas_Peale at comcast.net
Thu Sep 29 03:43:06 UTC 2011


On 09/28/2011 08:29 PM, David Whyte wrote:
> On Thu, Sep 29, 2011 at 8:28 AM, Simon Hobson <linux at thehobsons.co.uk> wrote:
>> Now I've got a machine dedicated to the backend, I've configured to
>> start commflagging when a recording starts (only one job at the
>> moment - need to experiment to see if two works well). The idea is
>> that it can process the data as it's received, and so can work from
>> what's already held in the OS cache and thus not add to the I/O load
>> by reading a recording in after it's finished.
>>
> Is this really how realtime commflagging works?  If the data is being
> processed as it is received, I am assuming you mean the data is read
> off the tuner, buffered somewhere in memory and the commflagger
> processes it then writes it to disk.
>
> This raises two questions:
> 1) What if the commflagger can't keep up? How big is the buffer?
> 2) What if the commfalgger 'crashes', would the data never get stored to disk.
>
> I am pretty sure that realtime commflagging is just another job that
> is started at the same time as the recording starts (assuming there is
> a spare job slot) but if I am wrong, could someone confirm?
>
> Cheers,
> Whytey
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
As far as I know, which isn't much, the comflagging is just another task.
What we are relying on is the disk cache caching what has just been written to the disk.
Linux seems to use all unused RAM as a disk cache. If commflagging is happening while recording, and you have lots of RAM, then
the commflagging task should be getting its data from RAM. If it gets too far behind, there will not be enough RAM to hold the
buffer, and commflagging will need to get the data from the disk.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110928/40220f21/attachment.bin 


More information about the mythtv-users mailing list