The error messages are unrelated to the actual problem, and I've just fixed them.

I can't play that particular station usefully, but that appears to be a network problem.  It connects and buffers and occasionally emits a bit of sound.

Hi 
i am using version 12.2 on ubuntu
and i get the same error message as pedro's
i can add that the mms links i have work normally in other players as mplayer and totem
the link is 
mmsh://shared.streamwebtown.com/TwestoDOTcomANDNogoomFMblog7692?MSWMExt=.asf

Any news for this issue? There's still quite a lot of mms radios out there.

Status UNCONFIRMED?!

UNCONFIRMED bug status doesn't mean anything. We don't pay any attention to whether a bug is confirmed or not.

Some problems with mms streams with crossfading enabled were probably caused by a bug in gst-ffmpeg that I fixed a few months ago. If you're using the latest versions of rhythmbox, GStreamer, gst-plugins-bad, gst-plugins-ugly and gst-ffmpeg, and mms playback doesn't work for you, please provide rhythmbox and GStreamer debug output ('GST_DEBUG=*:4 rhythmbox -D player 2>debugoutput.log').

Created attachment 149137 [details]
debug rhythmbox level 3

A couple of problems here:

gstasfdemux.c:1907:gst_asf_demux_activate_stream:<asfdemux0> Activating stream  1, pad audio_00, caps audio/x-wma, wmaversion=(int)4, bitrate=(int)1152000, depth=(int)16, rate=(int)44100, channels=(int)2, block_align=(int)13375, codec_data=(buffer)1000030000000000000000000000a10100

There is no decoder for this format.

gstasfdemux.c:1370:gst_asf_demux_loop:<asfdemux0> Sending EOS, at end of stream

and the demuxer acts like the stream ends immediately. We're probably not handling this condition very well, but fixing that isn't going to make it work.

I've found out something interesting. In fact mms streams are all fine except the ones from Yacast. And actually, even http type streams from Yacast give the same error message. And Yacast is like the biggest stream provider in Europe, unfortunately for us..

Here's a few Yacast streams:

mms://vipnrj.yacast.net/encodernrj
http://viphttp.yacast.net/nrj/PUBWEBRADIOS/NOSTALGIE/encodernostalgie.asx
mms://vipnrj.yacast.net/nrj_webradio14

I don't know what to do about the decoder pb. I got all latest gst installed..

"and the demuxer acts like the stream ends immediately. We're probably not
handling this condition very well, but fixing that isn't going to make it work."

Sorry but I have no idea what this means. I'm just an end-user :)

Could you give us (end-users you know?) some help to solve this problem? I'm pretty sure we can solve this problem easily and soon. 
Not being able to play mms from one of the biggest provider out there is quite embarrassing...
Again, I don't think I've understood a word of your last comment.

No, I can't help you solve this problem.

Fine. Don't help. But you could at least tell what this means:

gstasfdemux.c:1370:gst_asf_demux_loop:<asfdemux0> Sending EOS, at end of stream

Who else is supposed to explain what this means? I just need to know what the problem is... Seriously, if you don't care just ignore the bug, and past it to someone else who cares.

I'm only trying to solve a problem I don't even understand. I'm afraid I'm stubborn enough to try again and again until I bloody solve it for good. Isn't the basics in the Open source community?

It doesn't mean anything to end users.  You can't solve this problem as an end user, though.

'EOS' means 'end of stream'.  You can read more about this (and demuxers, and anything else I mentioned above) in the GStreamer documentation: http://gstreamer.freedesktop.org/documentation/

It's not that I don't care about this issue, it's more that it's not a priority for me.  If you're willing to investigate it further, I'll help where I can, but I'm not going to solve it myself.

I just had a "wow" effect seeing the amount of documentation there...

I'll try anyway. Maybe the hidden developer in me (that I haven't quite met for the moment) will suddenly wake up.

Thanks.

