totem-xine crash on logo (workaround inside)

[GonzO]

I discovered the following bug today: When starting totem, I receive a crash that looks like the following:

The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 65 error_code 1 request_code 141 minor_code 13)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I have an i915 on-board video. If I open Totem by _clicking on a movie or song_, Totem works just dandy. At home, Totem opens, but the logo in the video window peels into place (from top to bottom), a process that takes about five seconds.

Based on that, I went into /usr/share/totem, and renamed "totem_logo.png" to "totem_logo.png.old" - wouldn't you know it, this fixes the problem.

Apparently, Totem trying to render .pngs can be problematic.

[GonzO (gonzo)]

More information on this: I've noticed, on every system I've ever installed Ubuntu on (about twenty, now), that Totem will VERY RELIABLY crash whenever it attempts to play any video of sufficient resolution. I have a couple of really high-definition videos (one is 1024x768, and one is 1280x1024) that Totem simply cannot run. I can produce this error just about anywhere. I think (but can't prove) that this has to do with the amount of available video RAM - the 1280x1024 will crash my computer here and at home; but the 1024x768 video runs at home (where I have a 6600GT, instead of an i915 onboard).

The "splash" screen for totem (the cutboard with the word "totem" on it) is currently a 1280x1024 PNG. Based on how slow it is to open this image (on my home machine - takes about five seconds for the image to "peel" into place from the top to the bottom), and based on the fact that it straight up crashes here, I'm willing to bet that Totem is trying to open that PNG as a movie, and this creates the reliable crash I've listed above.

Workaround: Scaling down the image resolution for totem_logo.png (<= 720 pixels wide), or removing totem_logo.png altogether both allow Totem to open as usual.

[Sebastien Bacher (seb128)]

Thanks for the useful informations on that. Could you get a backtrace?
- gdb totem
(gdb) break gdk_x_error
(gdb) run --sync
... crash
(gdb) thread apply all bt

[GonzO (gonzo)]

me@me:/usr/share/totem$ gdb totem
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) run --sync
Starting program: /usr/bin/totem --sync
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1224276288 (LWP 14215)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no...

[wlx (wangliangxu)]

I have the same problem with i915 on-board video, and I have renamed the totem_logo.png.

wlx@cngis:~$ totem --debug

** (totem:5803): WARNING **: Trying to connect to an older version of the GNOME screensaver
load_plugins: skipping unreadable plugin directory /home/wlx/.xine/plugins.
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_flac.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_flac.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_none.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_file.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_oss.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_alsa.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_arts.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_ao_out_esd.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_opengl.so foundload_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_xshm.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_xv.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_xvmc.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_decode_dxr3_video.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_vidix.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_vidix.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_aa.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_fb.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_sdl.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_caca.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_xxmc.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_none.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_decode_real_audio.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_decode_dxr3_spu.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_dxr3.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_vo_out_dxr3.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_vcd.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_file.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_http.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_dvd.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_vcdo.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_v4l.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_v4l.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_gnome_vfs.so foundload_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_smb.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_mms.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_stdin_fifo.so found
load_plugins: plugin /usr/lib/xine/plugins/1.1.1/xineplug_inp_pnm.so found
load_plugins: plugin /usr/li...

[Sebastien Bacher (seb128)]

might be the same issue than bug #35896

[GonzO (gonzo)]

Wow. Sure does look like it.

[Sebastian Dröge (slomo)]

should be fixed with libxine-main1 1.1.1+ubuntu2-5. please reopen otherwise :)

[James Clark (jjc)]

I still get the problem with 1.1.1+ubuntu2-6.

[Sebastien Bacher (seb128)]

do you have libgtk2.0-0 installed?

[GonzO (gonzo)]

I still get the problem as well. Yes, I do have libgtk2.0-0 installed.

[James Clark (jjc)]

Yes I have libgtk2.0-0 installed. The debug output says it's using the gdkpixbuf for video streamtype 3d.

If I put a breakpoint on exit(), go up the stack to outside the X library, and disassemble the code before the PC, the last call before XSync is XvShmPutImage.

[Jim Gettys (jg-laptop)]

I also see this problem, and the workaround works for me (tm).

It would seem possible Totem is just creating a huge logo pixmap, asks the server for the space, and fails to get it, causing the error.

XAA's memory allocator is really very bad...
       - Jim

[Sebastien Bacher (seb128)]

the logo ressource issue is what the new gdkpixbuf component should fix and it works fine for me ... maybe you guys face a different issue

