Opened 10 years ago

Closed 10 years ago

#7624 closed defect (fixed)

myth-setup crashes scanning DVB-T channels with ERROR: invalid channel on HDHomerun.

Reported by: tortise@… Owned by: Nigel
Priority: minor Milestone: 0.23
Component: MythTV - Channel Scanner Version: 0.22
Severity: medium Keywords: Scan Seg Fault
Cc: Ticket locked: yes


We are getting

"ERROR: invalid channel.(.;)"

for two New Zealand DVB-T HDHomerun users when trying to scan channels. mythtv-setup crashes instead of scanning the channels.

Problem may be related to, in lines 249-257 of hdhrchannel.cpp and may be related to use of qam before auto?

For me this is running 20090806 firmware on mythbuntu 9.10 and fixes 22824. Also known to occur on 22778.

Second user running .22 r22824 on Gentoo amd64, HDHR firmware 20091024.

Seeing these two packets repeated 8,000-13,000 times when beginning a scan, after which mythtv-setup segfaults (tcpdump -iwlan0 -vv -s0 -A 'host')

15:22:36.916921 IP (tos 0x0, ttl 64, id 29588, offset 0, flags [DF], proto TCP (6), length 82) > Flags [P.], cksum 0xfb83 (correct), seq 366375:366417, ack 287898, win 5840, length 42

E..Rs.@.@.1... *.. .......qr.|..P.........."../tuner0/channel...qam:474000000...O.

15:22:36.917657 IP (tos 0x0, ttl 64, id 51255, offset 0, flags [none], proto TCP (6), length 73) > Flags [P.], cksum 0x9db2 (correct), seq 287898:287931, ack 366417, win 1460, length 33

E..I.7..@..u.. ... *.....|....q.P.............ERROR: invalid channel.(.;)

How can we assist from here?

Attachments (2)

7624-1.patch (945 bytes) - added by Mark de Reeper <markdr@…> 10 years ago.
Initial patch for 7624
gdb.txt (14.5 KB) - added by ross.jemima@… 10 years ago.
backtrace report

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by Mark de Reeper <markdr@…>

Attachment: 7624-1.patch added

Initial patch for 7624

comment:1 Changed 10 years ago by Mark de Reeper <markdr@…>

I am also seeing this issue here in NZ. I had moved from a .22-trunk (r21860) release to .22-release-fixes and started to have this issue. I reverted back to r21860 until I had more time to investigate.

