Opened 7 years ago

Closed 6 years ago

#11064 closed Bug Report - Crash (Fixed)

LiveTV with HDHR Prime crashes mythfrontend

Reported by: Monkey Pet <monkeypet@…> Owned by:
Priority: minor Milestone: 0.27
Component: MythTV - General Version: Master Head
Severity: low Keywords:
Cc: Ticket locked: no

Description (last modified by Kenni Lund [kenni a kelu dot dk])

Watching LiveTV with HDHR Prime is consistently crashing mythfrontend. The dialog i get refers to max buffering exceeded. I can't exit from it and sometimes it just crashes there.

With 0.25 and 0.26 (Master Head), I tried a few more experiments:

  1. LiveTV - Remote frontend, Tune to a TV Channel within a few mins, it aborts almost immediately with "max buffering exceeded". Frontend will crash and needs to be restarted.
  2. Recording - Now schedule the same channel, same show and start the recording. No remote frontend are viewing the stream. Recording proceeds with no problems.
  3. Recording/then streaming to remote frontend - This works also. I tell myth to record the show, then watch the recording immediately after starting. I am guessing I have to use this as the workaround until the LiveTV streaming is more robust. It sucks that I can't channel surf anymore, but now I can watch almostLiveTV again.

I am really doubting that this is a signal issue. If it was a signal issue, #2 would behavior exactly like #1 and would be aborted also. Also a majority of my recordings are finishing without any issues. However, LiveTV would consistently fail and most of the time fail immediately within the first 5 mins. Also #3 works, so it can't be a signal issue.

I will attach the full logs next.

(gdb) bt
#0  0xb77a9424 in __kernel_vsyscall ()
#1  0xb51f91ef in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb51fc835 in __GI_abort () at abort.c:91
#3  0xb52342fa in __libc_message (do_abort=2, fmt=0xb532c3bc "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#4  0xb523ee42 in malloc_printerr (action=<optimized out>, str=<optimized out>, ptr=0x95626f8) at malloc.c:5007
#5  0xb5240fbf in _int_malloc (av=0xb536c440, bytes=40) at malloc.c:3470
#6  0xb5242d3c in __GI___libc_malloc (bytes=40) at malloc.c:2924
#7  0xb54d313b in qMalloc(unsigned int) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#8  0xb552ebef in QString::realloc(int) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#9  0xb552f23d in QString::append(QString const&) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#10 0xb5534bfe in QString::section(QString const&, int, int, QFlags<QString::SectionFlag>) const ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#11 0xb6cda1d1 in section (aflags=..., aend=<optimized out>, astart=<optimized out>, asep=..., this=<optimized out>)
    at /usr/include/qt4/QtCore/qstring.h:782
#12 SSDP::ProcessData (this=0x90bb330, pSocket=0x90b2bd8) at ssdp.cpp:356
#13 0xb6cdadad in SSDP::run (this=0x90bb330) at ssdp.cpp:301
#14 0xb6b09932 in MThreadInternal::run (this=0x91224e0) at mthread.cpp:79
#15 0xb54dade0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#16 0xb3a32d4c in start_thread (arg=0xa8fe3b40) at pthread_create.c:308
#17 0xb52b5ace in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Backend log:

2012-09-02 17:16:20.798928 I [6287/28999] ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) - RingBuf(/export/data/myth
tv/4766_20120903001527.mpg): Waited 0.5 seconds for data 
                        to become available... 225236 < 327680
2012-09-02 17:16:21.299115 I [6287/28999] ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) - RingBuf(/export/data/mythtv/4766_20120903001527.mpg): Waited 1.0 seconds for data 
                        to become available... 225236 < 3276802012-09-02 17:16:22.299456 I [6287/28999] ProcessRequest ringbuffer.cpp:1098 (WaitForAvail) - RingBuf(/export/data/myth
tv/4766_20120903001527.mpg): Waited 2.0 seconds for data                         to become available... 225236 < 327680
2012-09-02 17:16:27.569263 I [6287/6351] HouseKeeping housekeeper.cpp:221 (RunHouseKeeping) - Running housekeeping thread
2012-09-02 17:17:04.086174 I [6287/6340] TVRecEvent tv_rec.cpp:1043 (HandleStateChange) - TVRec(5): Changing from WatchingLiveTV to None
2012-09-02 17:17:04.105938 E [6287/29068] HDHRStreamHandler hdhrstreamhandler.cpp:211 (UpdateFilters) - HDHRSH(1313E021-0): UpdateFilters called in wrong tune mode
2012-09-02 17:17:05.079236 I [6287/6340] TVRecEvent tv_rec.cpp:830 (FinishedRecording) - TVRec(5): FinishedRecording(4766_2012-09-03T00:15:27Z) damaged recq:<RecordingQuality overall_score="0" key="4766_2012-09-03T00:15:27Z" countinuity_e
rror_count="0" packet_count="365988">    <Gap start="2012-09-03T00:00:00Z" end="2012-09-03T00:15:27Z" duration="927" />
    <Gap start="2012-09-03T00:16:14Z" end="2012-09-03T01:00:00Z" duration="2625" /></RecordingQuality>


