Created attachment 125121 [details]
sample subtitles file

Do you have the preference to make it load the subtitle automatically? Otherwise, have you tried right-clicking on the file to make it load the text subtitle?

Most likely not a bug...

Yes. It sometimes load the subtitles, sometimes not (and I only have .srt subtitles, nothing fancy). 

What's even more scary is that there was another movie for which I had a srt file (which displayed fine), but the timing was wrong, so I corrected it. I checked the file in gedit too, and there's nothing wrong. However, after making the changes in the srt file, no subtitles display at all in totem anymore (while it does show in mplayer/vlc/whatever). Basically: totem loads the subtitles only when it feels like it!

Try loading the sample subtitles that I attached in some video. You won't see any subtitles appearing.

Totem does not output anything regarding this in the terminal, even with debug on.

Created attachment 125694 [details]
another sample - before and after

In this sample, the file
"tonari no totoro (copie).srt" (if renamed to the proper name) will display subtitles with the movie (tonari no totoro.mkv). 

The other file
"tonari no totoro.srt" will not display.

I looked at both files in gedit, and they are exactly the same, except the timings. The timings are within the duration boundaries of the movie anyway (1 hour 24 minutes 53 seconds).

Which backend are you using?

Totem GStreamer 0.10.21

0:00:01.853282157 11389      0x21ac640 WARN             decodebin gstdecodebin.c:1716:type_found:<subtitle-decoder> error: This appears to be a text file
0:00:01.853465316 11389      0x21ac640 WARN             decodebin gstdecodebin.c:1716:type_found:<subtitle-decoder> error: decodebin cannot decode plain text files
0:00:01.853567686 11389      0x21ac640 WARN           playbasebin gstplaybasebin.c:2042:subbin_startup_sync_msg:<play> error starting up subtitle bin: error message from element 'subtitle-decoder': GstMessageError, gerror=(GstGError)(NULL), debug=(string)"gstdecodebin.c\(1716\):
\ type_found\ \(\):\ /GstBin:subtitle-bin/GstDecodeBin:subtitle-decoder:\012decodebin\ cannot\ decode\ plain\ text\ files";

# For that non-working subtitle file:
$ gst-typefind-0.10 sample.srt 
sample.srt - text/plain
# For a known working subtitle file:
$ gst-typefind-0.10 working.srt 
working.srt - application/x-subtitle

This is fixed in CVS and should be in the upcoming 0.10.22 release, see bug #555607

*** This bug has been marked as a duplicate of 555607 ***

Are you sure this is the same bug? #555607 talks about individually malformed subtitle lines (timecodes starting with spaces), while my problem seems to be due (according to Bastien's investigation) to mimetype detection.

Viewing the file properties for those files, in nautilus, tells me application/x-subrip.

I looked at the two files in the archive in comment #4. One (the non-copie one) has an initial space at the very beginning before the '1', which made non-CVS versions of GStreamer not detect it properly. However, both files were detected correctly with gst-typefind from CVS (but not with an older gst-typefind), so I'm guessing that this is the same bug.

This is about media format detection in GStreamer, not mime type detection in nautilus (both are not related).

Please re-open if this still fails with core/base from CVS.

*** This bug has been marked as a duplicate of 555607 ***

Well, I tried my sample file in an ubuntu jaunty virtualmachine which has gstreamer 0.10.22 (or so it seems), and it still doesn't work?

Not sure what the problem is but with latest GIT all files attached to this bug are correctly identified as subtitles.

Oh indeed, works in ubuntu 9.04; I just forgot that totem is not set to autoload subtitles by default. Flipped the switch and it worked. Thanks for all the fish!