[mythtvnz] Pixelation/Corrupt recordings

[Stephen Worthington]

On Mon, 7 Jul 2014 13:33:06 +1200, you wrote:

>On 7 July 2014 13:19, Aaron Pelly <apelly at monkeymasters.co.nz> wrote:
>> On 07/07/14 12:21, Steve Hodge wrote:
>>
>> On Mon, Jul 7, 2014 at 12:08 PM, Aaron Pelly <apelly at monkeymasters.co.nz>
>> wrote:
>>>
>>> On 07/07/14 11:23, Steve Hodge wrote:
>>>>
>>>> If it's not consistently happening with simultaneous recordings it's
>>>> probably not a throughput issue. You could try recording say 6 things at
>>>> once to test this.
>>>
>>> You made me watch some Home and Away. Damn you!
>>>
>>> Inconclusive results. iotop shows about 2MB/sec to two storage groups.
>>> gnome-system-monitor shows mythbackend and mount.ntfs both ranging from 3
>>> to 6% CPU. Both cpus running about 15-20%
>>> some recordings OK. Some show corruption. Corrupt shows are on Sommet and
>>> Prime. This is not always the case.
>>
>>
>> Probably not a HD or RAM bottleneck if they're not all corrupt.
>>
>> Yes, and IO looks trivial.
>>
>>
>> Maybe do some testing with commercial detection off in case that is
>> corrupting them somehow.
>>
>> Can do. Surely it doesn't run for live tv though?
>>
>>
>> Might also be worth looking into whether one tuner in particular is the
>> source of corrupt recordings.
>>
>> Do you know if the tuner that was used stored in the DB anywhere? Might save
>> me some time.
>>
>>
>>
>>>
>>> Interesting backend log entry:
>>> 11:55:39 zeus mythbackend: mythbackend[2503]: W DeviceReadBuffer
>>> recorders/DeviceReadBuffer.cpp:555 (Poll)
>>> DevRdB(/dev/dvb/adapter1/frontend1): Poll took an unusually long time 2547
>>> ms
>>>
>>> Last 2000 lines of the backend log:
>>> cat /var/log/mythtv/mythbackend.log | tail -2000 | pastebinit
>>> http://paste.ubuntu.com/7757924/
>>>
>>> I'll investigate that log entry further.
>>
>> Makes me wonder if I should try different firmware. Cant remember where I
>> got the current version from. Probably via the linux tv wiki. I recall there
>> were multiple versions.
>>
>>
>> Have a look at the kernel log too.
>>
>> Nothing shows up around the time I tested multiple recordings.
>>
>Yeah - check the firmware. I had a *very* frustrating problem with
>pixellated recordings & live TV which resulted in multiple trips up
>the roof & to Jaycar trying to solve a reception problem, when in fact
>I needed to reinstall the card's firmware (a Hauppage HVR-2210).
>
>Of course your problem could still be reception-related.... :)

It is always worth trying a cold boot if you suspect firmware
problems.  Shut down the PC, turn the power supply off, turn off all
peripherals, and wait for at least a minute for all the capacitors to
decay.  Turn the power supply on, and wait for 15 seconds or so for
the standby power to stabilise.  Turn on peripherals.  Then start the
PC.  That should ensure that absolutely all hardware is completely
reset and all firmware is reloaded.

To help diagnose this, you might like to add the "-v record" option to
the end of your mythbackend command line (in
/etc/init/mythtv-backend.conf in Mythbuntu).  Then you will get extra
debug output logged about the recording process.  Even without that,
you get a recording quality message at the end of each recording. Here
is an example of a recording quality report from your log:

Jul  7 11:26:02 zeus mythbackend: mythbackend[2503]: I TVRecEvent
tv_rec.cpp:834 (FinishedRecording) TVRec[20]:
FinishedRecording(2929_2014-07-06T23:24:58Z) damaged
recq:<RecordingQuality overall_score="0"
key="2929_2014-07-06T23:24:58Z" countinuity_error_count="0"
packet_count="16684">#012    <Gap start="2014-07-06T22:45:00Z"
end="2014-07-06T23:24:58Z" duration="2398" />#012    <Gap
start="2014-07-06T23:26:01Z" end="2014-07-07T00:00:00Z"
duration="2039" />#012</RecordingQuality>

That log entry does not actually tell you much, as you always get
errors like that when using live TV.  But if you get errors like that
when doing normal recordings, it can give valuable clues.

The "TVRec[20]" (and any other place where there is a number in [])
indicates the multirec tuner number that was used.  To find which
physical tuner that was, you can look it up in the database with some
SQL:

select cardinputid,cardid,sourceid,inputname,displayname,(select
videodevice from capturecard where cardid=ci.cardid) as videodevice
from cardinput ci order by cardinputid;

In the resulting table, the number in [] is the cardinputid value, and
the matching videodevice value is the physical tuner device used.