Mailing List Archive

Pixelation/Corrupt recordings
Hi guys, I'm looking for some pointers to troubleshoot corrupt recordings.

At various times, with various degrees of intensity, my recordings are
not happening cleanly. Sometimes it doesn't happen, sometimes it is mild
enough to ignore, sometimes it makes a recording totally unwatchable.
The messages below are the only thing I have managed to find in the logs
(messages repeat during playback). The backend doesn't seem to complain
during the recording, but that might be because I don't have the best
logging options set.

Jul 7 10:08:56 crepitus mythfrontend.real: mythfrontend[25257]: E
Decoder avformatdecoder.cpp:4709 (ProcessAudioPacket) AFD: Unknown audio
decoding error
Jul 7 10:08:58 crepitus mythfrontend.real: mythfrontend[25257]: E
Decoder videobuffers.cpp:283 (GetNextFreeFrame) GetNextFreeFrame()
unable to lock frame 100 times. Discarding Frames.

Hardware:
- core2 duo ~3GHz
- 4G RAM
- many 7200rpm HDDs, but with only two configured as storage groups.
drives are currently ntfs. This will change in the next few days.
- 2 HVR4000 tuners
- Cheapo Nvidia card, (gt9500?), doubt that's relevant.

I do have a motherboard with a core2 quad and 8G ram that I'll probably
stick in the backend this week. Maybe I should just try that first?

I don't have a lot of (any?) clues showing up to help me track this
annoyance down, but here is list, in no particular order, of a mixture
of superstition, suspicion, notes, and anecdotes:

- mplayer can't play the recordings either
- it might be worse when there are multiple simultaneous recordings
- it comes and goes
- might be worse when the backend has low ram
- seems a bit better after rebooting the backend
- not sure if it affects dvbs or just dvbt
- i haven't done the math for required throughput for the HDDs or the
PCI bus.

- I have seen this with gbpvr on the same hardware, using dvbs only and
it seemed to be primarily caused by lack of ram. I doubt it's relevant,
I only mention it for completeness.

Of course, this might be simply bad reception. I haven't seen any
correlation with terrestrial weather. Have not looked at solar weather.

I feel lazy asking you guys for more help. I know I can solve this if I
spend enough time googling, but I feel like so many things could be
causing this. Some clues to narrow it down would be a bit of a treat really.

Thanks,
Aaron.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On Mon, Jul 7, 2014 at 10:59 AM, Aaron Pelly <apelly@monkeymasters.co.nz>
wrote:

> Hardware:
> - core2 duo ~3GHz
> - 4G RAM
> - many 7200rpm HDDs, but with only two configured as storage groups.
> drives are currently ntfs. This will change in the next few days.
> - 2 HVR4000 tuners
> - Cheapo Nvidia card, (gt9500?), doubt that's relevant.
>
> I do have a motherboard with a core2 quad and 8G ram that I'll probably
> stick in the backend this week. Maybe I should just try that first?
>

You've got more than enough CPU and RAM for recording, I doubt this will
help unless there is something else running on the box?

>
> I don't have a lot of (any?) clues showing up to help me track this
> annoyance down, but here is list, in no particular order, of a mixture of
> superstition, suspicion, notes, and anecdotes:
>
> - mplayer can't play the recordings either
>

So it's definitely a problem in recording.


> - it might be worse when there are multiple simultaneous recordings
> - it comes and goes
> - might be worse when the backend has low ram
> - seems a bit better after rebooting the backend
> - not sure if it affects dvbs or just dvbt
> - i haven't done the math for required throughput for the HDDs or the PCI
> bus.
>

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. Is there anything else hitting those drives? What about
the drive with the database?

Of course, this might be simply bad reception. I haven't seen any
> correlation with terrestrial weather. Have not looked at solar weather.
>

Bad reception would be my guess. Does it happen during live TV?