From the research I have done over the weekend I believe that this is actually related to a change made in release .22 r22016. The change was to hdhrstreamhandler.cpp ( It appears to be going into a recursive loop which ends up in a segfault.

The change message for the fix was "Hokey fix to make newer hdhomerun firmware revisions work. Retry tuning with "qam:<freq>" if "qam_256:<freq>" or "qam_64:<freq>" failed." I guess that here in NZ we are seeing some different cases which should be ignored rather than triggering a recursive call.

By removing this change from a recent trunk release, I no longer get the problem. A suggested patch is attached (against r22889), I have no way of testing it against the original problem which led to r22016 though.

comment:2 Changed 10 years ago by anonymous

0.22 r22860 + this patch on gentoo amd64 is now succesfully scanning and tuning for livetv

Getting EIT data for only some channels currently, as soon as I've recompiled with faad support (oops, missed that one), will confirm all channels are playing successfully.

comment:3 Changed 10 years ago by anonymous

After recompiling, nuked the DB and started from scratch

I get a LOT of these while scanning

2009-11-23 18:10:02.252 HDHRSH(121027A2-0) Error: DeviceSet(channel qam:722000000): ERROR: invalid channel

But we have a successful result overall

qam_64:690000000:TV ONE:1:13313:8746:1200:27=27:dvb     0:cnt(pnum:1,channum:1)
qam_64:690000000:TV2:2:13313:8746:1201:27=27:dvb        0:cnt(pnum:1,channum:1)
qam_64:690000000:TVNZ 6:6:13313:8746:1202:27=27:dvb     0:cnt(pnum:1,channum:1)
qam_64:690000000:TVNZ 7:7:13313:8746:1203:27=27:dvb     0:cnt(pnum:1,channum:1)
qam_64:706000000:TV3:3:13313:8746:1300:29=29:dvb        0:cnt(pnum:1,channum:1)
qam_64:706000000:C4:4:13313:8746:1301:29=29:dvb 0:cnt(pnum:1,channum:1)        
qam_64:706000000:TV3 PLUS1:8:13313:8746:1302:29=29:dvb  0:cnt(pnum:1,channum:1)
qam_64:778000000:Maori Television:5:13313:8746:1400:33=33:dvb   0:cnt(pnum:1,channum:1)
qam_64:778000000:Parliament TV :22:13313:8746:1401:33=33:dvb    0:cnt(pnum:1,channum:1)
qam_64:778000000:Test Channel:242:13313:8746:1402:33=33:dvb     0:cnt(pnum:1,channum:1)
qam_64:778000000:ChineseTV:28:13313:8746:1403:33=33:dvb 0:cnt(pnum:1,channum:1)        
qam_64:778000000:PRIME:10:13313:8746:1404:33=33:dvb     0:cnt(pnum:1,channum:1)        
qam_64:778000000:Reserved 6KSD:245:13313:8746:1405:33=33:dvb    0:cnt(pnum:1,channum:1)
qam_64:778000000:Freeview | HD:100:13313:8746:1406:33=33:dvb    0:cnt(pnum:1,channum:1)
qam_64:778000000:tvCentral:30:13313:8746:1408:33=33:dvb 0:cnt(pnum:1,channum:1)        
Found 3 transports:
Channels: FTA Enc Dec
ATSC        0   0   0
DVB        15   0   0
SCTE        0   0   0
MPEG        0   0   0
NTSC        0
Unique: prog 15 atsc 0 atsc minor 0 channum 15

EIT data on all channels, everything seems to be working

comment:4 Changed 10 years ago by ross.jemima@…

Subscribing to ticket

comment:5 Changed 10 years ago by anonymous

An interim approach is to use 0.21 until 0.22 is updated as 0.21 22228 does not have this issue. I am running the HDHomerun pretty well using JYA's old last 0.21 version 22228 (and no longer updating) with 190.42. I just checked his 22228 files are still up on his server so maybe he'd put up another deb for them, however someone might have to ask him very nicely to do that - or maybe you can figure out some way to run them yourself in the meantime?

Changed 10 years ago by ross.jemima@…

Attachment: gdb.txt added

backtrace report

comment:6 Changed 10 years ago by ross.jemima@…

I can get mythbackend up and running when I don't have any HDHomerun tuners configured (ie delete all the tuners). But when I configure the tuners I get the attached backtrace. I'm using 0.22 r22869 (from JYA's release repo).

If this issue is going to take a while to be solved I might do as suggested and try reverting to 0.21. Its a bummer though since 0.22 has multirecord support for HDHomerun.

comment:7 Changed 10 years ago by danielk

Owner: changed from danielk to Nigel
Status: newassigned

comment:8 Changed 10 years ago by Stuart Auchterlonie

Milestone: 0.220.23

comment:9 Changed 10 years ago by fastie81

Hi Guys

Got the same problem.

Changed 23 hours ago by stuarta 
milestone changed from 0.22 to 0.23

Does this now mean 0.22 will not get fixed? Has any one tried this patch? does it work and if so is there any steps on how to get this working? I have like 4 Homerun's and now I cant use any of them.. Would love to get this working again. Please help C

comment:10 Changed 10 years ago by anonymous

Yes I know two people who have successfully applied the patch. There may be better ways to do it however it would be nice to have it work as it is, even if this is a hack of a hack related to very old firmware.

comment:11 Changed 10 years ago by stuartm

Ticket locked: set

comment:12 Changed 10 years ago by Nigel

Status: assignedstarted

In Australia, with an empty DB, an initial scan with r23228 is tuning 'auto:freq', so doesn't exhibit this fault. Until I can mangle my database enough to reproduce, can one of the interested parties please try this tidyup of r22016:

Index: hdhrstreamhandler.cpp
--- hdhrstreamhandler.cpp	(revision 23228)
+++ hdhrstreamhandler.cpp	(working copy)
@@ -692,7 +692,7 @@
         return QString::null;
-    if (error && name == QString("channel"))
+    if (error && name == QString("channel") && val.contains("qam_"))
         QString newval = val;
         newval.replace("qam_256", "qam");

and mail the results to me, or the mythv-dev list?

comment:13 Changed 10 years ago by Nigel

(In [23297]) Prevent infinite recursion caused by [22016]. I would prefer to revert the hack completely to find out the failure conditions that required it, but 'til I get the -v channel output, this will have to do. Refs #7624

comment:14 Changed 10 years ago by Nigel

Resolution: fixed
Status: startedclosed

(In [23298]) Backport [23297] from trunk. Closes #7624

Note: See TracTickets for help on using tickets.