Breezy Totem freezes when playing DVDs

[Steve Laniel]

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)]

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)]

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)]

thanks, seems to be a libxine issue

[Steve Laniel (steve-laniels)]

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

[Sebastien Bacher (seb128)]

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