Cheers,
Steve
Re: Pixelation/Corrupt recordings [ In reply to ]
On 07/07/14 11:23, Steve Hodge wrote:
> On Mon, Jul 7, 2014 at 10:59 AM, Aaron Pelly
> <apelly@monkeymasters.co.nz <mailto:apelly@monkeymasters.co.nz>> wrote:
>
> Hardware:
> - core2 duo ~3GHz
> - 4G RAM
> - many 7200rpm HDDs, but with only two configured as storage
> groups. drives are currently ntfs. This will change in the next
> few days.
> - 2 HVR4000 tuners
> - Cheapo Nvidia card, (gt9500?), doubt that's relevant.
>
> I do have a motherboard with a core2 quad and 8G ram that I'll
> probably stick in the backend this week. Maybe I should just try
> that first?
>
>
> You've got more than enough CPU and RAM for recording, I doubt this
> will help unless there is something else running on the box?
I do use it as a PC too, so sometimes firefox is running. Firefox, for
me, is like having a bloody gorilla in your RAM. I had thought (but not
checked) that this would swap out when I wasn't around for a while.
Frontends on other machines report 3.9GB total, 3.7GB used, 138MB
available. This is pretty consistent no matter what the backend is up
to, so I suspect a myth bug. gnome-system-monitor reports about 900MB
used at the moment. At the moment I'm not having recording issues either...

>
> - it might be worse when there are multiple simultaneous recordings
> - it comes and goes
> - might be worse when the backend has low ram
> - seems a bit better after rebooting the backend
> - not sure if it affects dvbs or just dvbt
> - i haven't done the math for required throughput for the HDDs or
> the PCI bus.
>
>
> 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.
I will try this.

> Is there anything else hitting those drives?
Can't think of anything. I'm about to move a bunch of data around and
get them formatted as ext4/xfs as appropriate. I will see how/if this
affects recordings in progress.

> What about the drive with the database?
SSD

>
> Of course, this might be simply bad reception. I haven't seen any
> correlation with terrestrial weather. Have not looked at solar
> weather.
>
>
> Bad reception would be my guess. Does it happen during live TV?
Yes.
Re: Pixelation/Corrupt recordings [ In reply to ]
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.

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.

Aaron.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On Mon, Jul 7, 2014 at 12:08 PM, Aaron Pelly <apelly@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. Maybe do
some testing with commercial detection off in case that is corrupting them
somehow. Might also be worth looking into whether one tuner in particular
is the source of corrupt recordings.


> 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.


Have a look at the kernel log too.

Cheers,
Steve
Re: Pixelation/Corrupt recordings [ In reply to ]
10:1 it is a signal strength or noise issue. Cable, splitter, water ingress, ....

Sent from Yahoo Mail on Android
Re: Pixelation/Corrupt recordings [ In reply to ]
On 07/07/14 12:21, Steve Hodge wrote:
> On Mon, Jul 7, 2014 at 12:08 PM, Aaron Pelly
> <apelly@monkeymasters.co.nz <mailto:apelly@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.
Re: Pixelation/Corrupt recordings [ In reply to ]
On 7 July 2014 13:19, Aaron Pelly <apelly@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@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.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

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.... :)

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On Mon, Jul 7, 2014 at 1:19 PM, Aaron Pelly <apelly@monkeymasters.co.nz>
wrote:

> On 07/07/14 12:21, Steve Hodge wrote:
>
> 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?
>

Right, it won't be that.

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.
>

I suspect it isn't. I'll have a look tonight.


> 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.
>

That's quite likely to be the issue.

Cheers,
Steve
Re: Pixelation/Corrupt recordings [ In reply to ]
On 7 July 2014 13:33, Curtis Walker <sultanoswing@gmail.com> wrote:

>
> 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.... :)
>

Hi,
I have a 2210 card to but I haven't updated my system for ages as, the
2210 was not supported out of the box by the kernel. Do you know if it
is now?

Cheers
Bruce

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On Mon, 7 Jul 2014 13:33:06 +1200, you wrote:

>On 7 July 2014 13:19, Aaron Pelly <apelly@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@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.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
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 will try this.

> 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).
Done. Will keep an eye on it. Nothing interesting so far.

