Bugzilla – Bug 16275
Rebuffering on 1st track
Last modified: 2011-05-11 14:45:06 UTC
Always Rebuffers on 1st track when selecting a song in an Album and also on Random Song. Music Library consists only of FLAC's Looks like the Touch will start playing the 1st track too soon and rebuffers as its building the playlist, or possibly it starts building the playlist too soon. No problems after the 1st track
I too experience this on every attempt to play from a saved Playlist & frequently from Random Song Play. I tend to get 10s of immediate playback when the Touch will halt with a rebuffering message. Sometimes it recovers from this & sometimes it doesn't & it appears to be completely random as to where reply will commence. I have approx 17k tracks, 12k FLAC & 5k MP3. Album art (300 x 300) exists in every album folder & is also embedded in each track with MP3Tag. My first attempt was with a Seagate FreeAgent 750GB mains powered disk containing other files. I have also tried a Samsung S2 640GB USB powered drive with only the music files & experienced the same results. Firmware is released 7.5.0. An attempt to try 7.5.1 resulted in the disk format not being recognised. This error occurred with the Samsung formatted both as FAT32 & NTFS.
Also, if I select more '+' on a highlighted Album and select Play, there is no rebuffering issue. It takes a little longer for the 1st track to play as opposed to selecting the 1st track and then select, so lt looks like the building of the playlist is causing the problem 7.5.1 r8826
QA to have a look for an upcoming 7.5.x release
(In reply to comment #3) > QA to have a look for an upcoming 7.5.x release This should be a simple fix. When selecting a Random Song Mix, TinySC is starting Play on the 1st track immediately, causing re-buffering as it adds the 10 additional tracks to the playlist. All that is needed is a pause of a few seconds to resolve this bug. Is there possibly a delay setting in /etc/squeezecenter/prefs/server.prefs that I can adjust via ssh?
*** This bug has been confirmed by popular vote. ***
Hi - have been helping a friend and have run into the same problem. Netgear ReadyNas DUO Sqeezebox Server 7.5.2 Touch w/ latest firmware ZyXEL P2602HWT wireless router with LAN Ipad as remote Audio: 90% in Flac images compressed at level 5, with embedded and/or external cue sheets. Some in higher "resolution". Some in separate files. An occasional Wav, APE and mp3. Problem is buffering. The music starts playing a few seconds, then stops to buffer - then continues. Pretty annoying. Tried to wire the Touch - same problem there. Tried to change the server setting to decode FLAC on server passing PCM to the touch, same problem.
We have a hardcoded value for how long to delay playback to account for initial buffering, I wonder if we should make this a pref so people can increase it if they need it.
Same issue here. Harddrive connected via USB to Squeezebox. Latest firmware installaed in SB.
Let's look to see how much we can do in this area for 7.6. There is no certain way of solving this problem because, if the server becomes unresponsive, the player will eventually run out of data to play. There have already been a number of recent improvements.
== Auto-comment from SVN commit #9297 to the jive repo by ayoung == == http://svn.slimdevices.com/jive?view=revision&revision=9297 == bug 16275: Rebuffering on 1st track For lossless formats (FLAC, ALAC, PCM), if the buffer threshold is set to the default of 255KiB then increase this to 1MB. This may result in increased startup latency in the case of slow networks but that is preferable to stuttering after startup. 1MB should give about 10s of buffered data for FLAC at 44100/16/2 and perhaps 4s for 96000/24/2.
== Auto-comment from SVN commit #31810 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31810 == bug 16275: Rebuffering on 1st track
SBS 7.6.0 (32396), SB Touch 7.6.0 (R9430) Not seeing a re-buffering message nor has the song played, then skipped back to the beginning and started over.