GNOME Bugzilla – Bug 599970
totem freezes when loading video with subtitles file
Last modified: 2009-11-06 14:19:09 UTC
Totem 2.28.1 freezes everytime I try to open a video (at least avi files) that have .srt files associated. If I remove the .srt file, the video opens normally.
Note that to reproduce this bug you have to activate automatic loading of subtitles in the preferences screen. With that option enabled the bug occurs for every video with srt subtitles, on both Totem 2.28.1 and 2.28.2. I'm using Ubuntu 9.10.
I've been trying to pinpoint the bug myself. Not so easy. :) Here's all I have found out so far: The bug only happens when you open a video from the command line (or by double clicking). If you open Totem and then open a video file with matching subtitles, it works fine. So the bug only occurs when it's both a command line load _and_ auto subtitle loading is enabled. I've been debugging a bit, but I just can't find out where in the source code the program does something different when opening from the command line. The correct video and subtitle uri's are opened, just as when you open from within Totem. The only difference I see is in the debugging information. If the bug occurs, it seems as if Totem opened an "empty" video. Every call to "get_metadata"-like functions results in 0's and NULL values. Also movie size and framerate are 0, which might be the reason Totem freezes. So I'm not sure what's going on. Perhaps when you open a video from command line, it tries to read the metadata too early, before the file is properly opened? Resulting in an unplayable video at 0 fps? But then why does it only happen when it's also loading subtitles? I guess I should wait for someone more knowledgeable about the subject to take a look at it. :)
This seems to be a deadlock to me, the main thread deadlocks on gst_object_get_parent() in reaction to a "subtitle-encoding" changed signal. Probably some kind of lock ordering problem (like one thread takes locks 1 and 2, the other taking locks 2 and 1 in this order). This is the main thread:
+ Trace 218860
As it seems the "caps" property is being set in one thread, which invokes the property changed notification and at the same time and at the same time the mainthread is trying to load the subtitles and sets the subtitle-encoding property, probably on the same object. I guess a well positioned sleep would solve the race, but the real problem is th cross locking.
Commenting out these lines in totem-preferences.c works around the problem for me: encoding_changed_cb (GConfClient *client, guint cnxn_id, GConfEntry *entry, Totem *totem) { const gchar *encoding; GtkComboBox *item; item = GTK_COMBO_BOX (gtk_builder_get_object (totem->xml, "subtitle_encoding_combo")); encoding = gconf_value_get_string (entry->value); - totem_subtitle_encoding_set (item, encoding); - bacon_video_widget_set_subtitle_encoding (totem->bvw, encoding); */ + /* totem_subtitle_encoding_set (item, encoding); + bacon_video_widget_set_subtitle_encoding (totem->bvw, encoding); */ } of course this may not work if you have non-utf8 subtitles.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 600479 ***