On the Config, BASS.DLL, Performance tab, there are two network timeout figures: CONNECTION and READ.
Can you please check/correct my understanding of these?
CONNECTION timeout: time after which the network connection is assumed ‘dead.’
READ timeout: time after which mAirList ‘gives up’ trying to read a network file, and assumes that the file is ‘unreadable.’
Are those descriptions above correct?
And if the descriptions are correct, why does the CONNECTION timeout default to 5 seconds, while the READ timeout defaults to a little over nine HOURS? ??? I would expect the ‘read a file’ timeout period to be less than the ‘the network has died’ timeout period. ???
I’m sure that either the READ default timeout is not intended to be 32767 ::), or I am not understanding these values correctly! :-\
CONNECTION timeout (BASS_CONFIG_NET_TIMEOUT): The time to wait for a server to respond to a connection request. The default timeout is 5 seconds (5000 milliseconds).
READ timeout (BASS_CONFIG_NET_READTIMEOUT): The time to wait for a server to deliver more data for an internet stream. The default setting is 0, no timeout.
Both options are specified in milliseconds internally (as well as in the bass.ini file), but displayed in seconds in the config dialog, because the spinner control supports only values up to 32767, which might be too small.
The BASS_CONFIG_NET_READTIMEOUT option is only supported by BASS 2.4.7.0 and above, which will be shipped with mAirList from v3.1.5. Apparently, the older BASS versions (like 2.4.6.0, shipped with mAirList 3.1.4) return an “invalid” value when trying to read the current setting (-1, as an unsigned 32-bit integer, 0xFFFFFFFF, which is then capped to 32767).
I have placed a copy of the new bass.dll into the snapshot folder. Please download it, set the timeout setting back to something reasonable, and everything will be fine.
So, just to be clear, do one/both of these settings apply to (say) playing out an MP3 file which is stored elsewhere, or do they only apply to streaming things like encoders?
Sorry if I’m being unusually thick, but as you know I don’t do streaming nor networks really!
It applies to either of those. Because it’s basically the same technique. An MP3 internet stream is nothing but an MP3 file, with unlimited length, retrieved by HTTP.
The read timeout is a convenient way to detect stalled internet streams, that is, when the server does not send any data anymore. This is a common scenario with Shoucast-based streams. When a streaming source disconnects, the server does not send any data to the conntected listeners, but does immediately not drop the connection to them, but waits for a new source to connect. Likewise, a mAirList player instance connected to the server will sit and wait for more data. With the read timeout, you can make mAirList consider the stream ended after a particular time.
As far as I know, the settings also apply to the streaming (source) components from BASSenc. For example, the read timeout is used when the current number of listeners is retrieved using an HTTP call. Some people in Germany suffered from the automatic disconnect T-Online does every night - when that happened during one of those HTTP calls, the encoder would freeze, because Windows never reported the connection as closed. The read timeout cures this problem.
Suppose I have NO streaming whatever, just audio files.
Suppose that some of those audio files are stored on a disk on a different PC on a local LAN.
Suppose I put one of those files in my mAirList playist.
Are you saying that these network timeouts apply to playing that file? Even though no Internet is involved anywhere?
If so, I don’t understand the description you gave for Read timeout, because it specifically mentions Internet streams.
I think I’ll go and lie down now: my brain hurts! :’(
Oh, sorry… It only applies to files (or streams, which are virtual files) retrieved via HTTP or FTP. Files from Windows network shares are not affected.
