GNOME Bugzilla – Bug 339623
Show current track playing in Internet Radio entry view
Last modified: 2018-05-24 11:32:26 UTC
I would love to see this in Rb, Amarok does this and I don't know how it works.
I realized after hitting submit that the desc was a little vauge. What I am asking for is that when a new song starts streaming, libnotify would pop up with the new song name. So if I am listening to sky.fm classical, and the song changes from Tocatta and Fuge in D Minor, to Fur Elise, it should show up as a pop up, same as when a song changes in the music library. Amarok I know does this.
After playing the stream in mplayer I found a line that may help: MyUser@MyMachine ~ $ mplayer http://64.236.34.67:80/stream/1006 MPlayer dev-CVS-060414-17:32-4.0.3 (C) 2000-2006 MPlayer Team CPU: Advanced Micro Devices Sempron/Athlon MP/XP/XP-M Barton,Thorton (Family: 6, Stepping: 0) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Compiled with runtime CPU detection. 91 audio & 208 video codecs Failed to open /dev/rtc: Device or resource busy (it should be readable by the user.) Playing http://64.236.34.67:80/stream/1006. STREAM_HTTP(1), URL: http://64.236.34.67:80/stream/1006 Resolving 10.10.0.2 for AF_INET6... Couldn't resolve name for AF_INET6: 10.10.0.2 Connecting to server 10.10.0.2[10.10.0.2]: 8080... Name : S K Y . F M - Mostly Classical - Listen and Relax, it's good for you! www.sky.fm Genre : classical easy symphonic Website: http://www.sky.fm Public : yes Bitrate: 96kbit/s Cache size set to 320 KBytes Cache fill: 0.00% (0 bytes) Audio file file format detected. ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 mpg123: Can't rewind stream by 1085 bits! AUDIO: 44100 Hz, 2 ch, s16le, 96.0 kbit/6.80% (ratio: 12000->176400) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== alsa-init: using device default alsa: 48000 Hz/2 channels/4 bpf/65536 bytes buffer/Signed 16 bit Little Endian AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... mpg123: Can't rewind stream by 602 bits! A: 0.5 (00.4) of -0.0 (unknown) 1.9% 16% ICY Info: StreamTitle='Ensemble Fete Rustique - A Vivaldi';StreamUrl=''; # THIS LINE HERE+++++++++++++++++++++++++++++++ alsa-uninit: pcm closed (unknown) 1.6% 35% Exiting... (Quit) Another feature that would be helpful would be to change the current Title column to a Stream column and use the title column for the current playing song in the stream.
Rhythmbox already does this if you're using gstreamer 0.8, or gstreamer 0.10 cvs + patch from bug 333657. I think there's another patch required on top of that, but I'm not sure. (In reply to comment #2) > Another feature that would be helpful would be to change the current Title > column to a Stream column and use the title column for the current playing song > in the stream. Maybe I'm misunderstanding you, but that doesn't sound like a good idea. It sounds like you want the radio source entry view to look like this: [icon] [stream] [genre] [current song] [rating] [last played] but we can only have useful data for the 'current song' column for one stream.
OK, Then this enhancement request should be closed, because it is a gstreamer waitforme. The second suggestion is very minor, but I think that, as there is no buffering required, the current playing song could be very easily downloaded. The difficulty, as I see it, comes when the song changes. How do you find out when to update the data. If that could be figured out then it would be sweet, because I could look at the list and decide if I want to listen to any of the songs. If the second request is worth looking into then change the bug name and mark it as new or whatever it is supposed to be maked as. If the second request is somewhat silly and is not worth the trouble then just mark the bug closed. Thanks.
(In reply to comment #4) > OK, Then this enhancement request should be closed, because it is a gstreamer > waitforme. The first request is a duplicate. > The second suggestion is very minor, but I think that, as there is no buffering > required, the current playing song could be very easily downloaded. The > difficulty, as I see it, comes when the song changes. How do you find out when > to update the data. If that could be figured out then it would be sweet, > because I could look at the list and decide if I want to listen to any of the > songs. > If the second request is worth looking into then change the bug name and mark > it as new or whatever it is supposed to be maked as. If the second request is > somewhat silly and is not worth the trouble then just mark the bug closed. I have changed the summary description to reflect the second request as an enhancement. Not sure if it makes sense either, but perhaps it could always show the current track playing for the active stream (or the last track played in the case of streams that were inactive).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/179.