Topic: Basshls stopped playing certain streams

[Vaislog]

On the site where I get links to the streams, some new species appeared that the basshls cannot reproduce. Such streams have ?siren=1 at the end and I don't understand what to do with it. The key looks encrypted, although the same ffmpeg downloads such tracks without any problems.
Examples:

https://cs9-1v4.vkuseraudio.net/s/v1/ac/TUFpJsp04oENCbz3QuVxQceJZj9Cd0sQOJc0rCsgvHQHGvoDLusIM0ibJa7wcZN0on2VIhHAHygIqI-cumPRKjEnIhU6yeUTi16Q7Nq78GiKvF7KQXAYFUiFqnDg5thQIqg-qUz8nsNpoAzA8N6RYdbtzsHd4-R3udrFKqNp_dR5W9A/index.m3u8?siren=1

https://cs9-1v4.vkuseraudio.net/s/v1/ac/IxiOVk7S3H-xkXjHKC9deuz8HpJqFkV4kLXlui2-gAKuyWOUWXOYLvCN7rVxci1kg7DrIqCWs5L8FXVtTufSXFaaEuTxlM5D0kwu4MCq44P0yABdTJr3CThB_9HX4SunMO7kIY22n45ImiDdBkMYEHK79NtjlHdNEyNCbZEQZ8IZZkg/index.m3u8?siren=1

https://cs9-1v4.vkuseraudio.net/s/v1/ac/HLolr4JkzSit9Z5PJPaIZzh3U_ZcSRGP8P4jj98K3vAQUzqAplmkOWh96qcmFLQbTFWhhG8H4rJRb_YPXNSFOyVKqOs4J0DZOzicvhQI92aiTqPE5jw3GAnDVabE2Coj8u2M1R9bOOb8oR44mON9RlJwnIAUO70LFMiR_q-jo8ADPh0/index.m3u8?siren=1

There are also regular streams that play without problems, for example:
https://cs9-9v4.vkuseraudio.net/s/v1/ac/cBaOgW4zL7ZeRHJwoJm0S5HDsWwOH_x1wEU-8aIlNjhTg-9bQjG6HuYxbP_WERBXqvcH1DieqTBIJTd9D7qm9ZZjB4AokYFXLa_hf42_RG8ALVijlYj7VR0m1Xf_Uquj6lni4kCft2N2KQwpL2KPmKIhJV8Jb9GA9AsFRCy0kDRGfoM/index.m3u8

[Ian @ un4seen]

Those URLs all seem to be playing fine with BASSHLS here. What error code are you getting (from BASS_ErrorGetCode) when you try to open them there? Please also confirm what platform you're running on, and that you're using the latest BASS and BASSHLS versions, in case that's making a difference.

In case you're testing with the NETRADIO example, note the URLs won't work with that currently due to their length, but that can be fixed by increasing the size of the "temp" array used to hold custom URLs.

[Vaislog]

There is no error. BASS_ErrorGetCode return 0. There is just noise for a few seconds and then automatic switching to the next one. Here is a video example:
https://drive.google.com/file/d/1N2GkAtsiIrZEDXMGtEqotY0jqKO-KDBQ/view?usp=share_link

I'm using Windows 10 x64 21H1
bass.dll - 2.4.16.7
basshls.dll - 2.4.3.1
Bass.Net.dll - 2.4.14.1

[Ian @ un4seen]

The current BASS version is 2.4.17, so please try upgrading to that. The NETRADIO example has now been updated to support longer custom URLs, so you can also try playing your URLs with the pre-compiled version of that (in C\BIN folder) for comparison.

[Vaislog]

I updated but it didn't fix the issue. NETRADIO also cannot open the stream (error code 2). And it's not radio, it's just tracks with a known length. Previously, there were just mp3 files, but then they were converted to hls

[Ian @ un4seen]

The NETRADIO example can also stream files from the internet (by entering the URL in the "Custom" box), so that isn't a problem. Make sure you have BASSHLS.DLL (and BASS.DLL) alongside the NETRADIO.EXE file. The URLs in the first post are all still playing fine here today. Are they not there? If you're having the problem with a different URL now then please post that.

[Vaislog]

This is very strange, I took netradio.exe, put the bass.dll and basshls.dll libraries next to it, and the url reproduced without problems. Moreover, after that, these URLs began to play normally in my application. I don't understand how it could be related. But there was another problem. On my PC with Windows 10 everything is working fine now, but on Windows 7 x 64 when I try to play the url data I get error 41(Unsupported file format).Netradio also cannot play url data on windows 7

[Vaislog]

Noticed another oddity. Sometimes the service gives other links to streams that don't work well with basshls.
For example:
https://cs9-1v4.vkuseraudio.net/s/v1/ac/Mbb5akxkXeo1sKt0GUQWmZPEsb1C4DM0kkuHd97ZSnvdte61DmSjeRYr8j8yxYnuagI-poYzSDNm7h3GQQlZURmlkRkuWxWoEhztKhJxVYwZAf2QuKSx8UrY5kxT77waNLVNyn97Jirl1L6SAE13gBFyPUT6jF9kbyoek8lbFsMo9bk/index.m3u8?siren=1
It constantly hangs on buffering and makes the same noise as on the video.
https://drive.google.com/file/d/1FDsp0UzW1FXEtRabMKg8vKKry0s0ZAvu/view?usp=sharing

[Ian @ un4seen]

