DVBViewer Pro can't open and play this radio stream, unlike Foobar2000

[amirhs]

Folks, I'm running DVBViewer Pro V7.3.1.0, and it can't play or stream the URL for KBS Classic FM. The URL is http://serpent0.duckdns.org:8088/kbsfm.pls
I've found it from the Radio Browser directory, and Foobar2000 has no issues playing and streaming it. Is this a known bug with these types of URLs, or is there a work-around? I've tried checking or unchecking the "Play as file" check box to no avail.

Thanks,
Amir

[Griga]

1 hour ago, amirhs said:

I'm running DVBViewer Pro V7.3.1.0, and it can't play or stream the URL for KBS Classic FM.

 

Confirmed. It can play the URL inside the PLS playlist file (-> download it and open it with a text editor), but this URL contains an expiration date, so it will probably only work for a short time. The PLS content gets updated frequently, I guess.

 

DVBViewer can't handle (quite unusual) PLS playlist files, that contain the URL of another *.m3u8 playlist file, as used for the Apple HLS streaming format... kind of Matryoshka doll .  I'll look for a fix and post here, when it is done.

 

[amirhs]

9 hours ago, Griga said:

 

Confirmed. It can play the URL inside the PLS playlist file (-> download it and open it with a text editor), but this URL contains an expiration date, so it will probably only work for a short time. The PLS content gets updated frequently, I guess.

 

DVBViewer can't handle (quite unusual) PLS playlist files, that contain the URL of another *.m3u8 playlist file, as used for the Apple HLS streaming format... kind of Matryoshka doll .  I'll look for a fix and post here, when it is done.

 

 

Thanks both for the prompt reply and for taking care of the issue. Looking forward to testing your fix whenever it becomes available. Your efforts would be much appreciated.

 

Best,

Amir

[amirhs]

Perhaps related to this bug, the following station, again taken from the Radio Browser directory, cannot be played or streamed via DVBViewer Pro either: http://radio.linn.co.uk:8004/autodj.m3u
Foobar2000 has no issues playing it.

Best,

Amir

[Griga]

No problem here with the current or older DVBViewer versions. It's just an M3U playlist file containing the URL of a 320 kbps high quality MP3 stream. You can also try to use the URL inside the M3U directly (-> download it and open it with a text editor).

 

If it won't work, please reproduce the problem in DVBViewer debug mode and attach a support.zip here.

 

[amirhs]

Hmm. The URL inside it does work, but the playlist itself cannot be played or streamed by DVBViewer Pro. Let me see if I can generate the log.

[amirhs]

9 hours ago, Griga said:

No problem here with the current or older DVBViewer versions. It's just an M3U playlist file containing the URL of a 320 kbps high quality MP3 stream. You can also try to use the URL inside the M3U directly (-> download it and open it with a text editor).

 

If it won't work, please reproduce the problem in DVBViewer debug mode and attach a support.zip here.

 

My Support.zip file is attached. As mentioned before, DVBViewer Pro can't open the URL which points to a playlist or something.

support.zip

[Griga]

Quote

18.04.25 20:21:29.658 TfrmMain             LoadFromFile     http://radio.linn.co.uk:8004/autodj.m3u

 

Obviously you have tried to play the M3U as media file. Don't tick "Play as file" in the Channel Editor!

 

[amirhs]

17 hours ago, Griga said:

 

Obviously you have tried to play the M3U as media file. Don't tick "Play as file" in the Channel Editor!

 

That's true. However, the Open URL dialog, available from the Playback menu, doesn't provide the ability to enable or disable opening URLs as files. I was trying to use the Open URL dialog to see if I can play it before adding it to my channel list. If possible, please consider adding this check box to the Open URL dialog.
As you said, this option is available in the Add channel/ stream dialog, so I have no issues playing it if I add the URL to my channel list.

 

Thanks,

Amir

[Griga]

21 hours ago, amirhs said:

If possible, please consider adding this check box to the Open URL dialog.

 

For giving users another opportunity to make wrong decisions and trigger more support cases?

 

