Opened 14 years ago
Closed 14 years ago
#7925 closed defect (fixed)
Frontend segfaults when switching channels on HD-PVR input
Reported by: | 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 |
Description
Problem is repeatable:
- Select Watch TV (starts on PVR-350)
- Change input to HD-PVR
- Input changes, no problems yet.
- Channel up/down bringing up EPG.
- Press SELECT on different channel on HD-PVR input.
- STB channel change occurs without a problem.
- New channel starts to show, stutters once, then freezes.
- FE segfaults.
- 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)
Change History (16)
Changed 14 years ago by
Attachment: | hdpvr_segfault_livetv_backtrace.txt added |
---|
comment:1 Changed 14 years ago by
Status: | new → infoneeded_new |
---|
comment:4 Changed 14 years ago by
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 14 years ago by
Try the two you've got, John may be able to provide a refresh to 6611 if that doesn't work.
comment:6 Changed 14 years ago by
Status: | infoneeded_new → new |
---|
comment:7 Changed 14 years ago by
Status: | new → infoneeded_new |
---|
comment:8 Changed 14 years ago by
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 14 years ago by
Status: | infoneeded_new → new |
---|
comment:10 Changed 14 years ago by
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 14 years ago by
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 14 years ago by
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 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Backtrace from corefile