[mythtv-users] Pixelation/Bad Recordings HDHR Prime -- I am at my wits end

[Stephen P. Villano]

On 9/26/13 10:20 AM, Captain Hook wrote:
> On Wed, Sep 25, 2013 at 7:21 PM, Raymond Wagner <raymond at wagnerrp.com> wrote:
>> On 9/25/2013 4:41 PM, Jon Heizer wrote:
>>> and network tuners
>>
>> There's the key factor there. Networked tuners, meaning the tuner is a
>> little embedded computer sitting on your network somewhere, and feeding data
>> to you. Networks have unpredictable latency, and so anything operating over
>> one must be able to handle it. Hardware drivers do not account for such
>> things, and should not account for such things, but never the less run into
>> such things when attempting hardware pass through in a virtual machine. The
>> result is somewhere between unreliable and completely broken. Driver
>> developers typically want to have no part of someone attempting to use
>> hardware in a virtual machine.
>>
>> There are other architectural reasons why the typical user has no reason to
>> want to use a virtual machine, but that's a topic for another thread.
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
> I wouldn't really consider myself a "typical user", but I believe that
> this was disk I/O (or lack thereof) that was causing the issue, not a
> network issue.  I ran packet tests with Silicon Dust's instructions,
> and even during this I attempted to saturate the NIC on the VM host by
> transferring a large amount of data with other VMs (on the same host)
> and I never lost a single packet.
> _______________________________________________
>

Could be disk I/O, could be SQL related. It's one thing to toss data
around the network, even to save it to disk. It's quite another when one
has a database involved in the midst of it all. It could even be a
buffering issue, too small or too large a buffer can cause latency
issues that would result in data loss in the saved product, hence
pixelation.

In my setup, I got snookered a few years back into purchasing a fakeraid
card (was sold as a real RAID, but it's software RAID). That is a bit of
a bottleneck when writing to disk. Add in only a gig of RAMBUS ram, an X
session and worse, ZoneMinder, tuning was a bit of a challenge. I ended
up saving to a non fakeraid disk, then copying it to the fakeraid until
I can do better on mass storage.
It all comes down to what all is going on while the program is being
saved to disk, forking processes, database transactions and buffer dumps
all come into play.
That was one of the reasons that sql databases weren't recommended for
VM's for many years. Tuning was too problematic for many SA's to merit
suggesting it or supporting it.
Perhaps something like iostat, dstat or vmstat might be in order while
saving a program? It'd probably impact quality a bit more, but you'd see
the bottleneck if it's disk based.