Breezy Totem freezes when playing DVDs

Bug #17685 reported by Steve Laniel on 2005-06-01
8
Affects Status Importance Assigned to Milestone
totem (Ubuntu)
Medium
Sebastien Bacher

Bug Description

When I upgraded to Breezy, Totem (running over totem-xine) stopped being able to
play DVDs. It may play the DVD menu properly, but eventually it locks up --
locks up so severely that I have to Force Quit it every time. I've not yet been
able to play more than a minute of a DVD under Breezy Totem.

I typically -- though not always -- get this error in the console window near
the time of the lockup:

libdvdnav: Language 'en' not found, using '\uffff\uffff' instead
libdvdnav: Menu Languages available: \uffff\uffff

I'm running the latest version of libdvdnav4 (version 0.1.9-3). I'm not sure if
that's really the problem.

I'd run a debug build of Totem, but it appears that the only ones available are
for Hoary. If someone points me to a .deb of a Totem debug build, I'll gladly
install it.

Sebastien Bacher (seb128) wrote :

I don't have such issue with the current versions. What architecture are you
using? Can you get a backtrace of the hang with gdb:
- gdb totem
(gdb) run
... hang
(gdb) thread apply all bt

Steve Laniel (steve-laniels) wrote :

I'm running under i386. Here's what gdb reported:

Program received signal SIGINT, Interrupt.
[Switching to Thread -1225267520 (LWP 9169)]
0xffffe410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 11 (Thread -1318794320 (LWP 9188)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb728300e in __lll_mutex_lock_wait ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb72852dd in _L_mutex_cond_lock_33 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#3 0x00000000 in ?? ()
#4 0xb5133028 in ?? ()
#5 0xb7285198 in __pthread_mutex_cond_lock ()
   from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb7280e9f in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb7b7e3b1 in _x_ao_new_port () from /usr/lib/libxine.so.1
#8 0xb7b78e46 in xine_get_next_video_frame () from /usr/lib/libxine.so.1

Thread 9 (Thread -1306899536 (LWP 9179)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7280b76 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7b80138 in xine_event_wait () from /usr/lib/libxine.so.1
#3 0x08979d88 in ?? ()
#4 0x00000001 in ?? ()
#5 0xb7b8053c in xine_event_dispose_queue () from /usr/lib/libxine.so.1
#6 0x00000000 in ?? ()
#7 0x00000000 in ?? ()
#8 0xb21a44c8 in ?? ()
#9 0xb727e47a in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7292540 in ?? ()
#11 0xb7efad10 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
Previous frame inner to this frame (corrupt stack?)
#0 0xffffe410 in __kernel_vsyscall ()

Sebastien Bacher (seb128) wrote :

thanks, seems to be a libxine issue

Steve Laniel (steve-laniels) wrote :

Yeah, the problem seems to have disappeared. Thanks much.

Sebastien Bacher (seb128) wrote :

I'm closing the bug so. Feel free to reopen if that happens again.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.