Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Solution: frontend crash on playback

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


mike at halfmytime

Dec 30, 2004, 12:00 AM

Post #1 of 2 (1262 views)
Permalink
Solution: frontend crash on playback

Hey all,

My appollogies if this has already been covered, but I just worked
around a nasty hangup and I'm pretty excited about it, so I thought I'd
share in case anyone else is where I was for about the last 4 days.

Symptom:
Mythfrontend would crash at the start of playback if I selected a
recording for a second time (play, back to menu, play again, boom).
Changing whether the position was saved on exit didn't help. If I
selected one video and then another, it would work, but it would
eventually crash when it started to play about the 4th or 5th
recording. It would also crash at other times and was unstable in
general, but the times I just mentioned were very predicatble. My
backend was also very unstable. There was nothing unusal in
mythfrontend's output except "Killed" at the end. What especially
perplexed me was that I didn't change the configuration at all when the
instability developed. It was solid for the first 5 or so days after I
set it up.

System:
AMD Athlon XP 2400, NForce2 Motherboard, 2x Hauppauge 250, Samsung 160GB HD
MythTV .016, Gentoo with vanilla 2.6.9 kernel, NVidia Drivers 1.0.6629

Solution:
After a few days of dead ends (I thought the HD was dying, but cloning
it to another drive made no difference - helloooo 320GB once I get LVM
working:) I found help with this list post:
http://www.gossamer-threads.com/lists/mythtv/users/96713?search_string=%2Fdev%2Fdri%2Fcard0;#96713
I never realized mythfrontend's --verbose option took arguments.

# mythfrontend --verbose playback
--- SNIP ---
2004-12-29 23:06:58 Changing from None to WatchingPreRecorded
2004-12-29 23:06:58 nVidiaVideoSync: VBlank ioctl did not work,
unimplemented in this driver?
2004-12-29 23:06:58 DRMVideoSync: Could not open device /dev/dri/card0,
No such file or directory
Killed

Exactly the output in the post. Apparently the problem is with OpenGL
vsync and NVidia drivers.
Elsewhere in the thread someone mentioned that you can disable OpenGL
VSYNC in Myth by commenting out the OpenGL VSYNC block in the
settings.pro file in the Myth source directory and recompiling from scratch

settings.pro:
# OpenGL support for vertical retrace sync
#DEFINES += USING_OPENGL_VSYNC
#EXTRA_LIBS += -lGL -lGLU
#CONFIG += using_opengl

shell:
make clean distclean && ./configure && make && make install

Now that I'm looking around I little more I see that for Gentooers,
adding "-opengl" to your use flags and re-emerging MythTV will
accomplish the same thing with less keyboard on your hands. Also, I
don't know if it's necessary to comment-out the "EXTRA_LIBS" and
"unsing_opengl" lines too. I'm guessing it's not, but I don't want to
experiment with it just yet.

This has completely cleared up the problem for me, and even the backend
instability has gone away. I've been abusing it for about an hour and a
half (starting playback, stopping, rewinding, Live TV, recording,
program guide, aggressive editing of recording schedules), and
everything looks great. I am STOKED! I suppose I'm not using OpenGL
anymore, but this is a fast system with hardware encoding, so I have a
few cycles to spare, and I don't feel like worrying about it right now.
I've got time-shifted Aquateens to watch once I finish this email. But
first...


My Uneducated Theory:
Backtrace on the same crash shows that it's crashing inside the OpenGL
library provided by NVidia

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 196616 (LWP 1055)]
0xb64ec226 in _nv000833gl () from /usr/lib/libGLcore.so.1
(gdb) bt
#0 0xb64ec226 in _nv000833gl () from /usr/lib/libGLcore.so.1
#1 0xb73d4210 in _nv000030gl () from /usr/lib/libGL.so.1
#2 0x00030008 in ?? ()
#3 0x0000041f in ?? ()
#4 0xb7f2dda8 in ?? () from /usr/lib/libmythtv-0.16.so.0
(gdb) kill

If it's crashing because it can't open /dev/dri/card0, thien it makes
sense, because there's no such file in my /dev filesystem. Now, I'm not
particularly familiar with udev, but from what I understand that kind of
heirarchical /dev structure is a udev thing. So maybe the whole problem
is that NVidia's OpenGL is expecting a system that's running 2.6 to be
running udev and have a /dev/dri/card0, but Gentoo hasn't graduated to
udev yet, so there is none. Somebody let me know if I'm on the right
track here.


Oh hell yes it's a Moononites episode!

Good Luck Everybody,
Mike

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


doug at ties

Dec 30, 2004, 3:40 AM

Post #2 of 2 (1164 views)
Permalink
Re: Solution: frontend crash on playback [In reply to]

mikemurphy wrote:
> Hey all,
>
> My appollogies if this has already been covered, but I just worked
> around a nasty hangup and I'm pretty excited about it, so I thought I'd
> share in case anyone else is where I was for about the last 4 days.
[snip]
> Exactly the output in the post. Apparently the problem is with OpenGL
> vsync and NVidia drivers.
> Elsewhere in the thread someone mentioned that you can disable OpenGL
> VSYNC in Myth by commenting out the OpenGL VSYNC block in the
> settings.pro file in the Myth source directory and recompiling from scratch
[snippage]
> My Uneducated Theory:
> Backtrace on the same crash shows that it's crashing inside the OpenGL
> library provided by NVidia

Yes. What nVidia version are you running? Anything prior to 6111 is
known to cause this problem.

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 196616 (LWP 1055)]
> 0xb64ec226 in _nv000833gl () from /usr/lib/libGLcore.so.1
> (gdb) bt
> #0 0xb64ec226 in _nv000833gl () from /usr/lib/libGLcore.so.1
> #1 0xb73d4210 in _nv000030gl () from /usr/lib/libGL.so.1
> #2 0x00030008 in ?? ()
> #3 0x0000041f in ?? ()
> #4 0xb7f2dda8 in ?? () from /usr/lib/libmythtv-0.16.so.0
> (gdb) kill
>
> If it's crashing because it can't open /dev/dri/card0, thien it makes
> sense, because there's no such file in my /dev filesystem.

No, the nVidia driver is not looking for /dev/dri/card0. That's for the
"DRI" vsync method (which fails, because your hardware doesn't support
it). /dev/nvidia0 (another vsync method, the vblank ioctl method
message) *is* there, but also fails because your nVidia driver version
is too new. OpenGL is the first one that succeeded.

If you can get it to work, OpenGL will give better video smoothness than
RTC (which you are probably using), or usleep w/ busy-wait (which also
consumes more CPU). As an exercise, see if you can spot the --verbose
playback output that tells you which you're using, and if it's not RTC,
search the list archives to see what to do about it.

-Doug
Attachments: signature.asc (0.25 KB)

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.