Handle playlist of internet radio stations

[ik666]

Added playlist support for handling internet radio stations. No transcoding yet (probably not neccesary for the usual codecs).

Feature can be tested with:

• Generate Radio Browser playlist and copy it to a share (do not place to many radio stations inside playlist file, yet)

my_internet_radio_station.m3u file consists of radio stations like

#EXTM3U

#RADIOBROWSERUUID:962cc6df-0601-11e8-ae97-52543be04c81
#EXTINF:1,Dance Wave!
https://dancewave.online/dance.mp3

• VLC navigating to VLC media player -> Universal Plug 'n Play -> UMS -> my_internet_radio_station.m3u -> radio

[x] cache radio station metadata in a table
transcoding". Maybe this is only cosmetic and can stay this way.
[x] read metadata from radio browser API if possible

[SurfaceS]

I'm not reviewed the core goal of the PR. Only the Java part and UMS integration.

[SurfaceS]

Tell me if I'm wrong, but I checked the code and I think that the changes in RequestV2 can be completely removed, as the server serve the media url to the client (as it should), so this part is never/should never been reached (and UMS is not a proxy).

For the other part (retrieving media/radio info), we should care that some users do not want that UMS browse the internet (that is why I put this in external).

[ik666]

Tell me if I'm wrong, but I checked the code and I think that the changes in RequestV2 can be completely removed, as the server serve the media url to the client (as it should), so this part is never/should never been reached (and UMS is not a proxy).

If you want the playlists to work as intended, UMS needs to retrieve the data from the external radio station and stream it to the renderer (is kind of a proxy). The stream could also be transcoded if needed. The external URL could of course on top be presented as a res resource in the DIDL result. The control point/renderer should pick the right one (as proposed by the CDS v4 service doc).

For the other part (retrieving media/radio info), we should care that some users do not want that UMS browse the internet (that is why I put this in external).

But: If UMS is not connecting to the internet, it can not serve the radio station. Then this feature won't work.

[ik666]

@SurfaceS I'm unsure who made the change: it looks like RequestV2 is serving only WebAudioStreams now. I think this was initially matching WebStream as this would also let playlists of VideoStreams work like IPTV playlists. I haven't tested video playlists yet, though.

[ik666]

@SubJunk Do you want to check it now? For my playlist it's working.

[SurfaceS]

@SurfaceS I'm unsure who made the change: it looks like RequestV2 is serving only WebAudioStreams now. I think this was initially matching WebStream as this would also let playlists of VideoStreams work like IPTV playlists. I haven't tested video playlists yet, though.

I did it.

You was overriding the isCodeValid method of WebAudioStream (wtf... that is to check if the entered code is valid) to bypass the normal handle in RequestV2, then you check if the item is a WebStream to run your own code.
So a VideoStreams was never reaching your code (or it was a real blocked media with code is invalid !).

BTW, the RequestV2 should not to be changed, as it is not intended to create a stream for an item.
Stream things are handled by the StoreItem itself. And StoreItem itself will use an engine stream when needed.

For now, without any change WebAudioStream are served fine.
You can try adding a new shared content like your test url (https://dancewave.online/dance.mp3) to it and see that.
So why changing something that is running fine.

---

PR
Handling Playlist that may contain a third party #RADIOBROWSERUUID, why not if users are aware of it.
Decorate a WebAudioStream with a possibly de.sfuhrm.radiobrowser4j.RadioBrowser same a last one.
Decorate a WebAudioStream by extracting audio information from ice or icecast protocol is nice.
Storing WebStream Metadata is nice.

The others are in my pov (and only my point of view) unproductive / pollute a lot.
Most code should sit under the WebAudioStream itself, not playlist.
-> PlaylistFolder create a WebAudioStream, advise WebAudioStream that is has a #RADIOBROWSERUUID, WebAudioStream do the stuff itself.

---

privacy

For the other part (retrieving media/radio info), we should care that some users do not want that UMS browse the internet (that is why I put this in external).

But: If UMS is not connecting to the internet, it can not serve the radio station. Then this feature won't work.

adding the radio station as a shared content, and UMS going itself browsing a third party metadata server is not the same at all.

[ik666]

@SurfaceS I'm actually fine with the changes. The streams are served as expected.

[SurfaceS]

@ik666 I checked the RequestV2 changes, and that break transcoding for WebAudioStream from shared content when renderer cannot handle stream.

I made a PR on your git (ik666#89) that should fix most of my previous post remarks, and add thumbnail creation.

Have a shoot and let me know if it is something wrong on it.

[SubJunk]

@ik666 I'm excited to test the feature, just waiting for the code review conversations to be resolved before I test :)

[ik666]

@SurfaceS I see some issues with the following playlist entry.

#EXTM3U


#EXTINF:1,Discover Trance
https://www.discovertrance.com/DiscoverTrance-high.m3u

The items inside this playlist are identified as WebVideoStream and do not play any more. This was not the case before the merge. I believe the logic for identifying the content type (of the playlist entries) was removed. Quick look: Problem is that the WebStreamMetadata doesn't have the type information any more and the PlaylistFolder is not testing against that type any more ... You can test your branch also in the ums web ui I believe. It's playing sound if it's working ...

[SurfaceS]

Sorry, merging this to m3u_uri_handling has closed it.

I corrected thing in this PR.
https://github.com/ik666/UniversalMediaServer/pull/90/files

[ik666]

I think this is just OK ... thanks !