Opened 18 years ago

Closed 18 years ago

#2541 closed patch (fixed)

HDHomeRun segfaults on invalid channels

Reported by: dab@… Owned by: danielk
Priority: minor Milestone: 0.20
Component: mythtv Version: 0.20
Severity: medium Keywords:
Cc: carey.drake@… Ticket locked: no

Description

When mythbackend starts to record a program or an attempt is made to watch live tv on a hdhomerun capture device, mythbackend segfaults with my setup. This is running svn trunk revision 11452. I have verified that QAM tuning works on the device using hdhomerun_config to tune a valid clear QAM channel and viewing the udp stream using vlc. 8vsb viewing/recording also works fine from vlc as well as from myth; so it seems the device is funtioning properly.

I have a working mythtv qam setup with an Avermedia A180, and I tried to assign the hdhomerun capture device the same videosource as the A180 which resulted in the segfault. I also created a new videosource and performed a qam256 channel scan from mythtv-setup for the hdhomerun device (which worked fine), which still resulted in a segfault with attempts to record from the device.

A mythbackend log from mythbackend ran using -v record,channel,siparser and a gdb backtrace when the segfault occurs is attached. The backtrace is from mythbackend attempting to record a scheduled recording on the hdhomerun capture device. Please let me know if any further info is needed.

Thanks, Dwayne

Attachments (4)

gdb.txt (82.3 KB) - added by dab@… 18 years ago.
gdb backtrace
myth.log (13.3 KB) - added by dab@… 18 years ago.
mythbackend log
2541-v1.patch (3.8 KB) - added by danielk 18 years ago.
Fix for segfault
hdhr-qam256.diff (3.3 KB) - added by jwestfall 18 years ago.

Download all attachments as: .zip

Change History (19)

Changed 18 years ago by dab@…

Attachment: gdb.txt added

gdb backtrace

Changed 18 years ago by dab@…

Attachment: myth.log added

mythbackend log

comment:1 Changed 18 years ago by danielk

Owner: changed from Isaac Richards to danielk

comment:2 Changed 18 years ago by jwestfall

There is a bug in ChannelBase::SetCachedATSCInfo().

int chansep = chan.find("_");
...
currentATSCMinorChannel = chan.right(chan.length()-chansep-1).toInt();
currentATSCMajorChannel = chan.left(chansep).toInt();

The value passed to right() will be bogus if the number of digits before and after the _ isnt the same.

The logs show its passing 58_0, which make it chan.right(4 - 2 - 1 = 1, or "8_0") which results in currentATSCMinorChannel becoming -1. same thing happens with currentProgramNum. Fix would seem to be making it chan.right(chansep+1), but I have no way to test.

It doesnt seem this will fix the crash since TVRec::SetupDTVSignalMonitor() is wanting an atsc minor > 0

comment:3 Changed 18 years ago by jafa

Thread 31 (Thread -1491088480 (LWP 2893)): #0 0xb7bf8e98 in MPEGStreamData::VideoPIDSingleProgram (this=0x0) at mpeg/mpegstreamdata.h:186 #1 0xb7c16f1b in HDHRRecorder::ProcessTSPacket (this=0x82ecee8, tspacket=@0xa6799008) at hdhrrecorder.cpp:274

It looks like _stream_data in the hdhrrecorder is NULL.

comment:4 Changed 18 years ago by anonymous

Cc: carey.drake@… added

comment:5 Changed 18 years ago by danielk

Milestone: unknown0.21

jwestfall, you are confusing how QString::right() and QString::mid() work, the SetChachedATSCInfo() works as is (and I just tested it for good measure).

jafa, I think you are on to something, I'll look at this in the next couple days if you don't beat me to it.

comment:6 Changed 18 years ago by danielk

dab, it looks like the channel table is corrupted/invalid:

2006-10-07 02:33:53.279 TVRec(6) Error: No valid DTV info, ATSC maj(58) min(0), MPEG pn(-1)

How did you create your channel table? Manually?

I'll fix the segfault, but that won't be the end of your problems unless we figure out why the channel table has invalid entries in it.

