[feature] Include current scan frequency in icecast stream

[bovine]

When in "scan" mode between multiple frequencies, it would be nice if the icecast stream were able to indicate the current frequency in the stream metadata. Ideally, you would also be able to specify a name for each of frequencies so that could be shown rather than just the numerical frequency.

[bovine]

As I mentioned in the comment in my above code branch, it probably doesn't need to send that metadata with every packet. Only when the frequency changes, or a few seconds have elapsed probably.

Although my branch seems to get the frequency to be displayed onto the Icecast status webpage, I don't see the updated song title displayed in my iTunes. Perhaps it is also necessary to actually emit the metadata into the MP3 stream made by LAME?

[szpajder]

I'm afraid it's not really possible to make the player display the metadata in sync with the actual audio. Players usually emit metadata synchronously, but the audio stream gets buffered. The buffer introduces delay, which amount is unknown to rtl_airband, because it depends on the player configuration. So the metadata will not correspond to what the listener is hearing at that moment.

[rec9140]

I definitely I am interested in this feature... so I will offer some input... I do metatags for my feed via a P25 Control Channel dump feature... I use a BASH shell script to do this.. as I feed using DarkIce which has no native way to update the data either.

I use the http interface of IceCast to do updates to the metatag data...like...

wget -q --delete-after --http-user=admin --http-password=passp http://audio.domain.net:8000/admin/metadata?mount=/Feed\&mode=updinfo\&song=[tag+data+]+$RANDOM >/dev/null

I am aware of the delay between IceCast and the clients and this actually works for me.. I might be 1-2 seconds off.. I started off using a sleep 4s command in the loops that decode the data and send the updates but found I didn't need them as the delay between all the Icecast updating the tag, and propigating to the client and the audio buffer, it all caught up to itself that using a sleep xs was making it totally out of sync.

Maybe there could be a config option that sets what the delay is so that RTLSDR-Airband can wait that time and then send the tag data... I am sure this complicates things as the program sends out the audio, it drops out, scans to the next frequency and new audio starts...

Count me in as VERY INTERESTED and I know it can be done, as I use two programs DarkIce, and my shell script to update tags and there are maybe at best 1-2 seconds off from the audio ie: the audio might start and the tag updates 1-2 seconds later. I have Darkice set to bufferSecs = 10

I've played the stream via VLC, and a dedicated application on Droid devices, and it works great, the tags come through like clock work..

If I can offer more input I will.

[rec9140]

A thought I had in regards to the delay, and scanning on to the next frequency... using threads to handle the update of the tag and the delay issue....between the audio and the tag update...thus the update of tags would spawn a thread to deal with that update, and then close out...I have a memory about when I was looking at changing this from BASH to something else and part of the solution was threads... I'll look to see if I have that code around... I decided not to go that route for some reason at the time....

[bovine]

@rec9140 you might want to try compiling the commit from my branch (mentioned above), just to see how well that performs relative to what you're expecting.

[szpajder]

See commit 86014fe9daa97444329ce4491015825e150462a4 in freq_metadata branch. This is my first attempt to do this properly (ie. send metadata update only when the scanner stops on a new freq). Otherwise we would fill up the log files on the Icecast server pretty quickly.

It works, however I'm not too impressed. rtl_airband emits the update instantly after the scanner stops, but VLC with default buffering config shows the update after 5-8 seconds. Then comes the audio - after next 5 or so, seconds. So when I have the player opened in the background and hear something interesting, I switch to the player window to check which freq this was transmitted on and I'm pretty often given a totally wrong frequency, because the player already shows the freq from the next update, which came in the meantime. Of course the amount of introduced delay depends on the buffer size, so regarding rec9140's suggestion about sleeping for some fixed period - no, we won't be doing this, because there is no one-size-fits-all delay value. This is fully client-dependent.

[bovine]

That's unfortunate about the delay. I'm not sure if any other options exist that would provide a better experience.

[rec9140]

I am afraid that I disagree, that a delay, is pretty consistent... VLC or scanner radio... all show the updates within 1-2 seconds of the audio appearing with my setup of DarkIce and my BASH script.

And simply offering a configurable option to the config will let the USER set the delay that works for them the best.

[rec9140]

At this time I can not test SDR setups due to technical issues on my end...as all my devices are being used in production for live streams which are not using SDR.

[rec9140]

I am still interested in this option, and looking to make this easy for all.. can we look at offering a config option like for #23 with the squelch tag, where the USER specifies the delay needed for them... I've tried this with my setup using darkice and my BASH setup, and the delay is pretty consistent from device to device player to player be it VLC on what ever or via dedicated applications like scanner_radio ... Thus the USER determines the delayed needed, and puts it in the config like tagDelay = 10 where the value is seconds. The only complication I see is that as rtlsdr scans on to the next active frequency, there is a backlog of tags to update in the stream of audio. Thus the code pushes the tags on to a stack and a thread handles that stack of updates till its caught up, ends, rinse, repeat... With free resources becoming available I will be using rtlsdr and PI's to feed various things be it AM aircraft for local stuff, to some NFM stuff, and tags are a must. One feed per frequency is really not the preferred choice in my realm, wider audience than say ATC users.

[szpajder]

I'll see what can be done about this.

[szpajder]

Please clone the latest unstable tree (https://github.com/szpajder/RTLSDR-Airband/tree/unstable).

There are two new knobs:

• shout_metadata_delay - integer, default value is 3 seconds. This shall be put in the global section.
• send_shout_freq_tags - boolean (true|false). This is a per-output option, it enables tag updates for the given Icecast output. Default is false.

Refer to rtl_airband.conf.example file for examples.

Please test and share your feedback. Thanks.

[rec9140]

What formatting or format is the tag data in? I am waiting on Pi's and SDR's to arrive. THANKS!

[szpajder]

Currently it's hardcoded as "freq: xxx.yyy MHz", but I'll probably add support for configurable descriptions of some sort.

[szpajder]

Commit https://github.com/szpajder/RTLSDR-Airband/commit/65d347258ffcb0bfa8409e686c20e9a0152c7a78 adds support for optional textual labels.

channels: (
    {
        freqs = ( 126300000, 121500000, 128225000, 131375000 );
        labels = ( "Radar", "Emergency", "Tower", "Ground" );
        (...)
    };
);

[spotter-ssol]

I'm testing this feature and here is my feedback. I've enabled tags and turned on the send_scan_freq_tags. Curiously, metadata is updated on player (Winamp, buffer 64k) ~3s AFTER audio is played (shout_metadata_delay = 0;). Reducing player buffer size to 16k gave me ~1s delay.

[szpajder]

Released in version 2.2.0.

Closing.