I have also experienced this behavior with FLAC q6 24/96 files on SBS 7.5.2.  Only on the first track.  Typically if I "rewind" to start of track it plays fine the second time.  No artwork in files; covers are in folders.

Server is dual-core Atom with 2GB RAM running Win XP SP3.  Server is wired; Touch is wireless with 100% signal strength.

Apesbrain The 24/96 bug is here:
https://bugs-archive.lyrion.org/show_bug.cgi?id=15361

But as it's now happening to normal 16/44.1 It's a more serious problem .
So I opened a new bug.

But I forget the most important info:

Player Model: Squeezebox Touch
Firmware: 7.6.0-r9257
Player IP Address: 192.168.1.15
Player MAC Address: 00:04:20:22:26:dd

Streaming FLAC as WAV does not help ?

Noticable the server peaks at 100% CPU each time I choose a new album to play ?

*** This bug has been confirmed by popular vote. ***

Compared two things cueing up an album on a boom with it's own ui hardly makes dent in the cpu usage.

Using my controller to start a new album on my Touch makes sbs to peg the cpu for 2-5 seconds.

Sometimes if you are quick on the controller if you switch to the NP screen before it's populated you can hear that the music stops exactly when the NP screen gets populated with the playlist.

Using the web-ui increase the risk for drop-out btw .

My server has 1,2gHz via-epia cpu and 1GB of RAM .

Must emphasize that all was ok a month ago !!

It was also good with 7.5 and MySQL wich in theory should use more resources than the current server ?

It also runs fine on slower machines than mine.

Remember that we have 2 different bugs here , when the Touch was introduced 16/44.1 flac worked fine but 24/96 did not .

https://bugs-archive.lyrion.org/show_bug.cgi?id=15361

But they fixed that in 7.5.1 (but this is also broken again).

But now it is broken in normal 16/44.1 files to , but in a slightly different way it does not always happen, and i can see no pattern to which files is going to trigger this. only this it is more likely in hirez files.

And this is the new bug for when it happens on "normal" low-rez files with 7.6

https://bugs-archive.lyrion.org/show_bug.cgi?id=16750 .

This time the issues is not slow processing in the Touch it actually buffers, it's quite the opposite the server seems to be very busy.

This can be all because of image resizing ?

Wich is very very wierd as a have image precaching on during scan, but still sbs resize img for the UI's 

Can explain why some albums are fine as they are still in cache.
I'll try to catch when it fails.

This exampoe worked fine it only took 0,25s

Example:

[11-01-06 19:43:45.5125] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/4e4c5b92/cover_190x190_m
[11-01-06 19:43:45.5155] Slim::Web::Graphics::artworkRequest (122)   Resize specification: 190x190_m
[11-01-06 19:43:45.5237] Slim::Web::Graphics::artworkRequest (272)   Resizing: /media/music/music2/womad/Long Walk Home - Peter Gabriel/A_Sense_Of_Home.flac using spec 190x190_m
[11-01-06 19:43:45.6134] Slim::Web::Graphics::_cached (68)   from cache: jpg (12271 bytes for music/4e4c5b92/cover_190x190_m)
[11-01-06 19:43:45.6784] Slim::Web::Graphics::artworkRequest (83) Artwork request: music/4e4c5b92/cover_240x240_m
[11-01-06 19:43:45.6808] Slim::Web::Graphics::artworkRequest (122)   Resize specification: 240x240_m
[11-01-06 19:43:45.6861] Slim::Web::Graphics::artworkRequest (272)   Resizing: /media/music/music2/womad/Long Walk Home - Peter Gabriel/A_Sense_Of_Home.flac using spec 240x240_m
[11-01-06 19:43:45.7626] Slim::Web::Graphics::_cached (68)   from cache: jpg (17283 bytes for music/4e4c5b92/cover_240x240_m)

Is pre caching broken ?

It goes out and fetch the image in the file ?

But it may not be my problem ,even if it is a problem