Do you get the crash if you start with a movie argument (so it doesn't use the logo)? Does it happen if you reduce the window (you can run it on a movie, change it, close and open without argument to try that)?

[GonzO (gonzo)]

Sebastien: Totem does not crash when opened by launching something (double-clicking on a song or movie), or any other method by which the .png is not used. It has been working (by launching something) this whole time - it only crashes whenever the .png is called.

The original workarounds (changing image size, deleting image altogether) still allow T to work without crashing when just launched by itself (valid as of five minutes ago).

[James Clark (jjc)]

The workaround of scaling the image down to 640x512 works for me. I'm using a 945GM with the i810 driver.

[Rikard Nordgren (rikard-nordgren)]

I can also confirm that with the latest upgrades of dapper totem still crashes upon startup.

[Zack Cerza (zcerza-deactivatedaccount)]

I can also confirm all this, on my i915GM. The workaround I've been using is to first start xine, then start totem, then quit xine. Totem's logo then loads so slow I can watch it paint each pixel - yay!

[Gert Kulyk (gkulyk)]

Bug still there, workaround of scaling down the image seems to work for me. (i915GM, i810-driver)

[Antonio Amaro (ajsamaro)]

Great Fix: scaling down image. This way totem-xine works fine and I don't loose the original look of it.
I've used Gimp.

I've notice one thing, before trying this fix: is that totem din't crash if I opened it in any second-user-login.

So it seems to me that is an hardware management issue. That thing about "video RAM" said on top fits with this.
I hope this comment helps fiding the video bug.

[Gary Coady (garycoady)]

The backtrace I see with this (from an ATI Rage 128 controller) is:
(gdb) bt
#0 gdk_x_error (display=0x842d3a8, error=0xb4ebf200) at gdkmain-x11.c:599
#1 0xb7dcb035 in bonobo_ui_gtk_module_info_get ()
   from /usr/lib/libbonoboui-2.so.0
#2 0xb7214cea in _XError () from /usr/lib/libX11.so.6
#3 0xb721529e in _XReply () from /usr/lib/libX11.so.6
#4 0xb720cee3 in XSync () from /usr/lib/libX11.so.6
#5 0xb52e4aff in xv_display_frame (this_gen=0x8434038, frame_gen=0x8840f30)
    at video_out_xv.c:801
#6 0xb75581df in overlay_and_display_frame (this=0x8435c30, img=0x8840f30,
    vpts=-5409964445402999896) at video_out.c:1002
#7 0xb755951a in video_out_loop (this_gen=0x8435c30) at video_out.c:1137
#8 0xb73a8341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9 0xb71714ee in clone () from /lib/tls/i686/cmov/libc.so.6

The line that possibly causes the X error is on line 785 of src/video_out/video_out_xv.c in xine-lib:
    XvShmPutImage(this->display, this->xv_port,
                  this->drawable, this->gc, this->cur_frame->image,
                  this->sc.displayed_xoffset, this->sc.displayed_yoffset,
                  this->sc.displayed_width, this->sc.displayed_height,
                  this->sc.output_xoffset, this->sc.output_yoffset,
                  this->sc.output_width, this->sc.output_height, True);

I haven't really done much X programming, but I suspect there should be an X error handler (set with XSetErrorHandler), which then falls back to another (non-accelerated) implementation...

A similar issue to bug 4229.

[Jeff Vehrs (icemanv9)]

Today (Jul 4th), I found out that totem(-xine) crashed. I did scaled down the png file from 1280 to 1024. It worked. For pete's sake, the fix is very much needed to kill this bug.

[Sebastien Bacher (seb128)]

Jeff, such comments are not useful and a fix is different of a workaround

[Geert Braekmans (shadowhunter-gb)]

I know this is not a fix but eh...

What if we changed the default output driver and tried with Xv or Xshm of something?

I only couldn't find how to do this...

Geert.

[Sebastien Bacher (seb128)]

