GNOME Bugzilla – Bug 706949
tsdemux: totem slider handle resets when moved manually
Last modified: 2013-09-08 22:40:12 UTC
I observed while playing .ts files (MPEG2 transport streams) in v3.6.3 that, although the movie will play fine and the slider will progress on its own correctly, that any attempt, whether via keyboard shortcut or click-and-drag, to move the slider handle will adjust playback at the "correct" spot, but the slider handle will reset itself all the way to the left, along with the playtime (the numerator) resetting to 0:00. At that point, the time will continue to increase and the slider will move on its own again, as though the movie has restarted. Output (I'm assuming from stderr) is a long series of errors like this: (totem:1488): GStreamer-CRITICAL **: gst_segment_do_seek: assertion `segment->format == format' failed The reason I'm reporting this as a movie player bug instead of a GStreamer bug, is because VLC's progress bar actually works as expected with the same file. The file may have format errors, as identified by the GStreamer-CRITICAL errors in the output, but somehow VLC is able to cope with them and keep its progress reporting consistent during the movie. Thank you for your time and attention to this bug.
This would be a GStreamer bug. Can you please test with a more recent version of GStreamer and plugins, and state which versions of GStreamer and plugins you tested with if you can reproduce the problem? A test file would also be very helpful.
Thank you for your response and for recategorizing this bug appropriately, Bastion. I discovered that I'm using the package totem-gstreamer in Ubuntu 13.04 64bit: $ totem --gst-version GStreamer Core Library version 1.0.6 So, I'm using version 1.0.6 of gstreamer. I'll try to download, compile, & install v1.0.10 and see if I can reproduce the error. I'll provide an update.
I just confirmed that this was fixed in some version at or before v1.0.10. Thanks to TFKyle and __tim on IRC for helping me setup a quick test to confirm this. Now if only Ubuntu/Debian would update the gstreamer libs to 1.0.10! :-)
> Now if only Ubuntu/Debian would update the gstreamer libs to 1.0.10! :-) Debian sid has 1.0.10. You can probably use those. Alternatively, you can do: $ mkdir ~/.local/share/gstreamer-1.0/plugins and then copy libgstmpegtsdemux.so from the gst-plugins-bad build directory into ~/.local/share/gstreamer-1.0/plugins/ . Then just don't forget about it when you upgrade to something newer :) (maybe set a cronjob to remove it in october or so).
(In reply to comment #4) > Alternatively, you can do: > > $ mkdir ~/.local/share/gstreamer-1.0/plugins > > and then copy libgstmpegtsdemux.so from the gst-plugins-bad build directory > into ~/.local/share/gstreamer-1.0/plugins/ . When I copy just the 1.0.10 libgstmpegtsdemux.so that I built into that directory, I get an error opening my ts file: "Videos requires to install plugins to support the following multimedia feature: RV1226 protocol source." When I don't copy that 1.0.10 libgstmpegtsdemux.so file over, the ts file opens, but experiences the same 1.0.6 gstreamer seek assertion error as before. Can you please explain what's happening and why?
I checked the output of totem to find the error: " ** Message: Missing plugin: gstreamer|1.0|totem|... protocol source|urisource-... (... protocol source) CRITICAL:Could not find any packages to operate on ** Message: No installation candidate for missing plugins found. " Is it expecting to find other .so library files in that ~/.local/share/gstreamer-1.0/plugins/ directory besides just libgstmpegtsdemux.so? Thanks for your time and reply.
Sorry, I have no idea why that would happen, or where the RV1226 protocol source thing comes from. Does not make sense.
Tim, do you think that gstreamer would expect to find other plugins or .so library files in ~/.local/share/gstreamer-1.0/ just because I put that one in there for some reason? It sounds like it's looking for something else there, but I'm not familiar with exactly how gstreamer-1.0 uses that directory.