(Sorry if this has been covered before, but the forum search appears to have broken just as I was trying to look for this one, and I'm suffering from patience buffer overflow...)

My tests to try and remove some nasty clicks at the start of certain mp3 files are being made much harder by the fact that more often than not my browser is starting to continually refresh the playlist window, which makes it impossible to navigate, and starts to eat up CPU as well. (Browser is IE7, though I've seen it in Firefox too; skin is fishbone, virtually mandatory as I need to do "play next" a lot. SlimServer 6.5.1, quite an old nightly now.) Only fix so far is to close and restart the browser, then tediously navigate back to my folder of test files.

(Whether I actually need to do this is another matter: if I have a file in my playlist, and I change the tags in the file to see if they're affecting the audio, when I play the file again, will SS re-read the audio data from the changed file? Surely there's no caching of audio data, and so no need to rescan? If I'm wrong, then these tests are about to get EVEN MORE tedious!)

Could it be because while testing I'm only playing a few seconds of each track (to see if the damn click is still there, which so far it is), then pausing?

Usually, I love my SB3, but I get enough hassle with IT in my day job, and do NOT want it at home as well! So on nights like this, I could scream and start breaking things (just like I do at work :-))

-- Brian

Mark Lanctot

2006-11-28, 18:19

(Whether I actually need to do this is another matter: if I have a file in my playlist, and I change the tags in the file to see if they're affecting the audio, when I play the file again, will SS re-read the audio data from the changed file? Surely there's no caching of audio data, and so no need to rescan? If I'm wrong, then these tests are about to get EVEN MORE tedious!)

I would think any changes that could affect the audio will be immediately apparent without a rescan. SlimServer caches the tags but does not cache the audio data. So if you change the file's tags, the cached tag data may not be current, but the audio will come from the current file.

Whether this applies to the "album art is audible as a pop/screech" error I'm not sure, because that bug hasn't been squished yet. It could be a tag problem, in which case when you remove it it should go away. As you say, it isn't going away. Maybe the tag is still there, but just empty now.

Brian Ritchie

2006-12-21, 19:14

Thought I ought to bring some closure to this.
In reverse order:

I reckon that the browser refresh was going mad when I was pausing (not stopping) near the beginning or end of a track. (I'm sure I'm not alone: I'm popping out of the room, and just can't bear to miss part of the next song - and don't yet have a Squeezebox in the loo :-)) I'm trying to get out of the habit (of pausing, I mean :-) - I stop near the start of the next track instead.)

I couldn't work out how to use tag editing to get rid of the clicks I was finding at the start of some tracks; however, last night I installed the most recent nightly, and - yippee! - no more clicks.