[IDEA] Update to radio streams

[marek.marakesh]

Hi,

I found plenty of higher quality streams for whole FluxFM radio streams: https://streams.fluxfm.de/

Can they be updated in new release to 320k mp3? Currently most of them is in 64k aac.

I will share my latest backup of Moode radios with updated streams and my custom Radio streams for HiRes, like:
https://www.frequence3.com/
https://superstereo24bit.com/
https://motherearthradio.de/
https://insanityradio.com/
https://www.pureclassix.com/
NAIM Radio FLAC streams
Paradise Radio FLAC streams
JB Radio FLAC streams

Would you be interested to use it to include as  update to next release?

Attached is backup of all streams from last release 8.3.6 with updated streams and thumbs to my custom streams only.
Could not upload full backup as logos are heavy making zip 37MiB big.

[Tim Curtis]

I'll check them out.

Are the Flux 320 streams reliable and do they transmit metadata?

[marek.marakesh]

I'll check them out.

Are the Flux 320 streams reliable and do they transmit metadata?

Yup, those updated in json file were checked and have metadata.

[Tim Curtis]

Cool. I looked at the backup zip and it does not contain the full sized radio logos, only the thumbs.

Can you check on your end?
Thx.

[marek.marakesh]

Cool. I looked at the backup zip and it does not contain the full sized radio logos, only the thumbs.

Can you check on your end?
Thx.

Here is one with only custom logos (only other stations). Full backup takes 37MiB and limit for upload is 2MiB.

[Tim Curtis]

Cool. I looked at the backup zip and it does not contain the full sized radio logos, only the thumbs.

Can you check on your end?
Thx.

Here is one with only custom logos (only other stations). Full backup takes 37MiB and limit for upload is 2MiB.

Ok, I should be able to work with that.

[marek.marakesh]

@Tim Curtis in the streams I uploaded there are 3 that I had problem with.
This is old issue with specific streams, that after song is changing in the stream, MPD stops playing and logging "Decoder is too slow; playing silence to avoid xrun".
Those streams are:
JB Radio2 (FLAC) with metadata https://maggie.torontocast.com:8076/flac
BDPST ROCK Radio (FLAC) https://s2.audiostream.hu/bdpstrock_FLAC
Radio Calico (FLAC) https://radio3.radio-calico.com:8443/calico

I overcome this issue deploying mpd-watchdog in the way described here by JackRichardson with slight modification for moode:
https://discourse.mopidy.com/t/radio-doe...hdog/424/6
If someone is interested I can share my config.

I modified original mpd-watchdog lines like that:
35c35
< INTERVAL=10
---
> INTERVAL=1
90c90,92
<     $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
---
> #    $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
>     tail -n 1 /var/log/mpd/log |grep -E "playing silence to avoid xrun"
>
136c138
<             log warning "restarting mpd"
---
>             log warning "xrun error - restarting mpd"

[Tim Curtis]

@Tim Curtis in the streams I uploaded there are 3 that I had problem with.
This is old issue with specific streams, that after song is changing in the stream, MPD stops playing and logging "Decoder is too slow; playing silence to avoid xrun".
Those streams are:
JB Radio2 (FLAC) with metadata https://maggie.torontocast.com:8076/flac
BDPST ROCK Radio (FLAC) https://s2.audiostream.hu/bdpstrock_FLAC
Radio Calico (FLAC) https://radio3.radio-calico.com:8443/calico

I overcome this issue deploying mpd-watchdog in the way described here by JackRichardson with slight modification for moode:
https://discourse.mopidy.com/t/radio-doe...hdog/424/6
If someone is interested I can share my config.

I modified original mpd-watchdog lines like that:
35c35
< INTERVAL=10
---
> INTERVAL=1
90c90,92
<     $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
---
> #    $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
>     tail -n 1 /var/log/mpd/log |grep -E "playing silence to avoid xrun"
>
136c138
<             log warning "restarting mpd"
---
>             log warning "xrun error - restarting mpd"

@the_bertrum mentioned something similar in another thread and IIRC he also implemented a watchdog type script that looked for a particular MPD log message and then performed a stop/play sequence to "restart" the stream and hopefully achieve smooth, uninterrupted playback.

The challenge with this type of approach is that it's not really a good, universal workaround since the underlying issue has to do with the continuity of the stream itself. Unstable streams are usually due to broadcaster bandwidth or streaming server issues but sometimes can be due to poor Internet connection at the receiving side i.e., residential Internet gateway/Router. Regardless of which side the player just sees interruptions in stream data that eventually reach unrecoverable levels.

For example on my end the station BDPST ROCK Radio (FLAC) quickly starts stuttering and never recovers from stream starvation. No amount of MPD stop/play sequences results in a smooth, uninterrupted stream. The log has tons of run messages.

[marek.marakesh]

@Tim Curtis in the streams I uploaded there are 3 that I had problem with.
This is old issue with specific streams, that after song is changing in the stream, MPD stops playing and logging "Decoder is too slow; playing silence to avoid xrun".
Those streams are:
JB Radio2 (FLAC) with metadata https://maggie.torontocast.com:8076/flac
BDPST ROCK Radio (FLAC) https://s2.audiostream.hu/bdpstrock_FLAC
Radio Calico (FLAC) https://radio3.radio-calico.com:8443/calico

