GNOME Bugzilla – Bug 771546
Rhythmbox says radio playing when no actual playback happens
Last modified: 2016-09-22 09:19:58 UTC
This is a typical scenario on most new linux installations. gstreamer plugins are not properly set / installed. The user clicks on the internet radio stream to check if audio works fine. Rhythmbox should complain saying that playback is not possible without plugins. But, currently it buffers first few seconds and displays "playing" ( in playing column ), with time at 0:00. There is no time progress ( always at 246712018 ) in tick_cb as shown below: (22:26:37) [0x1107000] [tick_cb] rb-shell-player.c:2580: tick: [http://stream-dc1.radioparadise.com/rp_192m.ogg, 246712018:0(0)] + 5s (22:26:42) [0x1107000] [tick_cb] rb-shell-player.c:2580: tick: [http://stream-dc1.radioparadise.com/rp_192m.ogg, 246712018:0(0)] It would be better to display an error message in this case. I've encountered this issue in new installation of FC24 and Arch Linux.
Created attachment 335723 [details] Log file when radio link is clicked.
Just tried a radio station with sound output pointing to a remote pulseaudio ( PA ) server. Audio streams and plays perfectly fine. But, the time in slider is always 0:00, and the tick never moves. (18:13:13) [0x92bc2c0] [tick_cb] rb-shell-player.c:2580: tick: [http://stream-dc1.radioparadise.com/rp_192m.ogg, 183412000:0(0)] ... (18:13:24) [0x92bc2c0] [tick_cb] rb-shell-player.c:2580: tick: [http://stream-dc1.radioparadise.com/rp_192m.ogg, 183412000:0(0)]
Seeing this issue only on x86. Linux sid 4.7.0-1-686-pae #1 SMP Debian 4.7.2-1 (2016-08-28) i686 GNU/Linux Not on x64. Linux unstable 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) x86_64 GNU/Linux
(In reply to vrishab from comment #3) > Seeing this issue only on x86. > > Linux sid 4.7.0-1-686-pae #1 SMP Debian 4.7.2-1 (2016-08-28) i686 GNU/Linux > > Not on x64. > > Linux unstable 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) x86_64 > GNU/Linux This is not true. Issue happens in both x86 and x64. Actual problem: The actual problem is with the audio sink. If an audio sink has issues, gstreamer detect it and possibly stops the proceeds. This is reflected in Rhythmbox's time slider. I've not seen this behavior before ( in any player / system ), and hence appears strange to me. Normally a player would keep playing and updating the time slider independent of whether the audio sink has issues. When the time slider never updates, it appears to the user as if Rhythmbox has issues. I am not sure if Rhythmbox wants it this way. A better way would be to update the user about 'audio sink issues', rather than the current scenario, as the user would left confused as to what is the real issue ( plugin issue / audio output issue ) etc. For quite sometime, I thought this was a missing gst plugin issue, as the symptoms are close to a missing plugin.
If gstreamer isn't reporting an error when it's not able to play anything, that's a bug in the gstreamer sink element. If gstreamer isn't reporting the playback position when it is able to play, that's also a bug in the gstreamer sink element. I'm not sure which of those you're trying to describe here. It's not the application's responsibility to guess what the playback position is (is that what you're suggesting? I'm not sure), or to guess whether there's some other problem based on how the playback position is changing.
(In reply to Jonathan Matthew from comment #5) > If gstreamer isn't reporting an error when it's not able to play anything, > that's a bug in the gstreamer sink element. If gstreamer isn't reporting > the playback position when it is able to play, that's also a bug in the > gstreamer sink element. I'm not sure which of those you're trying to > describe here. Both issues are seen here. But, I am referring to the former one, as it creates more confusion. When audio works fine ( later case ), at least the user is sure, he has installed his plugins right. > It's not the application's responsibility to guess what the playback > position is (is that what you're suggesting? I'm not sure), or to guess > whether there's some other problem based on how the playback position is > changing. Something like that. If the tick is not moving for a long time ( say ~15 seconds ), application could issue a warning saying there is backend gstreamer issue. We could have a software watchdog to see if the timer has updated, if the track / stream is in playing state.
(In reply to vrishab from comment #6) > > > It's not the application's responsibility to guess what the playback > > position is (is that what you're suggesting? I'm not sure), or to guess > > whether there's some other problem based on how the playback position is > > changing. > > Something like that. If the tick is not moving for a long time ( say ~15 > seconds ), application could issue a warning saying there is backend > gstreamer issue. We could have a software watchdog to see if the timer has > updated, if the track / stream is in playing state. I really don't see the point. It's pretty obvious that playback isn't working in that situation. How about you fix the bugs that are causing the problem?
(In reply to Jonathan Matthew from comment #7) > > Something like that. If the tick is not moving for a long time ( say ~15 > > seconds ), application could issue a warning saying there is backend > > gstreamer issue. We could have a software watchdog to see if the timer has > > updated, if the track / stream is in playing state. > > I really don't see the point. It's pretty obvious that playback isn't > working in that situation. How about you fix the bugs that are causing the > problem? The idea is to remove the "Rhythmbox is not playing the track because I probably did not install all the required plugins" notion from the user, when a failure of this sort happens. Rhythmbox knows its not a plugin issue ( since it did not receive GST_MESSAGE_ELEMENT on the bus ). So, if rhythmbox can convey that it is not a plugin issue, it will be a big relief to the user. For now, I've filed https://bugzilla.gnome.org/show_bug.cgi?id=771772 to address the gstreamer part of the issue.
(In reply to vrishab from comment #8) > (In reply to Jonathan Matthew from comment #7) > > > Something like that. If the tick is not moving for a long time ( say ~15 > > > seconds ), application could issue a warning saying there is backend > > > gstreamer issue. We could have a software watchdog to see if the timer has > > > updated, if the track / stream is in playing state. > > > > I really don't see the point. It's pretty obvious that playback isn't > > working in that situation. How about you fix the bugs that are causing the > > problem? > > The idea is to remove the "Rhythmbox is not playing the track because I > probably did not install all the required plugins" notion from the user, I don't believe users generally have this notion, and even if they did I don't think this is a useful way to address it. Ensuring that the plugin install code works properly, ensuring that appropriate error messages are displayed when other errors occur (and when plugin install isn't available), and fixing bugs that result in playback not working for other reasons are more useful things to do. What you're proposing makes it harder to do the last of those in that it adds complexity to code that's already overcomplicated, which is why I'm opposed to it.