Live TV Hangs MythFrontend

[skd5aner <skd5aner@…>]

After upgrading from 0.25-fixes to 0.26-fixes, Live TV is very unstable. Recently, simply launching Live TV often hangs the frontend, and sometimes causes it to crash. I've attached logs with -v record,channel,siparser,network for both the frontend and master backend. I've also attached backtraces for both the frontend and backend during the frontend hang.

I've seen other instabilities with Live TV, and I'm not sure they're related, but I've seen it hang the frontend before video is shown as well as after a few seconds of video. I've also seen a variety of other issues where playback will never start and simply send me back to the main menu - sometimes with errors (i.e., not enough buffers), and sometimes with no error after waiting for a dozen or more seconds.

[skd5aner <skd5aner@…>]

mythbackend log

[skd5aner <skd5aner@…>]

CORRECT mythfrontend log

[skd5aner <skd5aner@…>]

gdb attachment - mythfrontend

[skd5aner <skd5aner@…>]

gdb attachment - mythbackend

[skd5aner <skd5aner@…>]

Added a new gdb.txt (gdb.mfe.2.txt) during a recent hang of the frontend that exhibited the problem I most frequently am seeing now every time I launch live tv... MythFrotend? simply hangs and is non-responsive with a "Please Wait..." dialog box after launching live tv.

[skd5aner <skd5aner@…>]

Possibly related to #11211

[skd5aner <skd5aner@…>]

Discussion of the issue on several email threads in mythtv-users, this one in particular has a lot of "Me Toos" with various detailed reports - might be useful to reference. Two things I've gleaned from the thread so far: ​http://www.gossamer-threads.com/lists/mythtv/users/529836

1) It seems to be happening for users on various kernel versions (3.2, 3.5) who can confirm that when rolling back to 0.25, they no longer experience the issue

2) It may be related to remote frontends. One user reported that the problem didn't seem to exhibit itself on a combined BE/FE machine.

[rob.verduijn@…]

Hello,

Livetv fails after upgrading to 0.26 using hauppauge pvr-150 on opensuse 12.2 x86_64 kernel 3.4.11 Removing and adding the cards via setup does not help. Symptom : The channel starts but freezes completely after a few frames and after a while drops you back in the mythtv menu.

Downgraded to 0.25-2 LiveTV still fails. Removed and added the cards once more. LiveTV worked again.

I can confirm that rolling back to 0.25-2 removes the problem.

Regards Rob

[rob.verduijn@…]

I forgot to mention a few more things

I use a backend/frontend setup (both use the same kernel) via a wired connection (1gb)

When streaming the livetv from the backend I do not get any frames at all just the please wait message.

After I mounted the livetv folder from the backend using nfs on the frontend I got a few frames then the screen freezes and drops me back in the mythtv menu after a while. (with a timeout error)

In both cases recording shows works, however I cannot watch the recording until after it is finished recording.

Rob

[mythtv@…]

I am running Fedora 17 with the RPMFusion packages. I can start Live TV on an analog channel (PVR-500) and it seems to work fine. Changing to another channel on the PVR-500 will give a timeout and exits to the frontend. Going from the PVR-500 to the HDHR Prime works fine. Changing back to another channel on the PVR-500 works fine. It's only changing channels on the PVR-500 that is problematic. I count myself lucky that mythfrontend isn't crashing.

I did not experience this on 0.25.2. Live TV on 0.25.2 was fairly stable.

Here's mythfrontend --version:

MythTV Version : 0.26.0-1.fc17 (v0.26.0-28-ge3087dd)

[terry@…]

I can confirm that this problem does occur with a PVR-250 using Mythtv v0.26.0 on a combined FE/BE machine running kernel 2.6.35.

[Bernie Whalen <bernard.whalen@…>]

I see the same problem on a combined FE/BE running mythbuntu 12.04 with a PVR-150. The kernel version is 3.2.0-33-generic and mythtv version is 0.26.0-42-g10479af

[mythtv@…]

Replying to mythtv@…:

I forgot to add my kernel version. It's 3.6.7-4.fc17.x86_64

[Chad Sawatzky <chad.sawatzky@…>]

Just updated to 0.26 and my experience seems to be the same as others describe. I have a PVR-150 and kernel 3.6.7-4.fc17.i686.PAE

MythTV Version : 0.26.0-1.fc17 (v0.26.0-28-ge3087dd) MythTV Branch : fixes/0.26 Network Protocol : 75 Library API : 0.26.20120822-1 QT Version : 4.8.2 Options compiled in:

linux release use_hidesyms using_alsa using_jack 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_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_libudf 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 using_libudf

[landonzone-ot1@…]

This bug is also affecting my system (FE/BE + 2 FE systems). All three systems are Core i5 systems with at least 2GB of RAM (the FE/BE has 8GB)

The issue in my system is limited to watching LiveTV from the PVR150 card on the FE systems.

I have been able to work around the issue by:

using a LiveTV Storage Group that resides on an Intel SSD.

Exporting that directory via NFS to the FE systems.

Mounting the NFS Share on the FE systems with the nfs mount option "noac" - I am turning off attribute caching on the front ends. Turning off the cache is what ultimately made this work.

[skd5aner <skd5aner@…>]

The following patch, provided by Jim Stichnot, has solved the problem for me in limited testing on 0.26-fixes. I do not know if there are significant other impacts, but I just wanted to share my (very) positive results related to my specific problem documented in the ticket:

​http://pastebin.com/vqyqcE3X

[Jim Stichnoth]

Marking this as a duplicate of #11211, which was fixed in a1b9b1f94a774710443637de034c661618e5baa3.

Note that this fixes a specific regression introduced in 0.26. Live TV bugs present in 0.25 may still be lurking.

[jidping@…]

Replying to skd5aner <skd5aner@…>:

The following patch, provided by Jim Stichnot, has solved the problem for me in limited testing on 0.26-fixes. I do not know if there are significant other impacts, but I just wanted to share my (very) positive results related to my specific problem documented in the ticket:

​http://pastebin.com/vqyqcE3X

I had same issue with 0.26-fixes and pvr150 and the patch has solved the problem. Can it be commited in 0.26-fixes so mythbuntu can pick it up?

Thanks

[Jim Stichnoth]

To be clear, the pastebin patch was just a proof of concept meant for testing and verifying the root cause. It's not appropriate for committing to the MythTV code base because it makes changes to the underlying ffmpeg code which would have to be maintained across future ffmpeg resyncs.

In any case, a more reasonable fix was pushed to fixes/0.26 about two hours before your comment. Look for version v0.26.0-93-ga1b9b1f or later.

[jidping@…]

Replying to stichnot:

To be clear, the pastebin patch was just a proof of concept meant for testing and verifying the root cause. It's not appropriate for committing to the MythTV code base because it makes changes to the underlying ffmpeg code which would have to be maintained across future ffmpeg resyncs.

In any case, a more reasonable fix was pushed to fixes/0.26 about two hours before your comment. Look for version v0.26.0-93-ga1b9b1f or later.

Thanks for fixing it. It works great.