getmusicbee.com

Support => Questions => Topic started by: sveakul on June 04, 2020, 07:22:35 PM

Title: Default buffering setting for network streams?
Post by: sveakul on June 04, 2020, 07:22:35 PM
I was wondering what default setting MusicBee uses for buffering network radio streams before starting playback.  Most FLAC streams seem to start inordinately slowly, for example about 12 seconds for http://secure.live-streams.nl/flac.flac (http://secure.live-streams.nl/flac.flac) when the same stream at the same time will start in 2 seconds with the AIMP player.  This is also noticeable on some mp3 streams, as in 14 seconds for http://stream.24dubstep.pl:8010/mp3_best (http://stream.24dubstep.pl:8010/mp3_best) vs. 1 second in AIMP, repeatable at the same time/day.  Output is Wasapi-Exclusive, event.  I would also like to ask if it's possible that this setting be made user-adjustable in 3.4 as buffering already is for files.  Thanks!
Title: Re: Default buffering setting for network streams?
Post by: Steven on June 05, 2020, 12:01:54 AM
it was recently increased to 20 seconds worth of data in the buffering but of course the actual time to load the buffer will depend on the internet connection. There is a setting in BASS to start playback sooner while it is still loading but of course runs the risk of cutting out if set to low
Title: Re: Default buffering setting for network streams?
Post by: sveakul on June 05, 2020, 02:28:49 AM
Thanks Steven, understood.  The setting in BASS you mentioned must be what is allowing the other player I referred to start much earlier, but as you said it then assumes a connection speed/reliability that many users may not have.  If it's not able to be made user-adjustable then better off with a wait and no stuttering for everyone's experience.
Title: Re: Default buffering setting for network streams?
Post by: Steven on June 05, 2020, 08:41:35 AM
try this version:
https://getmusicbee.com/patches/MusicBee33_Patched.zip
Title: Re: Default buffering setting for network streams?
Post by: sveakul on June 05, 2020, 06:51:05 PM
This is MUCH better--delay reduced by half in the two examples I gave;  thanks, Steven!