> 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.
Thanks for the query, Stephen.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On 07/07/14 15:10, Steve Hodge wrote:
>
> 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.
>
>
> That's quite likely to be the issue.
The firmware I'm using appears to be the latest. The cards are so old
now that the links in the wiki are all broken. Manually extracting the
firmware from the drivers on hauppauge's website gives me an identical
file. OK, not identical, slightly shorter, but that was probably an
error on my part. I will try my firmware at some stage but I don't think
it's a priority right now.
Re: Pixelation/Corrupt recordings [ In reply to ]
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.



_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On 15 Jul 2014 14:18, "Aaron Pelly" <apelly@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.
Re: Pixelation/Corrupt recordings [ In reply to ]
On Tue, 15 Jul 2014 15:23:38 +1200, you wrote:

>On 15 Jul 2014 14:18, "Aaron Pelly" <apelly@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.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On Tue, 15 Jul 2014 14:17:42 +1200, you 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.

It is possible to get too strong a signal and that causes problems
too. But I would expect the card to be saying 100% signal level if
that was happening.

I do not at all understand there being no log output sometimes about a
problem. There should be something, even if it is far back in history
where a tuner disappeared and Myth decided it could no longer even try
using it. When you get a problem like that, it would be a good idea
to look at the ls -al /dev/dvb output to see if any tuners are
missing, and also to try other software to see if they can use the
tuners. VLC or mplayer come to mind, and there are others.

>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.

Is there someone else you can ask to see if they have problems too?
Preferably an apartment on the same floor as you so they are likely to
be sharing the same bit of cable that goes to your apartment. Cable
problems in apartment blocks do happen - so maybe you need to talk to
whoever you are renting it from or to the body corporate to see if
there are any other people with problems.

>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.

I am wondering if you need to get in some professional help. A good
aerial company will have proper test meters and be able to install an
amplifier that should work properly if necessary, including the
satellite signals. That would likely be cheaper than buying your own
aerial test meter as they seem to start at $700 or so for the cheapest
I have seen recently.

Or you might like to try buying a cheap (< $30) USB DVB-T or DVB-T2
tuner to see if it has the same problems or not. That should resolve
whether it is the tuner card. However, finding one with Linux support
is not always easy - the ones I used to recommend seem to have
disappeared from the market. TradeMe usually has a good selection of
what is currently available, but the sellers often do no post enough
information to be able to look them up to see about Linux support.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On 07/07/14 10:59, Aaron Pelly wrote:
> Hi guys, I'm looking for some pointers to troubleshoot corrupt recordings.

An interesting data point - though more than likely unrelated to you.

Lately there have been bandwidth issues on the fibre link to the local
DVB-T transmitter which is causing pixelation - nothing to do with
anyone's CPE at all but the same symptom.

hads
--
http://nice.net.nz

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
>On 07/07/14 10:59, Aaron Pelly wrote:
>> Hi guys, I'm looking for some pointers to troubleshoot corrupt
recordings.
>
>An interesting data point - though more than likely unrelated to you.
>
>Lately there have been bandwidth issues on the fibre link to the local
DVB-T transmitter which is causing pixelation - nothing to do with anyone's
CPE at all but the same >>symptom.
>
>hads

That's a very interesting comment, which transmitters are you talking about
and do you know anything more? We have had our aerial checked by a
professional and still get a lot of pixilation -at times-, mostly on TV3 and
totally at random - not necessarily associated with bad weather.

Cheers

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7833 - Release Date: 07/10/14


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On 15/07/14 21:15, ajp@cantabrian.co.nz wrote:
> That's a very interesting comment, which transmitters are you talking about
> and do you know anything more?

Our local transmitter is Cave Hill which is the one I was referring to,
insufficient bandwidth on the shared link.

hads
--
http://nice.net.nz

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Pixelation/Corrupt recordings [ In reply to ]
On 15/07/2014, at 9:23 PM, Hadley Rich <hads@nice.net.nz> wrote:

> On 15/07/14 21:15, ajp@cantabrian.co.nz wrote:
>> That's a very interesting comment, which transmitters are you talking about
>> and do you know anything more?
>
> Our local transmitter is Cave Hill which is the one I was referring to, insufficient bandwidth on the shared link.
>
>
I'm gobsmacked. How is it possible to lease/provision insufficient bandwidth for the trivial DVB-T channel bit rates on a fibre link?
_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/