Internet radio station won't play

[matte86]

Hello there :)

I am playing with this great plugin on my Nextcloud server (v30.0.4).

I'm trying to playback an internet radio station and according to the "Getting Started" page, I have to add the stream URL.

Trying to add, for example, these URLs:

• http://streams.egofm.de/egoFM-hq
• http://www.egofm.de/stream/44kb.pls

But for both, I am stuck in the "Loading" state. URLs play fine if I paste them directly in the browser.

Any suggestion on how I can debug this issue further?

[paulijar]

Thanks for the report, I can reproduce the problem. I will investigate this further as soon as I have time. I can't give any direct suggestions how to debug further but it was already a great help that you reported this 👍.

[paulijar]

The reason seems to be how the new Music version handles stream URL redirections and how those streams have set the HTTP headers: Taking http://streams.egofm.de/egoFM-hq as an example, it firsts redirected me to the URL http://egofm-live.cast.addradio.de/egofm/live/mp3/high/stream.mp3?ar-distributor=ffa0&aw_0_req.gdpr=true which then redirected to http://egofm--di--nacs-ais-lgc--05--cdn.cast.addradio.de/egofm/live/mp3/high/stream.mp3?ar-distributor=ffa0&aw_0_req.gdpr=true&_art=dj0yJmlwPTkxLjE1Ny40NC45MyZpZD1pY3NjeGwtd2pub25jbm1iJnQ9MTczNjQ1NDQzOCZzPTc4NjZmMjljI2U0MGQ5NjA1ZjAyMzQzOGEzODE3M2FmMzk0NTVlMDM1, which was the actual stream.

The problem is that both of those redirections return Content-Length header with value 0. Then, the actual stream doesn't return the Content-Length header at all (which is as expected for a live stream). But this combination makes the Music app falsely believe that the actual stream would have length 0, and hence, nothing will be played.

I can easily make a bit hacky fix for this or then use a bit more effort to do the header handling logic with redirections actually work more sanely. Either way, there should be a fix in the next Music app release. I don't see this as so critical that there would be an immediate hotfix for this. If nothing more severe is found, then the next version will likely be released sometime during February.

[matte86]

Thanks a lot for the explanation! I will patiently wait for the next release then :)

[paulijar]

In the meantime, you should be able to work around this by entering the unwieldy URL http://egofm--di--nacs-ais-lgc--05--cdn.cast.addradio.de/egofm/live/mp3/high/stream.mp3?ar-distributor=ffa0&aw_0_req.gdpr=true&_art=dj0yJmlwPTkxLjE1Ny40NC45MyZpZD1pY3NjeGwtd2pub25jbm1iJnQ9MTczNjQ1NDQzOCZzPTc4NjZmMjljI2U0MGQ5NjA1ZjAyMzQzOGEzODE3M2FmMzk0NTVlMDM1 directly to the Music app as the stream URL. It's possible that this URL changes from time to time but at least for now it still works.

[matte86]

I tried adding the unwieldy URL but somehow it is still stuck on "Loading". I see some metadata is being parsed from the playlist (broadcaster name, genre, ...) but playback does not start. URL works when pasted directly in the browser though.

[paulijar]

That's weird because for me, it does play fine using the unmodified Music v2.1.1 on Nextcloud 30.0.4. And I tested it now with similar results on Firefox, Chrome, and Edge. It took a few seconds (maybe 3 - 4 s) to start playing but after that, no problems.

[paulijar]

If you open the browser developer tools with the F12 key and look at the Network tab while clicking the radio station with that long URL, then can you see the endpoint stream being fetched? What kind of response headers are there?

I'm just trying to figure out if there is another issue here, besides the obvious one which I mentioned before.

[matte86]

Unfortunately it seems that the endpoint stream remains in pending state.

[paulijar]

You may see the headers of the pending request once you stop the stream. Right click on the play button to find the stop option.

[matte86]

I have (0) Response headers in the stream section once I stop the playback

[paulijar]