[11-01-06 20:04:11.3098] Slim::Schema::Track::coverArt (395) Retrieving artwork for: file:///media/music/music2/Bamse/Cultivated%20Bimbo/Cultivated%20Bimbo%20(1993)%20Blasting%20in%20Progress/01%20-%20Ten%20Seconds%20To%20Crazy.flac
[11-01-06 20:04:11.3116] Slim::Music::Artwork::_readCoverArtTags (237) Looking for a cover art image in the tags of: [/media/music/music2/Bamse/Cultivated Bimbo/Cultivated Bimbo (1993) Blasting in Progress/01 - Ten Seconds To Crazy.flac]
[11-01-06 20:04:11.3291] Slim::Music::Artwork::_readCoverArtTags (254) Found image of length [12456] bytes with type: [image/jpeg]

Two(or more) image sizes are not pre cached at all ?

190*190_m & 240*240_m

Artwork.pm

I did an uggly hack in Artwork.pm and added those cleared and rescanned the whole dB .

And hey it worked :P for standard rez Flac !

Drop out frequency is 1/100 instead of 1/3 of the time .

So it's not a complete solution only an improvement.

I figured that at least 190*190 is used by the Touch.

All using the latest since build server came back.

I use this tread to talk with myself about the problem.

http://forums.slimdevices.com/showthread.php?t=83662

But here are other user with similar issue popping up hera and there running 7.5.x especially on the Touch itself.

I did some experiments with the artwork caching it had reduced the problem but it is not gone.

However I don't experience the problem if I use the Touch's own interface .

For normal CD quality flac I can reproduce it this way . Control your Touch with a controller .

makes sure both Touch and Controller is showing the NP screen with artwork .
also be sure that controller behaves such as it pops back to NP when you start a new album.

Now goto albums and choose something press > play at the album.

If the problem is going to apear it is in the exact moment when both Touch and controller should show artwork, they usually get their art simultaneously.

So art appears Touch buffer for 0,5 sec playback resumes
Server is resizing artwork at that stage according to logs

Therefore i made experiments with caching more art, this can happen even if all art is in cache but it is a much rarer thing.

Ok I did an experiment in bug 15361 that worked well:

In file /usr/share/jive/jive/audio/Playback.lua 

On the Touch i changed (line 342 in latest 7.6)

From

"
-- We can begin decoding with 2K of data
	local decodeThreshold = 2048
"

To this:

"
-- We can begin decoding with 2K of data
	local decodeThreshold = 2097152
"

This is 2048K of data ? (2048*1024=2097152)

It works for me .
Tried a lot of different albums all cued up with my controller.
Maybe this is completely wrong sux and works by coincident ? Half this value does not remove the problem double it and the player goes silent.
I only tried multiples of 1024 must be a reason for it.

This may be relevant to 16275

My fix makes it stop in a playlist if the song is really short 19 seconds , I can live with that until a better fix appears.

See my proposed patch on bug 15361

Mikael, what is the latest status after the other recent performance fixes?

(In reply to comment #14)
> Mikael, what is the latest status after the other recent performance fixes?

It's excellent ! thankyou. I have never had as good performance as it is now.

I can cue up all my 1500 24/96 files or a 3000 track normal playlist and no stutter even if i shuffle and that with the small buffer before your proposed change .

Cueing up a 3000 track list still takes 10-20 seconds but it works anyway*.
I deem a 4000 tracks playlists manageable on the via-epia 1,2Ghz cpu

With you proposed change you have some insurance for the most slugish NAS boxes and *cough* the built in server in Touch :)

Also the high performance setting to use more memory for SQlite is conservative ?
I never seen SBS use much memory even with that set.

Best regards.
Mikael

*maybe rethink pl handling some people juggle >10000 track pl on their ipods and are not entirely impressed with a 100 track limit :P (or 500 tracks).

Unable to reproduce

Using SB Radio (7.6.0 r9432) and SBS (7.6.0, 32398), I am unable to reproduce this issue on FLAC 24/96 tracks.  Will close.

Also, reported fixed in the forum thread:
http://forums.slimdevices.com/showthread.php?t=83662&page=3