Changed 18 years ago by danielk

Attachment: 2541-v1.patch added

Fix for segfault

comment:7 Changed 18 years ago by danielk

Type: defectpatch
Version: 0.20head

comment:8 Changed 18 years ago by danielk

Summary: mythbackend segfault when attempting to record from hdhomerun using qam256HDHomeRun segfaults on invalid channels

comment:9 Changed 18 years ago by dab@…

This patch does indeed fix the segfault, but as you say the recording is invalid. The channels for this source were imported from a channels.conf produced by a scan from my Avermedia A180 card, which is able to tune them. I do not get that error message when recording from the same channel with that card, here is a small excerpt from the mythbackend log when a recording starts on this channel using the A180 (no cracks about recording Pokemon, I was just testing ;):

2006-10-13 10:42:04.789 TVRec(1): StartRecording(Pok<E9>mon: Destiny Deoxys)
2006-10-13 10:42:04.790 TVRec(1): ClearFlags(AskAllowRecording,) -> RunMainLoop,
2006-10-13 10:42:04.885 TVRec(1): StartedRecording(0x84f95a0) fn(/mnt/storage/3535_20061013104200.mpg)
2006-10-13 10:42:04.888 TVRec(1): ClearFlags(CancelNextRecording,) -> RunMainLoop,
2006-10-13 10:42:04.890 TVRec(1): Changing from None to RecordingOnly
2006-10-13 10:42:04.891 TVRec(1): ClearFlags(FrontendReady,CancelNextRecording,) -> RunMainLoop,
2006-10-13 10:42:04.892 TVRec(1): SetFlags(AskAllowRecording,) -> RunMainLoop,AskAllowRecording,
2006-10-13 10:42:04.893 TVRec(1): Request: Program(yes) channel() input() flags(Recording,)
2006-10-13 10:42:04.896 TVRec(1): HW Tuner: 1->1
2006-10-13 10:42:04.897 TVRec(1): ClearFlags(PENDINGACTIONS,) -> RunMainLoop,AskAllowRecording,
2006-10-13 10:42:04.898 DVBChan(0): Opening DVB channel
2006-10-13 10:42:04.900 DVBChan(0): Using DVB card 0, with frontend 'Nextwave NXT200X VSB/QAM frontend'.
2006-10-13 10:42:04.924 ChannelBase(1): Input #1: 'DVBInput' schan(58) sourceid(3) ccid(1)
2006-10-13 10:42:04.925 ChannelBase(1): Current Input #1: 'DVBInput'
2006-10-13 10:42:04.926 DVBChan(0): SetChannelByString(58):
2006-10-13 10:42:04.932 DVBChan(0): Frequency: 627000000 Modulation: QPSK
2006-10-13 10:42:04.933 DVBChan(0): Old Params: Frequency: 627000000 Modulation: QPSK
                        DVBChan(0): New Params: Frequency: 627000000 Modulation: QPSK