That upload fixes the issue:

 totem (1.5.4-0ubuntu1) edgy; urgency=low
 .
   * New upstream version:
     - update xine-lib requirement to avoid startup crashes
   * debian/control.in:
     - require libxine 1.1.2 according to configure
 .
 totem (1.5.3-0ubuntu1) edgy; urgency=low
 .
   * New upstream version:
     - Text subtitle encoding is now selectable
     - Numerous Browser Plugin enhancements:
       - Try to cache files while playing them
       - Add support for cache=true hint
       - Fix getting the true path for relative paths
       - Add support for audio-only playback
       - Add a way to copy the URL from the right-click menu
       - Add "Open in Movie Player" in the right-click menu
     - Make showing/hiding the sidebar not resize the video or the window
     - Pop down language and subtitle menus to avoid hangs when the language or
       subtitle changes while the menu is open
     - Add AC3 and Monkey's audio to the known filetypes
     - Draw the logo ourselves, so we don't crash on startup if the logo is too
       big for the X video buffer (Ubuntu: #35229)
     - Show the logo when playing audio without visualisations
     - Fix a crash with non-default buffering values (GStreamer)
     - Fix a leak each time the logo was set (GStreamer)
     - Fix the "Skip to" dialogue not working when paused (GStreamer)

[Adriaan Peeters (apeeters)]

Any chance to fix this in Dapper?

[Sebastien Bacher (seb128)]

totem-xine is an universe package so not a priority but will consider it, for reference the upstream patch for it:
http://cvs.gnome.org/viewcvs/totem/src/backend/bacon-video-widget-xine.c?r1=1.228&r2=1.228.2.1&makepatch=1&diff_format=u

[Sebastien Bacher (seb128)]

John, you don't want to backport totem 1.5.4 to dapper, do you?

[John Dong (jdong)]

Ugh, I don't know, it sounds risky but may be worth the try, as I don't
think you can have a version of Totem any more unstable on my two 1280x800
machines than this! :)

On 7/13/06, Sebastien Bacher <email address hidden> wrote:
>
> John, you don't want to backport totem 1.5.4 to dapper, do you?
>
> --
> totem-xine crash on logo (workaround inside)
> https://launchpad.net/bugs/35229
>

[Sebastien Bacher (seb128)]

what version is unstable? the dapper one? if that's the case you should open bug and not push a new unstable version to user based on your experience because totem is not that unstable for other people

[John Dong (jdong)]

I'm just saying, at this point, totem with the xine backend does not even
open on my system without these workarounds, so something has to be done
about it. I will not push a buggy version of totem into backports either,
but totem is such an important program for the GNOME desktop and honestly a
good chunk of totem users are using the xine backed for better media
compatibility anyway, so please do consider doing some kind of fix for this.

On 7/13/06, Sebastien Bacher <email address hidden> wrote:
>
> what version is unstable? the dapper one? if that's the case you should
> open bug and not push a new unstable version to user based on your
> experience because totem is not that unstable for other people
>
> --
> totem-xine crash on logo (workaround inside)
> https://launchpad.net/bugs/35229
>

[Sebastien Bacher (seb128)]

that's what that bug is about, patching for the logo issue, why do you think it requires a backport or an unstable version rather than an easy patch?

[John Dong (jdong)]

I'm not saying that it requires a backport of an unstable version; I'm just
saying that if by chance using dapper-updates to backport that patch does
not work, we can now accomplish the same task via the dapper-backports
manual upload mechanism. Just another failover for this pesky bug :)

On 7/13/06, Sebastien Bacher <email address hidden> wrote:
>
> that's what that bug is about, patching for the logo issue, why do you
> think it requires a backport or an unstable version rather than an easy
> patch?
>
> --
> totem-xine crash on logo (workaround inside)
> https://launchpad.net/bugs/35229
>

[Sebastien Bacher (seb128)]

isn't backport supposed to be a build of the new distribution without source change? anyway it'll be fixed with dapper-updates so no need of a backport task

[John Dong (jdong)]

On 7/13/06, Sebastien Bacher <email address hidden> wrote:
>
> isn't backport supposed to be a build of the new distribution without
> source change?

Yes, in general it is, but now we have the infrastructure to make exceptions
to that when necessary.

anyway it'll be fixed with dapper-updates so no need of a
> backport task

Alright, glad to hear that. I'll reject the Backports bug then.

Thanks for your hard work!

--
> totem-xine crash on logo (workaround inside)
> https://launchpad.net/bugs/35229
>

[John Dong (jdong)]

To be fixed via dapper-updates.

[H.E. Pennypacker (klop2964)]

I too had this problem using i915 (not sure if my card being i915 is relevant), and this work-around worked too. Remarkable. I thought it would have been something far more difficult or complex. Thanks again, and I hope this will be solved through a fix of some kind.

[Gert Kulyk (gkulyk)]

I'm not sure what version you want to upload to dapper-updates, but 1.4.3 fixes the issue. I've created packages for my own today, later I'm going to upload them to my university-account, so that you can test them. The sources are already there :-)

http://userpage.fu-berlin.de/~gkulyk/totem_1.4.3-0ubuntu0.1.dsc
http://userpage.fu-berlin.de/~gkulyk/totem_1.4.3-0ubuntu0.1.diff.gz
http://userpage.fu-berlin.de/~gkulyk/totem_1.4.3.orig.tar.gz

[Gert Kulyk (gkulyk)]

Now the binaries are online. Simply go to

