Internet Radio URL is modified by Music, leading to a playback error

[jacotec]

I really would like to listen to my Radiotunes stations, but Music unfortunately cripples the URL, resulting in an error.

A subscriber URL for Radiotunes looks like this:

https://listen.radiotunes.com/premium/dreamscapes.pls?listen_key=xxxxxxxxxxxxxxxxxxxxxxxx

Unfortunately, in the broser console I see that this URL is opened by Music:

https://prem2.radiotunes.com/dreamscapes?xxxxxxxxxxxxxxxxxxxxxxxx

Due to the bug, the "listen_key=" is removed from the URL, leading to the error.

[paulijar]

Thanks for the report.

Your original URL points to a playlist file which should contain the actual stream URL. But maybe Music parses the playlist file somehow incorrectly. If you download the pls file from your original link, and open it with a text editor, then it should look something like this:

[playlist]
NumberOfEntries=1
File1=https://some.url
Title1=Some title
Length1=-1
Version=2

Is the URL shown there different from the one used by the Music app, as seen in the browser console?

[jacotec]

@paulijar Yes, the URL in the file is the one shown in the broweser console.
But opening the file in VLC play just fine ...

Storing the .pls file in my Nextcloud and clicking on it opens the Music Player which then stucks at "Loading..."

[paulijar]

If I try to open the URL https://prem2.radiotunes.com/dreamscapes on the browser, then I don't get any kind of response. But if, instead, I open http://prem2.radiotunes.com/dreamscapes (i.e. "http" instead of "https"), then there is a response which requests credentials.

1. When you view the contents of the PLS file, does the URL specify "http" or "https" or neither?
2. If you open http://prem2.radiotunes.com/dreamscapes?xxxxxxxxxxxxxxxxxxxxxxxx into your browser, replacing the "xxxx..." with the actual key from within the PLS, then does your browser play the stream?

[paulijar]

@jacotec Would you be able to check the two points listed above?

[bluesaxman]

I don't know if I should make a new issue or if this should just be part of this same issue, hopefully I'm reporting right.

I noted today that with it seems any http URL used for an internet radio station, Music (the web interface part) changes it to https before making the request. Even though it does show correctly in the info panel. I have not tested this on mobile through the API's yet. But can update later today if I'm able to test.

EDIT:
I seem to have solved this problem. It was unrelated to the Music code base, It looks like Chrome "blocks" mixed content by default, which apparently means "Upgrades" http urls to https without asking the user or the application if its ok. Thanks Chrome! Don't think that is the same problem @jacotec is having though. But it might be worth checking, might be a confounding factor in tracking down the issue.

SIDE Note: Might be helpful to include that documentation in the options page or something. I found it by grep'ing the source for "Error playing URL" average user probably isn't going to know grep though.

[paulijar]

@bluesaxman
It's actually stated there right as the first point of the trouble shooting. But that doesn't help much since users never read any manuals 😆.

Firefox has similar feature to Chrome, blocking the mixed access by default. To make this actually user-friendly, the Music app should detect the mixed HTTP/HTTPS access and the browser setting blocking it and give an error message describing the situation. But I'm not certain if that is technically possible; it would need some investigation.

It has actually been my main theory that this same root cause is behind @jacotec's problem. I asked the questions in #1025 (comment) in attempt to either confirm or disprove this theory.

[bluesaxman]

Ah, I totally missed that, funny because I read all the steps above it. But somehow had blinders on for the Troubleshooting section.

I submitted a bug report to the chromium team, since, at least to me, block and rewrite but still send don't seem like the same thing. If requests are supposed to be blocked, they should be blocked, which would make it easier for you folks to check for those conditions. As it stands now, chrome just transparently rewrites the request before sending it, instead of dropping the request and throwing some kind of detectable error. Probably wont change, but I figured I'd at least poke them about it.

After a little digging, I found this which might be exactly what is needed for the detection https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event Hopefully it helps.

[jacotec]

@jacotec Would you be able to check the two points listed above?

@paulijar Sorry for the late reply, I had a pretty high workload.

1. The links in the .pls file are all http
2. Yes, any link pasted into the browser starts immediately to play the stream.

[jacotec]

@bluesaxman Good finding!
I checked in Firefox and it works here. I usually use Edge everywhere and here it does not work, neither on my MacBook nor on my PC. But there is now warning or display in the browser anywhere, also not in the address bar where usually messages like blocked popups etc. appear.

I have to admin that I had a complete different understanding of the functionaliy of the music app here. I did not think that the browser directly plays the stream, I thought the stream runs through my Nextcloud server (like a proxy, or like my Logitech Music Server does).

That seems to be the only solution for this issue as well (not sure if this is possible in a NC plugin, but when I play a local music file on my Nextcloud it works pretty well in any browser).

[paulijar]

@jacotec Okay thanks, so this seems to confirm that HTTP/HTTPS mismatch is the root problem here. When you try to play the HTTP stream on Edge, and you open the browser developer console by pressing F12 and selecting the "Console" tab, then you will probably see something like this:

Now, if you click the padlock icon on the top bar, and select "Permissions for this site", you should be able to enable the "Insecure content" on this page. Then, reload the page and the stream should work.

[jacotec]

@paulijar Yeah, that works ... however, it's a bit ugly workaround. ;-)

What about my idea to proxy the streams through the Nextcloud? That would solve some issues:

• We don't need to take care about insecure content
• We don't have issues with geolocked streams when traveling

[paulijar]

What about my idea to proxy the streams through the Nextcloud?

Maybe. But I cannot tell outright if this is possible or not on Nextcloud. Some investigation and experimenting would be needed, and I make no promises about when that could happen.

[bluesaxman]

If I may interject again, having nextcloud proxy the connection should be possible with ffmpeg at the very least, however, it may or may not be feasible depending on how willing those contributing to the project are to implement it.

It seems a little out of scope for the plugin to me, but if those building it are willing, it would be a neat feature to have. Should be able to pull in ffmpeg to relay the stream, but I don't know how much additional code that might require to implement. Sometimes simple sounding solutions turn out to be more complex than they are worth. I'd totally do it if I had time, just because I fool around with ffmpeg a lot, but I don't really have time to contribute (aside from my comments here and there, which I hope are helpful) sadly.

[paulijar]

Closing in favor of the newly created feature request #1035.