2006-10-13 10:42:04.934 DVBChan(0): Tune(): Tuning to 627000000Hz
2006-10-13 10:42:04.935 dvbchannel.cpp:wait_for_backend: Status:
2006-10-13 10:42:04.936 DVBChan(0): Tune(): Frequency tuning successful.
2006-10-13 10:42:04.937 DVBChan(0): SetChannelByString(58): Tuned to frequency.
2006-10-13 10:42:04.938 TVRec(1): Starting Signal Monitor
2006-10-13 10:42:04.939 TVRec(1): SetupSignalMonitor(1, 0)
2006-10-13 10:42:04.941 DVBChan(0): Opening DVB channel
2006-10-13 10:42:06.064 SM(0)::AddFlags: Seen() Match() Wait(Sig,SNR,BER,UB,)
2006-10-13 10:42:06.065 DVBSM(0)::constructor(): initial flags 0x7400000
2006-10-13 10:42:06.078 TVRec(1): Signal monitor successfully created
2006-10-13 10:42:06.086 TVRec(1): Setting up table monitoring.
2006-10-13 10:42:06.095 TVRec(1): MPEG program number: 4507
2006-10-13 10:42:06.104 DTVSM(0)::SetProgramNumber(4507):
2006-10-13 10:42:06.111 SM(0)::RemoveFlags: Seen(PMT,) Match(PMT,) Wait()
2006-10-13 10:42:06.120 SM(0)::AddFlags: Seen() Match() Wait(PMT,)
2006-10-13 10:42:06.121 SM(0)::AddFlags: Seen() Match() Wait(PAT,PMT,)
2006-10-13 10:42:06.122 SM(0)::AddFlags: Seen() Match() Wait()
2006-10-13 10:42:06.123 TVRec(1): Successfully set up MPEG table monitoring.
2006-10-13 10:42:06.125 SM(0)::Start: begin
2006-10-13 10:42:06.136 SM(0)::Start: end
2006-10-13 10:42:06.145 TVRec(1): SetFlags(SignalMonitorRunning,) -> RunMainLoop,AskAllowRecording,SignalMonitorRunning,
2006-10-13 10:42:06.153 TVRec(1): ClearFlags(WaitingForSignal,) -> RunMainLoop,AskAllowRecording,SignalMonitorRunning,
2006-10-13 10:42:06.161 TVRec(1): SetFlags(WaitingForSignal,) -> RunMainLoop,AskAllowRecording,WaitingForSignal,SignalMonitorRunning,
2006-10-13 10:42:06.173 TVRec(1): ClearFlags(NeedToStartRecorder,) -> RunMainLoop,AskAllowRecording,WaitingForSignal,SignalMonitorRunning,
2006-10-13 10:42:06.178 TVRec(1): SetFlags(NeedToStartRecorder,) -> RunMainLoop,AskAllowRecording,WaitingForSignal,NeedToStartRecorder,SignalMonitorRunn
ing,
2006-10-13 10:42:06.182 Started recording: Pok<E9>mon: Destiny Deoxys: channel 3535 on cardid 1, sourceid 3
2006-10-13 10:42:06.188 scheduler: Started recording: Pok<E9>mon: Destiny Deoxys: channel 3535 on cardid 1, sourceid 3
2006-10-13 10:42:06.332 DVBSM(0)::UpdateValues: Signal Locked
2006-10-13 10:42:06.340 DVBSM(0)::UpdateValues: Waiting for table monitor to start
2006-10-13 10:42:06.342 DVBSM(0)::UpdateValues: Table monitor started
2006-10-13 10:42:06.341 DVBSM(0)::AddPIDFilter(0x0):
2006-10-13 10:42:06.346 DVBSM(0)::RemovePIDFilter(0x0):
2006-10-13 10:42:06.377 DVBSM(0): RunTableMonitorTS(): begin (# of pids 1)
2006-10-13 10:42:06.379 DVBSM(0)::AddPIDFilter(0x0):
2006-10-13 10:42:06.491 SM(0)::AddFlags: Seen(PAT,) Match() Wait()
2006-10-13 10:42:06.492 SM(0)::AddFlags: Seen() Match(PAT,) Wait()
2006-10-13 10:42:06.494 CreatePATSingleProgram()

Here are the relevant database rows for channel 58 and it's associated dtv_multiplex entry:

mysql> select * from channel where channum = '58' and sourceid =3\G
*************************** 1. row ***************************
         chanid: 3535
        channum: 58
         freqid: NULL
       sourceid: 3
       callsign: TOON
           name: TOON
           icon: /home/dab/.mythtv/channels/cartoonnetwork_30.jpg
       finetune: NULL
   videofilters:
        xmltvid: 12131
    recpriority: 0
       contrast: 32768
     brightness: 32768
         colour: 32768
            hue: 32768
       tvformat: Default
       commfree: 0
        visible: 1
  outputfilters:
  useonairguide: 0
        mplexid: 51
      serviceid: 4507
      atscsrcid: NULL
       tmoffset: 0
atsc_major_chan: 0
atsc_minor_chan: 0
1 row in set (0.00 sec)

mysql> select * from dtv_multiplex where mplexid = 51\G
*************************** 1. row ***************************
          mplexid: 51
         sourceid: 3
      transportid: NULL
        networkid: NULL
        frequency: 627000000
        inversion: a
       symbolrate: 0
              fec: auto
         polarity: v
       modulation: qam_256
        bandwidth: a
     lp_code_rate: auto
transmission_mode: a
   guard_interval: auto
          visible: 0
    constellation: auto
        hierarchy: a
     hp_code_rate: auto
       sistandard: atsc
   serviceversion: 33
  updatetimestamp: 20060912174359
1 row in set (0.00 sec)

Is there anything else I can provide to try and figure out why I would get that error message when attempting to record with the hdhomerun and this source? I'm testing this remotely from work, I will try to see if I can use the live tv editor on the newly scanned channels from a mythtv-setup scan I performed using the hdhomerun this evening.

Thanks for looking into this, Dwayne

comment:10 Changed 18 years ago by jwestfall

Attaching hdhr-qam256.diff patch gets my hdhr working with qam256 on comcast. Its untested with ATSC and am a bit iffy on how I am adding in the video/audio PIDs into the pid filter/mask.

Changed 18 years ago by jwestfall

Attachment: hdhr-qam256.diff added

comment:11 Changed 18 years ago by danielk

(In [11520]) Refs #2541. Fixes the segfault when the we fail to set up a signal monitor for a digital channel.

The DTVRecorders require a stream data instance from the DTVSignalMonitor so if we fail to get this we segfault. This patch prevents us from starting up the recorder if we fail to set up the signal monitor. This should only happen if we have filled our channel database with analog channels so I haven't added any on screen error messages, just messages from the backend.

The HDHRRecorder still can only tune true ATSC channels, whether they be over 8-VSB or QAM, another changeset will follow which allows tuning raw MPEG channels.

comment:12 Changed 18 years ago by danielk

Resolution: fixed
Status: newclosed

(In [11521]) Fixes #2541. Allows tuning raw MPEG channels in HDHRRecorder.

The HDHomeRun recorder classes were originally based off the HDTVRecorder (at least partially). The HDHRRecorder only tunes ATSC streams. Since most cable operators have many channels which do not contain ATSC info this means that QAM tuning is only likely to work with HDTV channels, assuming the cable operator is obeying the law (a big assumption in some markets). This copies over some of the pertinent bits of code from the DVBRecorder to the HDHRRecorder, and makes hdhrchannel look at the MPEG Program Number if the ATSC channel info is missing.

The change is based on the patch submitted by jwestfall.

comment:13 Changed 18 years ago by danielk

Milestone: 0.210.20
Resolution: fixed
Status: closedreopened
Version: head0.20

I didn't mean to close this, [11521] should probably be backported to 0.20-fixes.

The segfault [11520] cures should be pretty rare with [11521] applied and could potentially cause problems, so I will not be backporting it.

comment:14 Changed 18 years ago by dab@…

I've just upgraded to svn trunk rev 11550 and this does indeed cure all my QAM256 hdhomerun recording issues, even on my channels.conf imported channels scanned using my Avermedia A180. 8vsb tuning/recording also still works like a charm too.

Thanks danielk, jwestfall, and jafa for looking into this.

comment:15 Changed 18 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(In [11561]) Fixes #2541 in the 0.20-fixes branch. This backports [11521] to allow tuning raw MPEG channels in HDHRRecorder.

From the original commit message:

The HDHomeRun recorder classes were originally based off the HDTVRecorder (at least partially). The HDHRRecorder only tunes ATSC streams. Since most cable operators have many channels which do not contain ATSC info this means that QAM tuning is only likely to work with HDTV channels, assuming the cable operator is obeying the law (a big assumption in some markets). This copies over some of the pertinent bits of code from the DVBRecorder to the HDHRRecorder, and makes hdhrchannel look at the MPEG Program Number if the ATSC channel info is missing.

The change is based on the patch submitted by jwestfall.

Note: See TracTickets for help on using tickets.