Internal video player lockup

[marcus.t.andersson@…]

When watching a recording, press fast forward. Then press 'p' (pause/play) quickly a couple of times. The player stops responding.

I use the MiniMyth? 0.20.2-31 distribution.

This could be related to Changeset 14358. (​http://svn.mythtv.org/trac/changeset/14358)

[mythtv@…]

I have a similar problem with mythtv_0.20.2-0ubuntu10.1. However, I'm only seeing the problem plaing imported videos (.vob's) in mythvideo, not while playing recordings in mythtv. I think I have a fix for my problem (which is in mythtv, not mythvideo) and wonder if it might fix your problem, too.

What I would like to know is if you have the means to get a core dump of mythfrontend when the deadlock occurs, and can examine it with gdb, so I can confirm whether your problem is the same? I.e. kill -segv <mythfrontend-pid> produces a core file that can be examined with gdb. I'm not sure you can, given the fact that MiniMyth? is a diskless version.

If you can get a core dump and can get stack backtraces out of gdb that confirm it is the same problem, then can you build MiniMyth? with my fix and see if it fixes your problem?

If you can't get a core dump, then I think I need to create a separate ticket and recruit testers who can get core dumps. If my fix solves problems for someone other than me, hopefully it will make it into the a patch that filters down to the various distros, including MiniMyth?.

I'm new to Trac, so I hope you'll be notified of my comment and we'll have a means to communicate.

[stuartm]

A lot has changed since 0.20, can this issue be reproduced using trunk? At this point we're really only interested in fixing bugs which still appear in the development version and not the 0.20(-fixes) branch.

[mythtv@…]

I don't know if it can be reproduced in trunk, but I can tell you that the code I changed to fix the deadlock has not changed in trunk. Which leads me to believe it might be possible to reproduce it in trunk.

As a developer with 20+ years of experience, I can certainly understand your hesitation. However, 0.20.2 is in wide use and I suspect I'm not the ony one who has encountered this deadlock.

FWIW, I don't have a second machine to set up a trunk development environment to confirm this. If that's a showstopper for considering my patch, then perhaps I should try to share it with some downstream group, like debian-multimedia.org or mythbuntu? Or see if I can recruit some testers in the various user forums to validate the problem and the fix?

I suppose I could set up a separate root partition, or learn how chroot works so that I don't clobber my current mythtv setup. I am dependent on mythtv now so booting into a separate root partition means either choosing when I test so I can still record with 0.20.2 or losing out on some favorite shows. I don't know how deep chrooting goes, so I would want to be very careful about mysql, and perhaps some other gotchas I don't know about. Your thoughts?

After summitting this reply, I will attach my patch. It's pretty small, mostly comments in videoout_xv.cpp. The substance involves swapping two lines in that source file. It also includes a patch to RingBuffer?.cpp, which I know is already in trunk. Perhaps someone would be willing to take a few minutes and look at the comments in the videoout_xv.cpp portion of the patch?

[anonymous]

I can create a core dump in MiniMyth?, it has a file system as usual, in ram. I am not sure exactly when I will get the time to do it though. Don't let me stop you from going forward with the patch.

[mythtv@…]

Backtrace of two threads when mythfrontend deadlocks, fixed by deadlock.patch

[danielk]

We've rewritten this code in trunk + we're no longer fixing 0.20-fixes.