Delays in starting a radio stream.

[MarmiteSandwich]

Hi all,
This has been an issue for some time now (months?), which seems to be getting worse, so I decided to do something about it. Couldn't find anything obvs wrong with streaming settings and it happens with 2 different renderers, so I have discounted the renderer. The context is MinimServer and MinimStreamer on 2 different Raspberry Pis, set up in identical ways. The renderers are upmpdcli/mpd on a pi (with OpenHome on - Fig2), and Cambridge Audio CXN v2, via BubbleUPnP server in Windows for OpenHome purposes (Fig1). When I choose a radio station from MinimServer and select play, as often as not, there is a delay for up to 1 minute, after which I get a response from Android BubbleUPnP like Fig1. If I leave it, it may spontaneously start to play within the next 5 minutes, sometimes it seems to stay in that state indefinitely. Before this behaviour became common, the stream would just play within a few seconds. If the play icon is showing, I can press on it, and get a response like in Fig2. The stream definitions for the stations illustrated can be inspected in _Radio.m3u.

Any ideas/suggestions welcome.
Marmite.

PS otherwise MinimServer and MinimStreamer have served me well since the BBC first changed to HLS streams.
Fig1    
Fig2    
minimserver-update-218
minimstreamer-2.0.9
BubbleUPnP Server 0.9-update43

[simbun]

If you're playing to the BubbleUPnP local renderer do they play immediately? I've tested your playlist here and through the local renderer all the BBC stations play immediately.
I haven't tested them all but most of the others play with a small delay except [JFM] which produces 'NetworkSource: stream error response HTTP/1.1 500 Internal Server Error' in the MinimServer log.

[MarmiteSandwich]

(12-08-2022 17:32)simbun Wrote:  If you're playing to the BubbleUPnP local renderer do they play immediately? I've tested your playlist here and through the local renderer all the BBC stations play immediately.
I haven't tested them all but most of the others play with a small delay except [JFM] which produces 'NetworkSource: stream error response HTTP/1.1 500 Internal Server Error' in the MinimServer log.

I have had the same experience with the Bubble local renderer, although I will try it again to be sure. The problem is that this is an intermittent behaviour (the worst sort). Sometimes (with either renderer) they play straight away, and sometimes (with either renderer) they don't. I'm fairly sure that the stream spec file is ok - it has worked for years without these symptoms. I have had problems with Jazz Fm (JFM) before - I think the URL I am using is flaky.
Marmite

[MarmiteSandwich]

(12-08-2022 17:32)simbun Wrote:  If you're playing to the BubbleUPnP local renderer do they play immediately? I've tested your playlist here and through the local renderer all the BBC stations play immediately.
I haven't tested them all but most of the others play with a small delay except [JFM] which produces 'NetworkSource: stream error response HTTP/1.1 500 Internal Server Error' in the MinimServer log.

Result 1 of test stream to local renderer in Android BubbleUPnP. After waiting about 5 minutes. Fig3.
   
Result 2 of test stream as above. After < 1 minute. Fig4.
   

[simoncn]

If the 501 error is coming from MinimStreamer or the BBC stream, it should show up in the MinimServer log if the logging level is set to Debug. Please try this.

[MarmiteSandwich]

(12-08-2022 20:05)simoncn Wrote:  If the 501 error is coming from MinimStreamer or the BBC stream, it should show up in the MinimServer log if the logging level is set to Debug. Please try this.

Log attached with debug set, after attempting fig3 and fig4 again.
Marmite

[simoncn]

Thanks for this log. There are no 501 errors. I see the following:

1) The stream R4 started and was terminated immediately by the renderer
2) The stream R4 started and played for about 36 seconds
3) The stream AN started and was terminated immediately by the renderer
4) The stream WS started and was terminated immediately by the renderer
5) The stream TSF started and was terminated immediately by the renderer
6) The stream JLR started and was terminated immediately by the renderer
7) The stream PBS started and had a problem reading the stream metadata
8) The stream KUV01 started and had a problem reading the stream metadata
9) The stream PJR started and had a problem reading the stream metadata
10) The stream RES started and had a problem reading the stream metadata
11) The stream KUV01 started and had a problem reading the stream metadata

From this, it looks like there is some issue with your internet connection.

[MarmiteSandwich]

(12-08-2022 21:09)simoncn Wrote:  Thanks for this log. There are no 501 errors. I see the following:

1) The stream R4 started and was teminated immediately by the renderer
2) The stream R4 started and played for about 36 seconds
3) The stream AN started and was teminated immediately by the renderer
4) The stream WS started and was teminated immediately by the renderer
5) The stream TSF started and was teminated immediately by the renderer
6) The stream JLR started and was teminated immediately by the renderer
7) The stream PBS started and had a problem reading the stream metadata
8) The stream KUV01 started and had a problem reading the stream metadata
9) The stream PJR started and had a problem reading the stream metadata
10) The stream RES started and had a problem reading the stream metadata
11) The stream KUV01 started and had a problem reading the stream metadata

From this, it looks like there is some issue with your internet connection.

Thanks for this, Simon. An important lead for me to follow up.
Marmite.

[MarmiteSandwich]

For the record:
I discounted Simon's broadband theory, since I have been experiencing this issue at 2 different locations with different internet connections, and also streaming from Qobuz is not affected. Further experimentation and investigation highlighted 1 Android renderer and control point, and one station as being the worst cases. The guilty (Lenovo) device on which BubbleUPnP was underperforming had a security feature which randomized the MAC address for its wifi, which I turned off. The station causing the most frequent stalled streams was encoded in aac+, and had a stream with an optional .m3u extension on the name. I removed this extension and used other devices for control and rendering and found an acceptable level of first time playing.

The stalled attempts to play still occur occasionally, and seem to be worse with aac streams, and streams where the Lenovo device is in any way involved. The problem is still intermittent and not sufficiently frequent to warrant further experimentation, therefore I have parked this problem pending further developments.
Marmite