Playlist files (*.m3u, *.pls) referenced by a URL are mostly used as container for internet radio URLs. This enables providers to keep the URL persistent, even if the audio stream URL changes, so the user is not affected by the change, because the player gets the playlist first and then uses the (hopefully) up-to-date URL inside. The downside compared to using the direct address is an additional delay before playback starts, though.

 

That's why the handling of playlist URLs is implemented in the live stream / internet radio branch, which is connected to the channel list (as long as "play as file" is unchecked). The "Open URL" menu item basically uses the file playback branch, but before playback starts DVBViewer tries to estimate to what kind of stuff the URL is pointing and whether it might be a live stream with a format supported by DVBViewer natively. If yes, it is played like a channel, though it is no channel list entry. 

 

However, this content type detection does not consider that URLs entered by the user may point to a playlist file. So it is classified as "unknown type" and playback is delegated to the LAV source filter (if installed). Since it is based on the powerful FFmpeg libraries, it "understands" much more media types than DVBViewer. Except playlists, unfortunately. That's why this case ends up with an error message: "Cannot render media file...".

 

A simple solution is to add a bit of code in the DVBViewer content type detection, that recognizes *.m3u and *.pls playlist file extensions and directs the processing to the live stream branch. However, this will still fail if the URL inside the playlist points to a stream with a format that DVBViewer cannot handle natively, e.g. FLAC or OPUS audio, which the LAV source filter would handle quite happily.

 

So a better solution would be to download the playlist first, have a look inside, check the content type of the contained URL and then decide how it must be processed. Or with other words: Replace the playlist URL entered by the user by the URL contained in the playlist at an early stage.

 

So, as you can see, deciding which playback branch should be used requires a lot of "insider" knowledge that users mostly don't have. And there is an important difference between a "Play as File" checkbox for "Open URL" and channel list entries:  In the "Open URL" dialogue it would apply to different URLs, probably only used one time. In the channel list it applies to a specific URL, probably used many times on channel switching. Here users can try what works best, and stay with it. Since the file playback branch is also able to play live streams in many cases and vice versa, both settings may work, but maybe with certain advantages / disadvantages.

 

So far my considerations up to now...

 

[amirhs]

On 4/20/2025 at 12:05 PM, Griga said:

 

For giving users another opportunity to make wrong decisions and trigger more support cases?

 

Playlist files (*.m3u, *.pls) referenced by a URL are mostly used as container for internet radio URLs. This enables providers to keep the URL persistent, even if the audio stream URL changes, so the user is not affected by the change, because the player gets the playlist first and then uses the (hopefully) up-to-date URL inside. The downside compared to using the direct address is an additional delay before playback starts, though.

 

That's why the handling of playlist URLs is implemented in the live stream / internet radio branch, which is connected to the channel list (as long as "play as file" is unchecked). The "Open URL" menu item basically uses the file playback branch, but before playback starts DVBViewer tries to estimate to what kind of stuff the URL is pointing and whether it might be a live stream with a format supported by DVBViewer natively. If yes, it is played like a channel, though it is no channel list entry. 

 

However, this content type detection does not consider that URLs entered by the user may point to a playlist file. So it is classified as "unknown type" and playback is delegated to the LAV source filter (if installed). Since it is based on the powerful FFmpeg libraries, it "understands" much more media types than DVBViewer. Except playlists, unfortunately. That's why this case ends up with an error message: "Cannot render media file...".

 

A simple solution is to add a bit of code in the DVBViewer content type detection, that recognizes *.m3u and *.pls playlist file extensions and directs the processing to the live stream branch. However, this will still fail if the URL inside the playlist points to a stream with a format that DVBViewer cannot handle natively, e.g. FLAC or OPUS audio, which the LAV source filter would handle quite happily.

 

So a better solution would be to download the playlist first, have a look inside, check the content type of the contained URL and then decide how it must be processed. Or with other words: Replace the playlist URL entered by the user by the URL contained in the playlist at an early stage.

 

So, as you can see, deciding which playback branch should be used requires a lot of "insider" knowledge that users mostly don't have. And there is an important difference between a "Play as File" checkbox for "Open URL" and channel list entries:  In the "Open URL" dialogue it would apply to different URLs, probably only used one time. In the channel list it applies to a specific URL, probably used many times on channel switching. Here users can try what works best, and stay with it. Since the file playback branch is also able to play live streams in many cases and vice versa, both settings may work, but maybe with certain advantages / disadvantages.

 