Any errors in nextcloud.log or the browser console?

[matte86]

Perhaps this one?

[paulijar]

I assume that one comes already when loading the page? If so, then it's not relevant. It's just that the AngularJS framework checks upon load if the eval can be used. But as it's forbidden, the framework just falls back to other solutions. And there's no other way to check this than actually try to eval something. At least Firefox prints an error about this to the console but Chrome and Edge don't seem to do it.

[paulijar]

Btw, have you been able to play some other stream? So is the problem specific for this stream of affecting all the streams?

[matte86]

That is an excellent question. I managed to playback this stream successfully: http://streamcdnb1-4c4b867c89244861ac216426883d1ad0.msvdn.net/radiodeejay/radiodeejay/play1.m3u8

The above is an HLS stream. Are there any issues with other protocols?

I am running Chrome on a Macbook Air.

[paulijar]

HLS steams are technically quite different from the other stream types, and have basically totally separate handling in the Music app. The problem could also be in the settings of your HTTP server or proxy (if using any), as the HLS streams have been specifically designed to be trouble-free with any proxies.

To separate server-side issues from the client-side issues, you could try to use some other browser and/or computer if possible. You could also try to disable the stream relaying via your server with the configuration key music.relay_radio_stream, but then you would need to configure also music.allowed_stream_src

[matte86]

Unfortunately the failing streams fail also with Firefox, although there I receive a couple of error messages:

Error playing URL: /nextcloud/index.php/apps/music/api/radio/15/stream
Failed to check for new audio files (error -1); check the server logs for details

[paulijar]

Failed to check for new audio files (error -1); check the server logs for details

This one should be unrelated to radio streams, but something went wrong when checking if there would be any unscanned audio files available. Nextcloud.log could have more details.

[terrlinde]

Hi
jst wanted to throw some context, maybe it helps:
I'm using the Internetradio Streams for more then a year. Last time I updated the Music App to 2.1.1 which broke the streams for me. I just get an Nextcloud toast massage with "Error while playing URL: /index.php/apps/music/api/radio/1/stream"
I dont know which version I had before, must be some what around november 2024.
Great App, keep it up :)

[terrlinde]

Hi jst wanted to throw some context, maybe it helps: I'm using the Internetradio Streams for more then a year. Last time I updated the Music App to 2.1.1 which broke the streams for me. I just get an Nextcloud toast massage with "Error while playing URL: /index.php/apps/music/api/radio/1/stream" I dont know which version I had before, must be some what around november 2024. Great App, keep it up :)

After some more digging I also set the relaying options to false and added my radiostations to the allowed streams. The error messege changed to the origin stream URL, but still unable to playback. Firefox Browser Debug also shows it is violating directive of Content security policy. Will try to add the unwieldy URLs.

[paulijar]

@terrlinde
What changed in the version 2.1.0 is that all the radio streams are now relayed via your Nextcloud server by default. Previously, the streams were streamed directly from their original source to your browser. This old system had two major drawbacks:

1. If the original source stream used plain HTTP, the user had to separately allow "mixed content" in their browser settings to play such streams. In the near future, the use of mixed content may get blocked for good by the browsers.
2. We were forced to add exceptions to the Content-Security-Policy to allow the streaming from external sources. By default, we used to allow audio streams from all possible sources ['http://*:*', 'https://*:*'] to make it easy for the users but it bugged me that this decreased the overall security a bit. I believe that the "security hole" created was not a severe one but anyway, taking such calculated risks should be the responsibility of the cloud admin and not made automatically for them.

Now, you should get back the old behavior by configuring

'music.relay_radio_stream' => false,
'music.relay_podcast_stream' => false,
'music.allowed_stream_src' => ['http://*:*', 'https://*:*'],

Note that you need to reload the page in the browser for the allowed_stream_src to take effect.

If the problem with the relaying is not caused by the redirection bug (which I already fixed this week) but affects all the non-HLS streams, then it could be that a reverse proxy or similar is interfering with it.