ps: I do find surprising that nobody would take care of that problem for such a big app (and great let's say it) as Rhythmbox though.

(In reply to comment #7)
> mms://vipnrj.yacast.net/encodernrj
> http://viphttp.yacast.net/nrj/PUBWEBRADIOS/NOSTALGIE/encodernostalgie.asx
> mms://vipnrj.yacast.net/nrj_webradio14

These are actually RTSP streams.  I think the main thing we'd need to do to get these working would be to handle the mms->rtsp redirect that we get from mmssrc.

(In reply to comment #15)
> (In reply to comment #7)
> > mms://vipnrj.yacast.net/encodernrj
> > http://viphttp.yacast.net/nrj/PUBWEBRADIOS/NOSTALGIE/encodernostalgie.asx
> > mms://vipnrj.yacast.net/nrj_webradio14
> 
> These are actually RTSP streams.  I think the main thing we'd need to do to get
> these working would be to handle the mms->rtsp redirect that we get from
> mmssrc.

Indeed. Those work fine in Totem.

See bvw_handle_element_message() in totem/src/backend/bacon-video-widget-gst-0.10.c

We'd also need to fix bug 530775 for it to work with crossfading enabled.

Works fine for me in rhythmbox with latest gstreamer modules.

Created attachment 164267 [details] [review]
Handles GStreamer redirects

Handles the redirect event from gstreamer, updates the database entry and restarts the stream.

The example stream I used was:
mms://wms-trn-all.streaming.net.nz/trn-newstalk-zb-akl
which redirects to:
rtsp://wms-trn-all.streaming.net.nz/trn-newstalk-zb-akl

I initially tried to just get it to change the playing URI but couldn't get it to work.  I'm not sure if updating the database is the correct behaviour (i.e. are there streams with dynamic redirects?).

Review of attachment 164267 [details] [review]:

When I was testing an earlier version of this, I found that I needed to set the pipeline state to NULL rather than READY in backends/gstreamer/rb-player-gst.c:impl_close() so that the pipeline bus was flushed.  Otherwise, after handling the redirect, we'd get the error message that mmssrc posts immediately afterwards and stop playback.  It's possible that changing to rb_shell_player_play_entry adds enough delay (attempting to parse as a playlist, etc.) that this doesn't cause a problem.

::: backends/gstreamer/rb-player-gst.c
@@ +617,3 @@
+		else if (gst_structure_has_name (structure, "redirect")) {
+			_rb_player_emit_redirect (RB_PLAYER (mp), mp->priv->stream_data, gst_structure_get_string (message->structure, "new-location"));
+		}

we'll need an equivalent change to rb-player-gst-xfade.c too, of course

::: backends/rb-player.c
@@ +294,3 @@
+			      G_TYPE_NONE,
+			      2,
+			      G_TYPE_POINTER, G_TYPE_POINTER);

any reason the uri isn't G_TYPE_STRING here?

::: backends/rb-player.h
@@ +133,3 @@
+	void		(*redirect)		(RBPlayer *player,
+						 gpointer stream_data,
+						 gpointer data);

'data' should probably be 'const char *uri' instead

::: shell/rb-shell-player.c
@@ +780,2 @@
 	rb_debug ("playing stream url %s", location);
+	printf ("playing stream url %s\n", location);

debug leftover?

@@ +979,3 @@
+
+	/* Play new URI */
+	rb_shell_player_play_entry (shell_player, entry, NULL);

I think rb_shell_player_open_location (shell_player, entry, RB_PLAYER_PLAY_REPLACE, NULL) would work better here.  We don't want to change the active source or jump to the playing entry here, we just want to start playing again.

Created attachment 164272 [details] [review]
Handles GStreamer redirects

Updated with the feedback, thanks!

I don't really *get* the playback methods - this patch works but still might not be running the pipelines the correct way.

Looks good now, but the crossfading backend crashes when it gets a redirect.  I guess I'm going to have to look into that..

Pushed as commit 4ae9112 (crossfading changes in 5dadebf).  Thanks for working on this.