I overcome this issue deploying mpd-watchdog in the way described here by JackRichardson with slight modification for moode:
https://discourse.mopidy.com/t/radio-doe...hdog/424/6
If someone is interested I can share my config.

I modified original mpd-watchdog lines like that:
35c35
< INTERVAL=10
---
> INTERVAL=1
90c90,92
<     $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
---
> #    $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
>     tail -n 1 /var/log/mpd/log |grep -E "playing silence to avoid xrun"
>
136c138
<             log warning "restarting mpd"
---
>             log warning "xrun error - restarting mpd"

@the_bertrum mentioned something similar in another thread and IIRC he also implemented a watchdog type script that looked for a particular MPD log message and then performed a stop/play sequence to "restart" the stream and hopefully achieve smooth, uninterrupted playback.

The challenge with this type of approach is that it's not really a good, universal workaround since the underlying issue has to do with the continuity of the stream itself. Unstable streams are usually due to broadcaster bandwidth or streaming server issues but sometimes can be due to poor Internet connection at the receiving side i.e., residential Internet gateway/Router. Regardless of which side the player just sees interruptions in stream data that eventually reach unrecoverable levels.

For example on my end the station BDPST ROCK Radio (FLAC) quickly starts stuttering and never recovers from stream starvation. No amount of MPD stop/play sequences results in a smooth, uninterrupted stream. The log has tons of run messages.

True, this kind of solution is "not really a good, universal workaround since the underlying issue has to do with the continuity of the stream itself".
That is why I just shared my solution, which may be applied by anyone interested, if needed. This is not a perfect solution to include in any stable release of course.

Mentioned solution with stop/start I was experimenting not always worked for me, as those unstable streams sometimes causes exceptions in MPD which it cannot recover by simply stopping/starting player. Only solution satisfying me (accepting this 1-2 sec. drop in the sound) is just to restart MPD. Then it simply recovers from the exception.

I had few cases experimenting with the streams that hang my moode completely and I had to do hard restart.
Since I have this workaround in place, it never happened again ;-)

[Tim Curtis]

@Tim Curtis in the streams I uploaded there are 3 that I had problem with.
This is old issue with specific streams, that after song is changing in the stream, MPD stops playing and logging "Decoder is too slow; playing silence to avoid xrun".
Those streams are:
JB Radio2 (FLAC) with metadata https://maggie.torontocast.com:8076/flac
BDPST ROCK Radio (FLAC) https://s2.audiostream.hu/bdpstrock_FLAC
Radio Calico (FLAC) https://radio3.radio-calico.com:8443/calico

I overcome this issue deploying mpd-watchdog in the way described here by JackRichardson with slight modification for moode:
https://discourse.mopidy.com/t/radio-doe...hdog/424/6
If someone is interested I can share my config.

I modified original mpd-watchdog lines like that:
35c35
< INTERVAL=10
---
> INTERVAL=1
90c90,92
<     $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
---
> #    $MPC status 2>/dev/null | grep -B1 '^\[playing\]' | tr '\n' ' '
>     tail -n 1 /var/log/mpd/log |grep -E "playing silence to avoid xrun"
>
136c138
<             log warning "restarting mpd"
---
>             log warning "xrun error - restarting mpd"

@the_bertrum mentioned something similar in another thread and IIRC he also implemented a watchdog type script that looked for a particular MPD log message and then performed a stop/play sequence to "restart" the stream and hopefully achieve smooth, uninterrupted playback.

The challenge with this type of approach is that it's not really a good, universal workaround since the underlying issue has to do with the continuity of the stream itself. Unstable streams are usually due to broadcaster bandwidth or streaming server issues but sometimes can be due to poor Internet connection at the receiving side i.e., residential Internet gateway/Router. Regardless of which side the player just sees interruptions in stream data that eventually reach unrecoverable levels.

For example on my end the station BDPST ROCK Radio (FLAC) quickly starts stuttering and never recovers from stream starvation. No amount of MPD stop/play sequences results in a smooth, uninterrupted stream. The log has tons of run messages.

True, this kind of solution is "not really a good, universal workaround since the underlying issue has to do with the continuity of the stream itself".
That is why I just shared my solution, which may be applied by anyone interested, if needed. This is not a perfect solution to include in any stable release of course.

Mentioned solution with stop/start I was experimenting not always worked for me, as those unstable streams sometimes causes exceptions in MPD which it cannot recover by simply stopping/starting player. Only solution satisfying me (accepting this 1-2 sec. drop in the sound) is just to restart MPD. Then it simply recovers from the exception.

I had few cases experimenting with the streams that hang my moode completely and I had to do hard restart.
Since I have this workaround in place, it never happened again ;-)

Good point.

Have you considered putting the mpd-watchdog in a Git repo with an Open Source license like GPLv3 or MIT?
You could also add an installer script so people that find the workaround useful can easily install (or remove it).

Also devs might contrib suggestions for enhancing it.