[mythtvnz] Pixelation/Corrupt recordings

[Stephen Worthington]

On Tue, 15 Jul 2014 15:23:38 +1200, you wrote:

>On 15 Jul 2014 14:18, "Aaron Pelly" <apelly at monkeymasters.co.nz> wrote:
>>
>> On 07/07/14 22:20, Stephen Worthington wrote:
>>>
>>> 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.
>>
>> I'm not so sure now. I seem to have the latest firmware; the firmware I
>manually extracted from the latest drivers matched anyway.
>>
>>
>>> 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.
>>
>> Yes. I see errors now. Thanks for the tip. Here's a sample that seems to
>transition from good to bad. Problems start around 7am
>>
>> $head -8000 mythbackend.log.1 | tail -2000 | pastebinit
>> http://paste.ubuntu.com/7796380/
>>
>>
>>
>>> 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.
>>
>> This is a useful query. Thanks again for taking the time to give me such
>a detailed response.
>>
>> I have more information now. None of it seems to help though:
>>
>> When watching live tv on the backend Myth cunningly shows signal strength
>and s/n. Strength was alarmingly low. I happened to have an old signal
>amplifier lying around from previous experimenting. Sadly it doesn't pass
>anything into the GHz range, so no satelite. It did significantly raise the
>signal level and, when I've checked, s/n is around 90%.
>>
>> Most recordings are fine now. Sometimes they are totally unwatchable
>though. And sometimes Myth fails to create any output.
>>
>> I live in an apartment with one coax connection. Everything outside is
>beyond my control. However, the other couple of hundred people in the
>building are presumably doing OK.
>>
>> I've spent a bloody long time dicking around with this, but I'm a geek; I
>will persist. I feel I'm running out of ideas though.
>>
>> In reading about signal amplifiers I encountered filters to remove LTE
>signals. 2degrees has just launched 4g in Auckland. It seems unlikely
>telcos would be allowed to cause out of band interference.
>>
>> I also encountered a long standing obscure cx88 i2c driver bug. I have
>not tried the workaround on the master backend because it seemed to work in
>the past. Maybe I'll give that a go too
>
>Try the live TV under windows media centre, using your same hardware, if
>you have a spare partition (and access to the software of course!). If
>there's no problem there, it's more likely a Linux-related firmware of
>software problem, rather than reception or hardware.

If you do not have access to Windows Media Center but do have Windows,
then there is other Windows freeware you can use to try things.  I use
MediaPortal on my Windows box:

  http://www.team-mediaportal.com/

Any Windows 7 install disk should work for testing for up to three
days before it needs to be licensed.