Topic: BASS_StreamCreateURL BASS_ERROR_TIMEOUT after several days

[fmcoder]

I'm getting a weird BASS_ERROR_TIMEOUT from BASS_StreamCreateURL after a while, typically 3-7 or a bit more days of continuous operation. The software works like this: connect to the stream with BASS_StreamCreateURL; play it; if the stream disconnects for some reason, reconnect. It works like this, but eventually the connection is no longer possible due to BASS_ERROR_TIMEOUT error.

Other programs are able to play this stream on the same computer. If the long-running program is restarted, it's also able to play the stream again. The error stops from happening if the network interface is reset e.g. turn OpenVPN on/off, then error no longer occurs for several days - in this case, the long-running program plays the stream again, no more error 40.

Stream is from Icecast KH server in MP3 format.

Using the latest version of BASS and other bass* libraries.

What could that be, and how can be fixed?

[Ian @ un4seen]

That sounds strange. A few questions to perhaps narrow it down... What BASS_CONFIG_NET_TIMEOUT setting are you using and does it still timeout even if you raise that? Is it only happening with a particular URL/server, or are all URLs affected once the problem begins, ie. all BASS_StreamCreateURL calls timeout regardless of the URL? Does it only happen when using a VPN? What platform are you running BASS on? If you can, please also try on another platform to check whether it's something platform-specific.

[fmcoder]

BASS_CONFIG_NET_TIMEOUT is not changed, so I guess it's the default 5000 ms. Only tested it with one URL for now (it points to Icecast's m3u link); will try with a different URLs soon when I see this again. Platform is Windows, happens with both 32 and 64 bit software builds, software runs on Windows only. VPN is never used during those tests, only when I see that it's already failed, I turn it on/off and see that it BASS_StreamCreateURL doesn't fail anymore (perhaps turning network adapter on/off will have the same effect).

Software sets the following BASS_CONFIG_NET_* options as follows:
BASS_CONFIG_NET_PLAYLIST = 1
BASS_CONFIG_NET_PREBUF = 0
BASS_CONFIG_NET_BUFFER = 5000
BASS_CONFIG_NET_READTIMEOUT = 10000
BASS_CONFIG_NET_AGENT = set to a custom string
BASS_CONFIG_NET_PROXY = NULL

The stream is created with the following flags:
BASS_STREAM_STATUS | BASS_STREAM_BLOCK | BASS_UNICODE | BASS_STREAM_DECODE | BASS_SAMPLE_FLOAT

[Chris]

Hi,
the latest (master) Icecast KH Release (2.4.0 - KH 14) have a known Bug of that.
the 2.4.0 KH 15 have a fix of that.
Here a link for the fix Release
https://github.com/karlheyes/icecast-kh/releases/tag/icecast-2.4.0-kh15

[fmcoder]

It's already KH 15 version, and still happens.

[Ian @ un4seen]

Only tested it with one URL for now (it points to Icecast's m3u link); will try with a different URLs soon when I see this again.

Next time it happens, please also try capturing the network traffic with Wireshark to see what's being sent and received for the URL request.

[fmcoder]

Happened again. Tried changing the URL, the connection still fails with code 40. Other programs (including the ones that use BASS_StreamCreateURL) are able to play any of the tested streams. The two apps that were used for the tests have failed at about the same time - both were started at the same time, and failed after about 3 days.

Attached Wireshark log.

[fmcoder]

Another update on this: after a while (several hours) this error disappears and it's able to connect again with no error. Weird.

[Ian @ un4seen]

Weird indeed. Assuming it was capturing the correct network interface, your Wireshark capture seems to show that no requests were even sent out. To see if it may be related to something system-specific (perhaps some firewall running on it?), can you try to reproduce the problem on another PC?

I don't recall any recent changes that I would expect to affect this (then again we don't know what's causing it), but you could also give this latest build a try:

   www.un4seen.com/stuff/bass.zip

[fmcoder]

It actually tries to connect - the red TCP Retransmission entries appear when it calls BASS_StreamCreateURL. I've sent you (via emal) another capture made at the same time, but from another program that successfully called BASS_StreamCreateURL and was able to play the stream. There, the Retransmission entries are green, and then the stream data goes.

I could think that it may be something to do with the router, but why only certain software is affected? Same URL, same software but one can connect and other don't.

I have it running on another computers and the bug didn't yet appear there, but it doesn't yet mean anything as it can take days before the bug shows itself

[Ian @ un4seen]

It actually tries to connect - the red TCP Retransmission entries appear when it calls BASS_StreamCreateURL.

Are you sure they're related? They're being sent to a private IP (10.0.0.1). Maybe that's the VPN?

[fmcoder]

The VPN was turned off during the whole test so that's something else.