http://userpage.fu-berlin.de/~gkulyk/

and test them. :-)

[Gert Kulyk (gkulyk)]

If you don't want to upload totem-1.4.3, here is a patched 1.4.1-version (this time only dpatch):

[Gert Kulyk (gkulyk)]

Now also the binaries of the patched 1.4.1-version are online. Simply go to

http://userpage.fu-berlin.de/~gkulyk/

Please let me know, what to do to get one of the versions (I prefer the 1.4.3-one, because of additional fixes) as fast as possible to dapper-updates.

[Gert Kulyk (gkulyk)]

I got the information from Sebastien, that Daniel is working on it. I didn'nt know before, therefore I apologize for the traffic I caused. I hope that the new packages are uploaded soon.

[Daniel Holbach (dholbach)]

 totem (1.4.3-0ubuntu1) dapper-updates; urgency=low
 .
   * New upstream release:
     - Bugs fixed:
       - "[dapper][totem-xine] when I try to change connection speed it
          crashes" (Malone: #41099)
     - 1.4.3:
       - Add AC3 and Monkey's audio to the known filetypes
       - Draw the logo ourselves, so we don't crash on startup if the logo is
         too big for the X video buffer (xine-lib) (Malone: #35229)
       - Fix a leak each time the logo was set (GStreamer)
     - 1.4.2:
       - Make showing/hiding the sidebar not resize the video or the window
       - Fix saving non-relative m3u playlists, and parsing relative PLS
         playlists
       - Fix DVD playback when started from gnome-volume-manager
       - Pop down language and subtitle menus to avoid hangs when the language
         or subtitle changes while the menu is open
       - Add Impulse Tracker and MOD files to the list of supported types
       - Add audio/vnd.rn-realaudio as a supported playlist format
       - Fix a new installation of Totem not using visualisation (GStreamer)
       - Fix a possible crash when the buffering is set to non-default values
         (GStreamer)
   * debian/control.in:
     - Bumped Build-Depends according to configure.in.
   * debian/patches/07_default_visual_effect.dpatch,
     debian/patches/08_fix_overflow_when_calculating_ratio.dpatch:
     - dropped, included in release.

[Andrea Corbellini (andrea.corbellini)]

Same problem, on Feisty when trying to open http://upload2.net/page/download/CfLJKwEMrzJTw5I/dragdropurls.ogg.html (linked in bug #152975).

[Chris Waigl (cwaigl)]

I just saw a problem that looks very much the same, after upgrade from Feisty to Gutsy. Worked fine before.

chris@FAITH:~$ totem &
[1] 9382
chris@FAITH:~$ The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 42 error_code 8 request_code 141 minor_code 14)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[Dag-Erling Smørgrav (dag-erling)]

Same as Chris Waigl. Worked fine with Feisty. The previously mentioned workaround (scaling or removing totem_logo.png) does not work. Furthermore, gxine fails in the exact same manner:

The program 'gxine' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 326 error_code 8 request_code 141 minor_code 14)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Really annoying, as I just got season 5 of the Simpsons for Christmas. I watched the first four seasons without a hitch on Feisty.

I was able to watch the first episode using totem-gstreamer. I also tried vlc, but the image was very jumpy, and navigation was almost impossible as I could not see the mouse pointer while it was inside the vlc window.

[Dag-Erling Smørgrav (dag-erling)]

Correction, I was able to watch the first episode using mplayer. With the gutsy-backports version, I was even able to see (but not use) the menus. With totem-gstreamer, I was not able to see anything but an error message about missing codecs.

[Dag-Erling Smørgrav (dag-erling)]

I did some more digging. The problem Chris and I are seeing is completely unrelated; it is actually a dupe of #130696, which mentions several workarounds.

[juan Lopez-Amor Varela (juanlopezamorvarel)]

  No Funciona el DVD

[Tom (tom6)]

wow, i'm not finding this problem in Totem 2.24.3 with the splash screen and don't remember it affecting me before either. I must be just lucky i guess. I think i don't play stuff that's that high res in the first place although i do play HD so i'm not sure - prolly just lucky there too.

[Tom (tom6)]

Oopps, just noticed how ancient this thread is. Guess it's all been fixed now.

[pont.andersson (pont.andersson-deactivatedaccount)]

I want to comment that this bug is still in Ubuntu 10.04 and it can be forced by starting file after file after file until it crashes..
So if you go through your music eg. and start one track and then another and so on it will crash after a while. pretty enoying.

[Jacob Peddicord (jpeddicord)]

pont.andersson:

Please file a new bug, as that is likely a separate issue. This just has to do with Totem crashing when it tries to show its logo.