Flux FM stations start and then stop

[tominthevan]

Months ago this phenomenon was not happening on my system, but it has been happening for a while recently and I don't recall when I first noticed it. Even now, it happens most times, but not all the time when I select a Flux FM station. Here is what happens:

   1. I select a station - say, for example Flux-Lounge
   2. The station's Cover appears on the playback page, and the music starts, but the text below the cover is (i.e. not updated)
             Variable Bitrate
              Flux Lounge
              Flux Lounge
   3. The playback control switches from the play icon to the pause icon (like normal)
   4. The music plays for about 10 seconds and the text under the cover is updated to show the actual bitrate and the track currently playing
   5. The music continues to play for about another 5 seconds and then stops (at least the sound stops)

At this point there is no sound but the playback control is still the pause symbol and the histogram beside the Flux Lounge entry in the playlist is still bouncing along. If I click the playback pause icon it changes to the play icon. If I click the play icon, the process repeats.

I have tried a number of other stations and none show this behavior, just the Flux stations.

I originally was running Moode version 7.2 when I started to investigate this issue. When I realized there was a Moode update available, I updated. The problem persists.

My system configuration is:
  Raspberry Pi 3b+
  Justboom Amp hat
  Moode 8.01

I welcome any advice on how to fix this problem or diagnose it further. Since it's so easy to demonstrate, I'd love to hear from other Flux listeners who might (or might not) have this annoying problem.

Tom

[the_bertrum]

I get this sometimes on a few of the stations I listen too, but never so fast and some days, not at all. I tried a few fulx stations today and they all lasted for at least a few minutes (which is as long as I tested them for) and I never had any stop on me.
I suspect my system does this when the wifi signal to my Pi Zero W in a cabinet gets just too weak, but I've not run any tests to prove it.

[TheOldPresbyope]

@tominthevan

I think @the_bertrum is on the right track. 

The station's data stream is being decoded and passed on to the ALSA chain by MPD (Music Player Daemon). MPD will silence the output when it experiences data underrun (the data stream isn't arriving fast enough). I've seen this occasionally but in my case it was usually temporary, sometimes creating a putt-putt-putt effect. Could be the result of low WiFi signal, traffic congestion on the LAN or WAN, etc. I don't have an explanation for complete stoppage though, especially since you're experiencing it only with Flux FM stations.

I'm away from a player I could test with at the moment. I don't recall if MPD underrun messages are echoed to the moOde log. You might have to example the MPD log, /var/log/mpd/log. If necessary, you can bump MPD's log level to "Verbose" in the MPD Configuration screen. If you do, you'll want to revert to "Default" log level when you're done because it's...verbose

I haven't tried all the Flux FM stations lately, but the few I checked earlier today played without interruption for at least 15 minutes each.

Oh, that bouncing "spectrum" icon? It's a time-based animation unrelated to incoming signal, strictly eye candy.

Regards,
Kent

[tominthevan]

@the_bertrum and @TheOldPresbyope

Thanks for your responses. Yes it is possibly a network problem. I don't think it is my local network for the following reasons:
  1. My internet service is 500 Mbps and is monitored by me and another service that reports to me.
  2. my 5G WIFI access point is 5 meters away from the moode player with 1 layer of drywall between.
  3. The cutout of Flux stations is permanent when it happens and is predictable, unlike other random station cutouts.

It could be the internet connection between me and Flux's server. But it seems that if that were the case it wouldn't be so predictable. On the other hand, if it were a moode problem, then @the_bertrum would have the same issue and it seems he doesn't.

I noticed that the way the track name and bit rate is displayed under the Cover for Flux stations is different from other stations. In all other stations I have used, this information is updated immediately when I start a station. For Flux stations, the audio starts but the bit rate and track name takes 5 to 10 seconds to appear and then in most cases a few seconds later, the audio stops.

Anyway, right now I am listening to Flux B Funk, so it's random and annoying but not permanent. I will try @TheOldPresbyope's suggestion and see what the debug log can show.

Thanks again for your ideas and suggestions.

Tom

[the_bertrum]

I've been doing some investigation into what happens when I see this on my player.  In the mpd log (/var/log/mpd/log) I see this when the music stops:

Code:

Apr 08 09:14 : player: played "https://mediaserv73.live-streams.nl:18058/stream"
Apr 08 10:29 : alsa_output: Decoder is too slow; playing silence to avoid xrun
Apr 08 10:29 : alsa_output: Decoder is too slow; playing silence to avoid xrun

So I guess that means not enough data is flowing to something at some point.  I don't know where in the chain "the decoder" is.

I still suspect the poor quality of the wifi connection is the ultimate culprit (Pi zero inside and old radio on the other side of a brick wall from the router).  Sometimes the radio recovers and starts playing again, sometimes it never recovers and I have to stop then start playback, on occasion if I stop and restart soon enough I get a CURL timeout.
I'll run the station for a while on a player with an Ethernet connection, see if that ever has problems.

[TheOldPresbyope]

@the_bertrum

that "alsa_output::" message is issued by MPD's ALSA output plugin.

FluxFM Sound of Berlin has been playing uninterrupted for hours here [1] on a moOde 8 player on an RPi3A communicating via 5GHz WiFi to a near-by cable modem's access point (Link Quality=70/70  Signal level=-38 dBm).

Regards,
Kent

[1] I listened just long enough to get my heart started---gotta love the beat!---then put it on mute.

[the_bertrum]

[1] I listened just long enough to get my heart started---gotta love the beat!---then put it on mute.

Did you periodically un-mute to check it was still really playing?  The "playing silence" bit means that the UI looks like all is still hunky-dory.

I tried on my Ethernet connected Pi4 and see the same behaviour, although CamillaDSP alters the log output slightly:

Code:

Apr 11 07:33:04.672 INFO Starting playback from Prepared state, module: camillalib::alsadevice
Apr 11 08:03 : alsa_output: Decoder is too slow; playing silence to avoid xrun
CDSP Plugin ERROR: XRUN OCCURRED!

I also experimented with trying to "stabilise" the input to the decoder by having SOX resample everything for me (assumption that the recoding would hold up the stream enough to provide a steady output (I don't know what I'm talking about here so that assumption could be hilariously wrong)).  On Friday evening that resulted in 5 hours of glitch free listening, on Saturday morning I didn't get half an hour.

So It isn't hokey wifi, or underpowered Rpi that are to blame, must GI-GO I reckon.  Unless there are ways to tweak MPD so it handles under-runs differently.  The fact that it never recovers from the under-run is odd, given that a stop and start recovers the situation.

[Tim Curtis]

The symptoms suggest bandwidth or connection limiting at the broadcaster. Many streaming radio broadcasters limit bandwidth and number of connections to control cost and comply with streaming royalties.

I've been listening to one of the FluxFM stations for couple of hours now. The first time I tried though it stopped after a few minutes.

[TheOldPresbyope]

@the_bertrum

Ah, but I was listening virtually---no error messages showed up in the log.

I guess I was just lucky not to experience any since @Tim Curtis's hypothesis seems likely.

To debug this further, it would be useful to know how the FluxFM servers are configured. What comes to mind about the stop/start operation is that it triggers a (new) HTTP handshake sequence with the FluxFM server. That's not enough of clue for this "bear of very little brain."

Regards,
Kent

[the_bertrum]

I read some stuff on the MPD github that says this error is commonly due to an unstable connection. Some reported that swapping their Ethernet cables fixed it, so I tried another cable on one of my players, and it lasted a lot longer. Still had the issue though. It is far worse on my very poor wifi in box on a Zero, so I guess it is a combination of the feed and the poor wifi. Apart from the FluxFM stations (which I sometimes see it on, but not always), I can get the issue reliably on Scala, and ClassicFM both of which are trying very hard to push folk onto their own app, and Dandelion Radio which makes no secret of the fact that sometimes they just run out of bandwidth and folk get kicked off. It is very common on Scala and ClassicFM which are alas the two that my wife likes to have on all day, and tmuch rarer on Dandelion which I would have running all day if I could get away with it.

I'm experimenting with a not-very-elegant script that checks the mpd log every second and sends mpc stop then mpc play if it sees the xrun message.