GNOME Bugzilla – Bug 320233
Allow saving of iradio streams
Last modified: 2018-05-24 10:51:03 UTC
it would be nice if there was a "save stream" option in the context menu, if streamripper is detected, which ask for a folder and the automatize the following steps: 1. call "streamripper <url> -r -d <location> 2. connect to "http://localhost:8000"
We don't need streamripper for this. All we would need to do is insert a tee element into the pipeline and connect a file sink to it. We should be ble to do this at runtime, without disruption (yay for gstreamer!). Retitling bug to reflect that we don't need streamripper.
*** Bug 370543 has been marked as a duplicate of this bug. ***
Created attachment 100657 [details] A very quick implemention of a python based recorder plugin A simple and ugly plugin which uses the tee functionality to save anything rhythmbox plays back and thus the iradio stream to a mp3 on the user's desktop. It can be extracted in ~/.gnome2/rhythmbox/plugins/ for testing. Some notes: - It uses lame, id3v2mux and gnomevfssink here (make sure they are installed) but preferably it should use the currently selected encoding profile preference - Splitting the continuous recording to individual tracks would be nice but not sure how to do it properly upon a "entry-extra-metadata-notify::rb:stream-song-title" since setting properties (such as location) on the filesinks requires less than PAUSED pipeline state; perhaps this requires writing a custom sink... - add_tee/remove_tee causes a short "zap" (it skips) due to pipeline state change and general async issues during playback "Failed to pause pipeline before eee insertion". I guess it should use the tee signals to fix this? - The "id3v2mux" element should preferably pick up tags and magically copy them to the output file, however this fails right now with "(rhythmbox:14181): GStreamer-CRITICAL **: gst_tag_list_foreach: assertion `GST_IS_TAG_LIST (list)' failed"; setting tags manually from the rhythmdb entry seems a bit wrong here (?) - currently allows to save anything RB plays back, should we limit it to the streaming sources (it can record stuff from MagnaTune...)? - it might be interesting to grab the data directly before decoding it in order to save processing, but that requires some kind of data tee API in RB Perhaps using the RB encoder code could be of use here, too. Help and comments appreciated.
(In reply to comment #3) > - Splitting the continuous recording to individual tracks would be nice but not > sure how to do it properly upon a > "entry-extra-metadata-notify::rb:stream-song-title" since setting properties > (such as location) on the filesinks requires less than PAUSED pipeline state; > perhaps this requires writing a custom sink... I haven't looked at the code at all, but assuming you have a pipeline something like this: tee ! queue ! audioconvert ! audioresample ! lame ! id3v2mux ! sink if you place the lame ! id3v2mux ! sink bits in a bin, you should be able to block the audioresample src pad, unlink the bin, send an EOS event into it, set it to NULL state, change the location on the sink, set it to READY, send the new tag information into it, set it to PLAYING state, relink it to the audioresample, then unblock the audioresample src pad. Or something like that, anyway. > - add_tee/remove_tee causes a short "zap" (it skips) due to pipeline state > change and general async issues during playback "Failed to pause pipeline > before eee insertion". I guess it should use the tee signals to fix this? No, rb-player-gst should use pad blocking to insert tees, rather than changing the pipeline state. > - The "id3v2mux" element should preferably pick up tags and magically copy them > to the output file, however this fails right now with "(rhythmbox:14181): > GStreamer-CRITICAL **: gst_tag_list_foreach: assertion `GST_IS_TAG_LIST (list)' > failed"; setting tags manually from the rhythmdb entry seems a bit wrong here > (?) I'm not exactly sure about this, but I think it needs to receive the tag information before it pushes its first buffer (as id3v2 tags are placed at the start of the file). You'll probably need to set at least some tag information yourself (album = stream name, perhaps).
(In reply to comment #4) > (In reply to comment #3) > > - Splitting the continuous recording to individual tracks would be nice but not > > sure how to do it properly upon a > > "entry-extra-metadata-notify::rb:stream-song-title" since setting properties > > (such as location) on the filesinks requires less than PAUSED pipeline state; > > perhaps this requires writing a custom sink... > > I haven't looked at the code at all, but assuming you have a pipeline something > like this: > > tee ! queue ! audioconvert ! audioresample ! lame ! id3v2mux ! sink > > if you place the lame ! id3v2mux ! sink bits in a bin, you should be able to > block the audioresample src pad, unlink the bin, send an EOS event into it, set > it to NULL state, change the location on the sink, set it to READY, send the > new tag information into it, set it to PLAYING state, relink it to the > audioresample, then unblock the audioresample src pad. Or something like that, > anyway. > Thanks, doing that blocking and state change on the encoding bin worked even without unlinking. Now new tracks for streaming sources (iradio) are correctly written into a new files. > > - The "id3v2mux" element should preferably pick up tags and magically copy them > > to the output file, however this fails right now with "(rhythmbox:14181): > > GStreamer-CRITICAL **: gst_tag_list_foreach: assertion `GST_IS_TAG_LIST (list)' > > failed"; setting tags manually from the rhythmdb entry seems a bit wrong here > > (?) > > I'm not exactly sure about this, but I think it needs to receive the tag > information before it pushes its first buffer (as id3v2 tags are placed at the > start of the file). You'll probably need to set at least some tag information > yourself (album = stream name, perhaps). > If I debug the id3v2mux element using "GST_DEBUG=taglibmux:5" I can see that only the following tags are "received" from Rhythmbox: 0:01:15.454808000 11088 0xaffd20d0 LOG taglibmux gsttaglibmux.c:156:gst_tag_lib_mux_render_tag:<tagger> final tags: taglist, audio-codec=(string)"MPEG\ 1\ Audio\,\ Layer\ 3\ \(MP3\)", bitrate=(guint)128000; What I did next was to manually set the tags on the "id3v2mux" element and everything started to work. Tags are set correctly even with the "split iradio track" feature. So that kind of tells me this information is not send from rhythmbox in the first place (?). I can cleanup the code and pack the whole stuff into a patch against rhythmbox svn if maintainers would agree to include it.
Created attachment 100723 [details] A very quick implemention of a python based recorder plugin - Automatic track splitting for streaming sources (iradio) on new tracks - Use preferred gnome audio profile for recording - Merge tags of source into encoded file
*** Bug 505212 has been marked as a duplicate of this bug. ***
*** Bug 439940 has been marked as a duplicate of this bug. ***
*** Bug 565461 has been marked as a duplicate of this bug. ***
Martin Szulecki, the author of the plugin above seems to have moved to a different audio player (Banshee?), so isn't maintaining this plug-in any longer. However, there is another rhythmbox recording plugin available here: http://www.programmierecke.net/programmed/rhythmbox-radio-browser.html#Downloads Looks like it's fairly well developed and actively maintained by its author.
Adding bug dependency. Maybe we want to leave this but open until the plugin supports recording via GStreamer.
-- 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/80.