Opened 11 years ago

Closed 11 years ago

#7925 closed defect (fixed)

Frontend segfaults when switching channels on HD-PVR input

Reported by: Ken Emerson <kenneth.emerson@…> Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: MythTV - General Version: unknown
Severity: medium Keywords: frontend segfault live tv HD-PVR
Cc: Ticket locked: no


Problem is repeatable:

  1. Select Watch TV (starts on PVR-350)
  2. Change input to HD-PVR
  3. Input changes, no problems yet.
  4. Channel up/down bringing up EPG.
  5. Press SELECT on different channel on HD-PVR input.
  6. STB channel change occurs without a problem.
  7. New channel starts to show, stutters once, then freezes.
  8. FE segfaults.
  9. Changing channels on all other inputs (PVR-250, PVR-350, HDHR, and HVR-1800) all work OK; only HD-PVR causes this problem.

MythTV Version : 23176 MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20100115-1 QT Version : 4.5.0 Options compiled in:

linux debug using_oss using_alsa using_backend using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

Attachments (3)

hdpvr_segfault_livetv_backtrace.txt (35.9 KB) - added by Ken Emerson <kenneth.emerson@…> 11 years ago.
Backtrace from corefile
hdpvr_segfault_livetv_backendlog.txt (1.6 KB) - added by Ken Emerson <kenneth.emerson@…> 11 years ago.
Backend log
hdpvr_segfault_livetv_frontendlog.txt (1.4 KB) - added by Ken Emerson <kenneth.emerson@…> 11 years ago.
Frontend log

Download all attachments as: .zip

Change History (16)

Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

Backtrace from corefile

Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

Backend log

Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

Frontend log

comment:1 Changed 11 years ago by robertm

Status: newinfoneeded_new


Does applying #6602 and #6719 have any effect on this issue for you?

comment:2 Changed 11 years ago by robertm

Also please test #6611.

comment:3 Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

I will attempt these patches this weekend and let you know.

comment:4 Changed 11 years ago by anonymous

I am creating a trunk tree at r24052 (I am currently at 24029) and applying patch 6602 and 6719; however, 6611 fails at this revision. Do you want me to test 6611 by itself with r23670? Also, is r23670 at the same database version as r24052? If not, I may not have an easy way to test as the only system I have is my "production" system.

-- Ken E.

comment:5 Changed 11 years ago by robertm

Try the two you've got, John may be able to provide a refresh to 6611 if that doesn't work.

comment:6 Changed 11 years ago by jpoet

Status: infoneeded_newnew

I just tried applying #6719 and then #6611 to [24052] and did not get any rejections.

In what way is #6611 failing for you?

comment:7 Changed 11 years ago by robertm

Status: newinfoneeded_new

comment:8 Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

This is my output: ken@mythtv:~/mythtv_svn/mythtv-trunk/mythtv$ patch -p0 < hdpvr-signalmonitor-v2.1.patch

patching file libs/libmythtv/analogsignalmonitor.cpp

Hunk #2 succeeded at 124 with fuzz 2 (offset -3 lines).

Hunk #3 succeeded at 163 (offset -3 lines).

patching file libs/libmythtv/analogsignalmonitor.h

patching file libs/libmythtv/mpegrecorder.cpp

Hunk #1 succeeded at 1040 with fuzz 2 (offset -2 lines).

Hunk #2 succeeded at 1519 (offset 4 lines).

Hunk #3 succeeded at 1609 (offset -15 lines).

Hunk #4 succeeded at 1646 (offset -15 lines).

patching file libs/libmythtv/mpegrecorder.h

Hunk #1 succeeded at 83 (offset -1 lines).

patching file libs/libmythtv/signalmonitor.cpp

Hunk #1 FAILED at 94.

1 out of 1 hunk FAILED -- saving rejects to file libs/libmythtv /signalmonitor.cpp.rej patching file libs/libmythtv/signalmonitor.h

Hunk #1 succeeded at 286 (offset -18 lines).

-- Ken E.

comment:9 Changed 11 years ago by jpoet

Status: infoneeded_newnew

Ken, you must apply #6719 before #6611. If you don't then #6611 will fail the way you describe.

comment:10 Changed 11 years ago by anonymous

OK. I have all three patches installed. I haven't had time with frontend to test live TV yet, but preliminary backend tests have shown that recording on both HDHR tuners does not work. It does not matter which tuner is used first (including virtual tuners), the recording on the second tuner fails:

2010-04-16 13:41:26.703 HDHRSH(1013A1B7-0) Error: Get request failed

eno: No such device (19)

Recordings on my HVR1800, HD-PVR, and PVR-350 were successful

Also, recordings made with the HDHR spam with 100's of MB in backend log when commflagging or producing the thumbnail for the recording:

2010-04-16 13:30:10.202 [mpeg2video @ 0xb6ba12e0]invalid mb type in I Frame at 2 59 2010-04-16 13:30:10.212 [mpeg2video @ 0xb6ba12e0]ac-tex damaged at 45 28 2010-04-16 13:30:10.225 [mpeg2video @ 0xb6ba12e0]ac-tex damaged at 83 61 2010-04-16 13:30:10.235 [mpeg2video @ 0xb6ba12e0]ac-tex damaged at 45 29 2010-04-16 13:30:10.242 [mpeg2video @ 0xb6ba12e0]skipped MB in I frame at 24 63 2010-04-16 13:30:10.249 [mpeg2video @ 0xb6ba12e0]skipped MB in I frame at 52 31 2010-04-16 13:30:10.254 [mpeg2video @ 0xb6ba12e0]ac-tex damaged at 93 64 2010-04-16 13:30:10.257 [mpeg2video @ 0xb6ba12e0]ac-tex damaged at 13 32 2010-04-16 13:30:10.262 [mpeg2video @ 0xb6ba12e0]skipped MB in I frame at 14 67 2010-04-16 13:30:10.376 [mpeg2video @ 0xb6ba12e0]00 motion_type at 20 0 2010-04-16 13:30:10.382 [mpeg2video @ 0xb6ba12e0]invalid mb type in P Frame at 60 34

The spam may or may not be related to the patches, as I have seen this behavior before, but I don't remember it being this bad. I also do not know what the condition of the recordings is; will check later using the frontend.

I'll do more testing tonight and tomorrow.

-- Ken E.

comment:11 Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

I now have had a chance to review the video from the recordings mentioned previously. It turns out that all of the HDHR recordings were corrupt. When I tried to view live TV from either HDHR tuner, it was also corrupt. This would explain the tons of errors in the backend logfile. I then powered the HDHR off and back on and life was good. It has been months since I have had any problems with this device; hope it was a fluke (fingers crossed).

I checked out the Live TV and switched back and forth between the HD-PVR, HDHR, HVR-1800 and the PVR-350 and between different channels on the HD-PVR with no problems (detected). Good work.

I traced back the problem with the HDHR and the corruption started prior to my installing any patches so I don't see an correlation there. I will continue to play with this configuration over the weekend and report back the results, but right now it looks like this problem is solved.

-- Ken E.

comment:12 Changed 11 years ago by Ken Emerson <kenneth.emerson@…>

Channel switching on the HD-PVR appears rock solid. No other apparent problems with the patches. I assume that once you commit the patches to trunk you can close out this ticket?

Thanks for the help.

-- Ken E.

comment:13 Changed 11 years ago by robertm

Resolution: fixed
Status: newclosed

Fixed with #6719 and #6611.

Note: See TracTickets for help on using tickets.