[mythtv-users] Combined FE/BE using USB for all I/O?

[Stephen Worthington]

On Tue, 19 Aug 2014 10:23:53 +1000, you wrote:

>On 19 August 2014 05:56, Eric Sharkey <eric at lisaneric.org> wrote:
>> Yes, it mostly does, thanks.  What you describe sounds pretty good to
>> me.  I still don't like ring buffers in general, but as long as the
>> writes are asynchronous and the sync's don't rely on the ring buffer
>> it really should be ok in practice.
>
>ringbuffer because it's the easiest and most portable approach.
>remember that myth runs on various platforms (BSD, Linux, OS X,
>Windows), not all posix compliant, that the core code is almost a
>decade old and only required updating recently for minor fixes.
>
>>
>> But can you explain why multiple people on this list seem to think
>> that I/O contention is a serious problem, such as Stephen
>> Worthington's "All it takes is one moment when the
>> disk is too busy and you will lose a block of data and seconds of one
>> or more recording."?  That just doesn't seem to be the case.
>
>because that just can't happen.
>Assuming the disk is slow or the system can't write to disk quick
>enough, once the write buffer is full, new data can't be added, the
>whole recorder will stop writing new data to disk.
>the recording will be truncated and no more data will be written to
>it. It can't be a case of partial data missing, it would be *lots* of
>data missing.
>
>So I'm suspecting that the issue is different, the analysis of it
>being just wrong, and that it's not due to the threaded writer.
>
>The other way I think could happen, still within the recorder but not
>the writer. As I mentioned earlier, data coming from the V4L adapter
>is continuous and isn't buffered (well except the very little the
>driver will buffer). If there's no listener the data is lost. It's a
>bit like how serial ports work
>
>So if the system is unusually slow, if the V4L adapter is virtual
>etc... that by the time the system is free again to read from the V4L,
>some data has been lost, or that data is just lost regardless on the
>V4L interface.
>
>I can't think of any other way that would explain random, partial loss
>of data: nothing to do with how myth writes to disk with those
>symptoms.

It should be easy enough to test for this - just set up a storage
group that points to one storage partition, then set up multiple
recordings happening at the same time to go to that storage group.
Keep adding more simultaneous recordings until it breaks.

My experience is that when the disk is too busy, recordings do not
stop but I do get missing bits in the recordings.  However, it is a
while and a few MythTV versions since I have had this happen, as since
I had the problem I always make sure I have enough hard drives to
prevent it.