After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 380342 - Totem does not play mp3 files when lyrics are present
Totem does not play mp3 files when lyrics are present
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 386504
 
 
Reported: 2006-11-29 00:37 UTC by CedricMC
Modified: 2006-12-16 14:03 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description CedricMC 2006-11-29 00:37:45 UTC
Please describe the problem:
Totem does not play mp3 files (I've not tested with other, sorry) when a text file with the same base name as the audio one is present. Totem advices that a subtitle stream has been detected but there is no video.

Steps to reproduce:
1. Suppose that you have an mp3 file named "my.song.mp3"
2. Create a text file in the same directory with the name "my.song.txt"
3. Try to reproduce "my.song.mp3" with totem

Actual results:
An error window will appear advertising that a subtitle stream has been detected but there is no video to reproduce.

Expected results:
I expect totem to be able reproduce the audio file.

Does this happen every time?
Yes.

Other information:
No.
Comment 1 Bastien Nocera 2006-11-29 11:03:26 UTC
Is this with the GStreamer or xine-lib backend?
Comment 2 CedricMC 2006-11-29 11:49:54 UTC
GStreamer 0.10
Comment 3 Tim-Philipp Müller 2006-12-14 16:41:06 UTC
IMHO this is a totem bug. It shouldn't really pass any random text file as subtitle file to the backend, but only subtitle files.

Bastien, can totem detect the different subtitle types (for srt/ssa/sub etc.) per mime type or is it all going to come up as text/plain?
Comment 4 Bastien Nocera 2006-12-14 18:13:06 UTC
We don't have a single mime-type for those, and being "plain text" files, they wouldn't easily be detectable. Maybe we should just remove the ".txt" ones from the list...
Comment 5 Tim-Philipp Müller 2006-12-16 14:03:36 UTC
Okay, guess we need to make decodebin/playbin a bit smarter then:

Fixed for playbin+decodebin (default), still needs fixing for playbin+decodebin2 (future default):

 2006-12-16  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/playback/gstdecodebin.c: (type_found):
          Special-case the text/plain media type: we only want to recognise it
          as a 'raw' decoded media type if it comes from a demuxer or subtitle
          parser, but not if the entire stream is of text/plain type. If the
          entire stream is text/plain, we should just error out.

          This fixes playback of audio files with lyrics in totem. Totem can't
          distinguish between text files and subtitle files and passes any
          .txt file with the same basename as the main file to playbin as
          suburi, and playbin will then throw a 'subtitle found, but no video
          stream' error, which isn't entirely helpful. See #380342.

          Also, with this change we'll show a slightly more correct error
          message in case totem passes a playlist file to us (although a
          custom error message wording instead of the default text would
          probably not be a bad idea either).

          Same problem also needs to be fixed for playbin+decodebin2.

        * tests/check/Makefile.am:
        * tests/check/elements/decodebin.c: (src_handoff_cb),
        (decodebin_new_decoded_pad_cb), (GST_START_TEST),
        (decodebin_suite):
          Add simple unit test for decodebin for the above.