So far my considerations up to now...

 

Well, as for the "For giving users another opportunity to make wrong decisions and trigger more support cases" argument, the current approach where the Open URL dialog doesn't allow for opening playlist files is more problematic and error-prone, IMO, as it doesn't support playlist-oriented URLs at all. It's also different from the Internet Radio section, and that difference alone might be enough to cause issues on its own. At any event, I do understand the concerns you've raised.

[amirhs]

On 4/16/2025 at 10:41 AM, Griga said:

 

Confirmed. It can play the URL inside the PLS playlist file (-> download it and open it with a text editor), but this URL contains an expiration date, so it will probably only work for a short time. The PLS content gets updated frequently, I guess.

 

 

 

You are right - it worked for a short time, and stopped working today. I downloaded the file again, and extracted the updated URL from it. I hope this can be fixed on the part of DVBViewer in order for these types of playlists to be supported.

[Griga]

Both issues are already fixed. The fixes will be part of the next DVBViewer (beta) release:

• Fix: Playback: Playlist URLs entered via Playback → Open URL were not handled and caused an error message. Now the processing is delegated to the TS Stream (live) playback branch, thus covering streams that DVBViewer can handle natively (see here).

• Fix: TS Stream: DVBViewer could not receive HLS, MPEG Dash or TS streams, if the URL pointed to a M3U or PLS playlist file containing the stream URL (see here).

The first fix will cover most cases, but not all, as already stated. So I'm still considering to implement a more complete and more costly version. However, the cost-value ratio has to be considered too, because my resources are limited.

1 hour ago, amirhs said:

Well, as for the "For giving users another opportunity to make wrong decisions and trigger more support cases" argument, the current approach where the Open URL dialog doesn't allow for opening playlist files is more problematic and error-prone,

 

That's true, but why provide a checkbox for something that can be decided automatically? DVBViewer has for sure more "insider" knowledge required for correct handling than users. Nevertheless it may happen in certain cases that the automatic decision is not the optimal one, though working. So the Channel Editor gives users the opportunity to try. For trial and error you don't need expertise.

 

[amirhs]

1 hour ago, Griga said:

Both issues are already fixed. The fixes will be part of the next DVBViewer (beta) release:

• Fix: Playback: Playlist URLs entered via Playback → Open URL were not handled and caused an error message. Now the processing is delegated to the TS Stream (live) playback branch, thus covering streams that DVBViewer can handle natively (see here).

• Fix: TS Stream: DVBViewer could not receive HLS, MPEG Dash or TS streams, if the URL pointed to a M3U or PLS playlist file containing the stream URL (see here).

The first fix will cover most cases, but not all, as already stated. So I'm still considering to implement a more complete and more costly version. However, the cost-value ratio has to be considered too, because my resources are limited.

 

That's true, but why provide a checkbox for something that can be decided automatically? DVBViewer has for sure more "insider" knowledge required for correct handling than users. Nevertheless it may happen in certain cases that the automatic decision is not the optimal one, though working. So the Channel Editor gives users the opportunity to try. For trial and error you don't need expertise.

 

Thanks for the fixes! Looking forward to the upcoming beta release to test everything.

[amirhs]

On 4/21/2025 at 1:19 PM, Griga said:

Both issues are already fixed. The fixes will be part of the next DVBViewer (beta) release:

• Fix: Playback: Playlist URLs entered via Playback → Open URL were not handled and caused an error message. Now the processing is delegated to the TS Stream (live) playback branch, thus covering streams that DVBViewer can handle natively (see here).

• Fix: TS Stream: DVBViewer could not receive HLS, MPEG Dash or TS streams, if the URL pointed to a M3U or PLS playlist file containing the stream URL (see here).

The first fix will cover most cases, but not all, as already stated. So I'm still considering to implement a more complete and more costly version. However, the cost-value ratio has to be considered too, because my resources are limited.

 

 

 

Greetings. Any update on this? I'm still looking forward to the new beta to check these fixes, or to the next official release. Thanks.