This is very strange, I took netradio.exe, put the bass.dll and basshls.dll libraries next to it, and the url reproduced without problems. Moreover, after that, these URLs began to play normally in my application. I don't understand how it could be related. But there was another problem. On my PC with Windows 10 everything is working fine now, but on Windows 7 x 64 when I try to play the url data I get error 41(Unsupported file format).Netradio also cannot play url data on windows 7

That sounds strange indeed.

Your latest URL is playing fine here, and it and the others are all playing fine on Windows 7 too. Note the codec used in these HLS streams is MP3, so they should work on all platforms without anything extra besides BASSHLS. When the noise problem happens, what "ctype" value does BASS_ChannelGetInfo report?

[Vaislog]

I think I'm starting to figure out what's going on. Each time the site returns a different URL for streams, and in some cases they are problematic.
I thought that after the launch of the netradio the situation changed, but it turned out that urls was updated.
On problem tracks ctype = BASS_CTYPE_STREAM_MF. If ctype = BASS_CTYPE_STREAM_MP3 then it plays fine.

[Ian @ un4seen]

BASS_CTYPE_STREAM_MF means Media Foundation is being used to decode the data, ie. BASS and add-ons were unable to handle it. If the output is just noise then Media Foundation may have misdetected the data's format and/or it is corrupt, but you can check the BASS_TAG_WAVEFORMAT tag to find out what format Media Foundation did detect, something like this:

Code: [Select]

const WAVEFORMATEX *wf = (const WAVEFORMATEX*)BASS_ChannelGetTags(handle, BASS_TAG_WAVEFORMAT);
WORD format = wf->wFormatTag;

All of the URLs posted in this thread are still sounding fine here, and I've tried them several times now. Should the problem happen with them eventually? If you haven't already done so, please try with another connection (eg. using a VPN) in case the server is doing some geo-targeting.

[Vaislog]

I tested for several days in a row constantly updating the urls and the problem did not appear again. Moreover, even the "?siren=1" disappeared from the urls. Perhaps the site is experimenting with new types or there was some kind of failure. I will continue to see if this issue reappears.

Thanks for the help! If the problem shows up again, I'll see what kind of MF format I get

[Vaislog]

Greetings! The problem is back. Unfortunately, it was not possible to look at BASS_TAG_WAVEFORMAT, when I try I get Overflow Exception. One way or another, I found an interesting feature. If I remove ?siren=1 from the end of the URL, then everything plays without problems, and the stream is no longer considered as BASS_CTYPE_STREAM_MF.
Simple url:
https://cs9-6v4.vkuseraudio.net/s/v1/ac/IKKohkU3mpMnX8FoDQfryXFdjZ3EL9iQI-iXw15lyp8g9LG_lUgimM5hu6agjVh4jzsvIQWlgwr__6eYpMIKrLSC3DiX_rMz6-bzzS9OhwhMW3A0oufjFjh57IDKOCXcUqSdp5Pr9v5N6J07138PfsItsXQiYGuAzHHIw6DXPbGehCU/index.m3u8?siren=1

[Ian @ un4seen]

That URL seems to be playing fine here right now on Windows 10 and 7, with and without the "?siren=1" part. Is it always failing there or only sometimes, and can you reproduce it with the pre-compiled NETRADIO.EXE example?

Regarding the Overflow Exception when checking BASS_TAG_WAVEFORMAT, please show the code you're using for that.

[Vaislog]

Yes, the problem is permanent, but not with all URLs. For example, the url that I gave before now works both with "?siren=1" and without it. Yes, I can reproduce it on NETRADIO, I attach the video and the link that I used for tests.
Link: https://cs9-22v4.vkuseraudio.net/s/v1/ac/8a1dZbEU259KxM6HbCTGRfVstMZdzMLEQVUJYlZJOhGj18p3WbIgpfw2RYD1Mg0_w9KynRALSPz53nnX6PsYrjCwMc6p_xyJu0Ec5IF_MQS3Worps8GGxzRy4GBfkzb3U7VHE344ZeBofqfQTBB03QfjzmBRJDMkmJZGFPmhmyvs9xk/index.m3u8?siren=1
Video: https://drive.google.com/file/d/1NGxNAGwCH5eQTyKHFmYOjJjKQ3Fy8Z-_/view?usp=share_link


At the expense of the code, I had an error there, so I got an exception. At the moment, I get just "P" in the tags. Maybe I'm doing something wrong, I'm attaching the code and the result in the debugger.
Code: https://drive.google.com/file/d/1geIbZnVldeDIvpaCEuGV8H7pjRRz4rC5/view?usp=share_link
Debugger: https://drive.google.com/file/d/1N_au0aL_tfb6K7FbWHocwoSZeNCTg7zq/view?usp=share_link

[Ian @ un4seen]

Oh yes, I can reproduce the problem with that URL. It's caused by the encrypted media segments having some junk before the MPEG-TS data, which BASSHLS isn't currently expecting. I'll look into having it skip junk and then come back with an update for you to try.

Regarding the BASS_TAG_WAVEFORMAT crash, please note that tag isn't a string but rather a pointer to a WAVEFORMATEX structure:

   https://learn.microsoft.com/en-us/windows/win32/api/mmeapi/ns-mmeapi-waveformatex

[Ian @ un4seen]

Here's the BASSHLS update for you to try:

   www.un4seen.com/stuff/basshls.zip

Let me know if you still see the problem happening with any URLs.

[Vaislog]

Thank you very much! It works great now!