Basshls stopped playing certain streams

Started by Vaislog,

Reply Print
Go Down Pages1

Ian @ un4seen

#1
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

#2
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

#3
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

#4
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

#5
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

#6
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

Ian @ un4seen

#8
Quote from: VaislogThis 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

#9
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

#10
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

#11
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

#12
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

#13
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

#14
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

#15
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

#16
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.

pm_electro

#18
Same problem still exists with the same server and latest library versions. It is more stable with long streams like this one, but can occur randomly with short ones. Some number of segments is downloaded (always different count) and then stops.
https://cs9-4v4.vkuseraudio.net/s/v1/ac/itavY9e0xUycQ6vmkujR-ZOcv3aggFORsCqBSxkINui5PMpS-XnAYpZJ63YMwZEI7zldDnOBR_c7-MpFFhLNaektUSk3G7pPNhGVHOUCsF9tRCLUkQnkqy2NBKu-0zNT0kyYkrCAkOwmOI8XTplENJ6Vsy7g6E-og68LCvwVm5yoS5M/index.m3u8?siren=1

Ian @ un4seen

#19
That URL seems to be playing fine here. How often does the problem happen, and after playing for how long? Does the BASS_CHANNELINFO "ctype" value = BASS_CTYPE_STREAM_MF (instead of BASS_CTYPE_STREAM_MP3) when the problem happens, as in the original poster's case?

Please also confirm what platform you're running on, and the full version numbers of the BASS and BASSHLS that you're using. If you're running on Windows, and haven't already done so, also try this latest BASS build:

    www.un4seen.com/stuff/bass.zip

pm_electro

#20
It seams like problem is in network connection closing and/or timeouts, not in the stream contents. When i have configured fiddler's AutoResponder to give pre-saved m3u and segments without connecting - problem disappears. Maybe playing from start to end works perfectly, i haven't checked. But if i start the stream and will seek forward 15 seconds every 500 ms - it will stop playing somewhere in the middle.
I'm trying to debug and fix this long standing problem in other people's software written in C# using BASS.NET. It has playing and downloading features from that server implemented with BASS. In latter case it uses download callback and seeks forward using BASS_POS_DECODETO flag. However behavior is the same for normal seek and seek with flag, it will stop at some point.
Windows 10 x64, app is 32-bit because of some other 32-only libraries. BASS and BASSHLS latest, downloaded from site at the time of post.
Maybe i could look at the correct HLS downloader (or player with seek support) implementation with BASS for comparisson.

Ian @ un4seen

#21
Quote from: pm_electroWindows 10 x64, app is 32-bit because of some other 32-only libraries. BASS and BASSHLS latest, downloaded from site at the time of post.

Does that include the BASS build that I posted above? If not, please try that too. If the problem persists, also confirm the stream's BASS_CHANNELINFO "ctype" value when it happens.
Reply Print
Go Up Pages1