Frontend log:

Sep  2 17:16:53  mythlogserver: last message repeated 10 timesSep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: N CoreContext myth
player.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 19896ms for video buffers AAAAAUUUAAUUAAULAuAUUAUAAUAAAAAP
Sep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: E Decoder avformatdecoder.cpp:4493 (GetFrame) decoding error#012#011#011#011eno: Unknown error 541478725 (541478725)
Sep  2 17:16:53  mythlogserver: last message repeated 11 timesSep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: N CoreContext myth
player.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 20012ms for video buffers AAAAAUUUAAUUAAULAuAUUAUAAUAAAAAP
Sep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: E CoreContext mythplayer.cpp:2118 (PrebufferEnoughFrames) Player(0): Waited too long for decoder t
o fill video buffers. Exiting..Sep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: E Decoder avformatdecoder.cpp:4493 (GetFrame) decoding error#012#011#011#011eno: Unknown error 541
478725 (541478725)Sep  2 17:16:54 fa-Macmini mythlogserver: mythfrontend[2949]: I CoreContext tv_p
lay.cpp:2155 (HandleStateChange) TV: Attempting to change from WatchingLiveTV to None

Attachments (4)

mythtv_backtrace.txt (76.0 KB) - added by Monkey Pet <monkeypet@…> 7 years ago.
Backtrace
mythtv_backtrace.2.txt (76.0 KB) - added by Monkey Pet <monkeypet@…> 7 years ago.
Backtrace
mythfrontend.log.bz2 (25.2 KB) - added by Monkey Pet <monkeypet@…> 7 years ago.
logfile from frontend
mythbackend.20120902011908.6287.log.bz2 (48.9 KB) - added by Monkey Pet <monkeypet@…> 7 years ago.
logfile from backend

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by Monkey Pet <monkeypet@…>

Attachment: mythtv_backtrace.txt added

Backtrace

Changed 7 years ago by Monkey Pet <monkeypet@…>

Attachment: mythtv_backtrace.2.txt added

Backtrace

Changed 7 years ago by Monkey Pet <monkeypet@…>

Attachment: mythfrontend.log.bz2 added

logfile from frontend

Changed 7 years ago by Monkey Pet <monkeypet@…>

logfile from backend

comment:1 Changed 7 years ago by Monkey Pet <monkeypet@…>

fa@fa-Macmini:~$ mythfrontend --version xprop: unable to open display Please attach all output as a file in bug reports. MythTV Version : v0.26-rc-17-gf830b84 MythTV Branch : master Network Protocol : 75 Library API : 0.26.20120822-1 QT Version : 4.8.1 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2

comment:2 Changed 7 years ago by Kenni Lund [kenni a kelu dot dk]

Description: modified (diff)
Milestone: 0.26unknown
Priority: criticalminor
Severity: highlow

comment:3 Changed 7 years ago by mythtv@…

Is this the same as #10884 ?

comment:4 Changed 7 years ago by Monkey Pet <monkeypet@…>

This was caused by the HDHR Prime dropping off the network for a few secs during recordings. The workaround is to keep on pinging the HDHR Prime. I have a bug opened with silicon dust. Still mythfrontend should never segfault, but neither should the HDHR drop off the network. Also see bug 10414 where I found the workaround of pinging the HDHR Prime.

comment:5 Changed 6 years ago by stuartm

Milestone: unknown0.27
Resolution: Fixed
Status: newclosed

There have been two different fixes for segfaults in SSDP::ProcessData?(), which is where this backtrace is pointing, since this ticket was created. I'm going to assume that it is fixed in 0.27 but if it is still reproducible then please re-open the ticket.

Note: See TracTickets for help on using tickets.