PDA

View Full Version : 5.2 release candidate w/ firmware v.26 testing summary



Michael Bird
2004-06-23, 10:18
Testing report for 5.2 w/firmware v.26, 6/22 nightly build.

System summary:

Server: Windows Server 2003. The only thing running on it other than the OS
is the SlimServer service.
CPU: 2GHz Intel Celeron.
Memory: 512MB DDR.
System drive: 60GB Maxtor system drive.
Music collection drive: Terabyte raid 5 array with Escalade RAID card and
four Western Digital 250GB drives.
Network: Everything is running wired connections with NetGear
routers/switches.
Slim hardware: 1 Squeezebox and 1 SliMP3
Music collection: Approx 43,000 songs, all are LAME-encoded MP3s.

Here's a summary of my experience with the 6/22 nightly:

Firmware update to Squeezebox: No problems here.

Problem with pausing/unpausing the music: Still having the same problem as
before -- if the Squeezebox is paused for more than 30 seconds or so, when
unpausing it plays what is in the buffer and then stops. Just as a side
note, my SliMP3 does NOT have this problem.

Various performance problems:

When the server first builds the tag database, at the very end of the scan,
it becomes unresponsive for several minutes (seems to vary from about 5 to
20 minutes). I've tried this with the tag db turned on and off, and also
with the "look for artwork" option turned on and off, doesn't seem to make
any difference.

With the tag db caching turned on, about every hour or so of continuous
play, the music stops for about 3-4 seconds, then starts again where it left
off. This does NOT happen with the tag db caching turned off. Very strange.

I have been experiencing both of these problems throughout 5.1.6 and 5.2,
and have reported them previously.

During song title searches, the server almost always becomes unresponsive.
Sometimes it becomes unresponsive during artist and album title searches.
Seems like the database searches should be a lot more efficient, given the
fact that I am running a fairly robust dedicated server. This seems less of
a problem (though it still happens sometimes) with the tag db caching turned
on, but I usually have that turned off because of the above problem.

Nuisance bugs:

When doing a clean install of a nightly (that is, I removed the previous
version and deleted the SlimServer directory to do a fresh install), the
installer program does not save the selected music folder and playlist
folder that I specify during installation. I have to go in to server
settings and set these after the install. This has happened with at least
the last month of nightlies, maybe farther back.

After a clean install, the player settings for the SliMP3 default to a
bitrate limit of 64kbps -- that is, the first item in the dropdown. I
haven't checked the prefs file to see what it shows there, I'm just going by
what the web interface says.

Other problems:

The synchronization between the Squeezebox and the SliMP3 still doesn't work
very well. They often start up a second or more apart. This seemed to be
(mostly) fixed for a while pre-5.1.6, but seems worse now. Would like to see
this working. I only have 1 Squeezebox, so I don't know if that sync works
better.

-Michael Bird

dean
2004-06-23, 16:05
Hi Michael,

Thanks for the report.

On Jun 23, 2004, at 10:18 AM, Michael Bird wrote:
> Problem with pausing/unpausing the music: Still having the same
> problem as
> before -- if the Squeezebox is paused for more than 30 seconds or so,
> when
> unpausing it plays what is in the buffer and then stops. Just as a side
> note, my SliMP3 does NOT have this problem.
Sean's still looking into this. Unfortunately he hasn't been able to
reproduce it here, but he's got a few more things to try.

> When the server first builds the tag database, at the very end of the
> scan,
> it becomes unresponsive for several minutes (seems to vary from about
> 5 to
> 20 minutes). I've tried this with the tag db turned on and off, and
> also
> with the "look for artwork" option turned on and off, doesn't seem to
> make
> any difference.
I haven't seen this problem either, I'm testing for it now.

> With the tag db caching turned on, about every hour or so of continuous
> play, the music stops for about 3-4 seconds, then starts again where
> it left
> off. This does NOT happen with the tag db caching turned off. Very
> strange.
I think I know what's going on here. Every hour the cache is saved to
disk. It looks like it takes enough time on your system to stop the
music. I've filed a bug against this, #402.

> During song title searches, the server almost always becomes
> unresponsive.
> Sometimes it becomes unresponsive during artist and album title
> searches.
> Seems like the database searches should be a lot more efficient, given
> the
> fact that I am running a fairly robust dedicated server. This seems
> less of
> a problem (though it still happens sometimes) with the tag db caching
> turned
> on, but I usually have that turned off because of the above problem.
This is one that has been reported before and I've looked at, but also
have not been able to reproduce. This might be due to the fact that my
test music library only has 11k songs in it.
I'm working on getting a larger test database.

> When doing a clean install of a nightly (that is, I removed the
> previous
> version and deleted the SlimServer directory to do a fresh install),
> the
> installer program does not save the selected music folder and playlist
> folder that I specify during installation. I have to go in to server
> settings and set these after the install. This has happened with at
> least
> the last month of nightlies, maybe farther back.
Vidur is looking into this now.

> After a clean install, the player settings for the SliMP3 default to a
> bitrate limit of 64kbps -- that is, the first item in the dropdown. I
> haven't checked the prefs file to see what it shows there, I'm just
> going by
> what the web interface says.
Ok, thanks. I think that this is a cosmetic issue in the web
interface, it should be doing the right thing while necessary. Vidur
is going to look at this.

> The synchronization between the Squeezebox and the SliMP3 still
> doesn't work
> very well. They often start up a second or more apart. This seemed to
> be
> (mostly) fixed for a while pre-5.1.6, but seems worse now. Would like
> to see
> this working. I only have 1 Squeezebox, so I don't know if that sync
> works
> better.
I'll file a bug against this to look at soon. #403.

Thanks,

dean

Daryle A. Tilroe
2004-06-23, 16:47
dean blackketter wrote:

> On Jun 23, 2004, at 10:18 AM, Michael Bird wrote:
>
>> <Pause bug stuff>
>
> Sean's still looking into this. Unfortunately he hasn't been able to
> reproduce it here, but he's got a few more things to try.

Really? I find it surprising that it cannot be replicated
at slim since there seem to be many of us experiencing it.
Is there anything we can do to help zero in on the common
factor and cause?

--
Daryle A. Tilroe

Jules Taplin
2004-06-23, 17:00
Well... if it helps... I can provide a negative... I definately _DON'T_ see
the problem. And I would have encountered it - I only just worked out that
holding pause down stopped, so I've been a pretty heavy 'pause' user *grin*.


(5x Squeezeboxes... 2 Wired, 3 Wireless, Server on Linux RedHat 9, Around
20k item music library, all music <192Kbit mp3).


At a wild guess... are all the pause affected people Windows users? At least
a couple of them look to be...

-- Jules

----- Original Message -----
From: "Daryle A. Tilroe" <daryle (AT) micralyne (DOT) com>
To: "Slim Devices Discussion" <discuss (AT) lists (DOT) slimdevices.com>
Sent: Thursday, June 24, 2004 12:47 AM
Subject: [slim] 5.2 release candidate w/ firmware v.26 testing summary


> dean blackketter wrote:
>
> > On Jun 23, 2004, at 10:18 AM, Michael Bird wrote:
> >
> >> <Pause bug stuff>
> >
> > Sean's still looking into this. Unfortunately he hasn't been able to
> > reproduce it here, but he's got a few more things to try.
>
> Really? I find it surprising that it cannot be replicated
> at slim since there seem to be many of us experiencing it.
> Is there anything we can do to help zero in on the common
> factor and cause?
>
> --
> Daryle A. Tilroe
>
>

Bill Fenner
2004-06-23, 18:02
On Wed, Jun 23, 2004 at 05:47:43PM -0600, Daryle A. Tilroe wrote:
> dean blackketter wrote:
> >Sean's still looking into this. Unfortunately he hasn't been able to
> >reproduce it here, but he's got a few more things to try.
>
> Really? I find it surprising that it cannot be replicated
> at slim since there seem to be many of us experiencing it.

I suspect that firmware 26 ACKs pure ACKs during zero-window probing;
Linux sends pure ACKs but Windows and FreeBSD send one byte of data.
Either behavior is valid, but my traces show that the squeeze doesn't
ACK FreeBSD's window probes. (I don't have a trace from Linux with
a squeezebox to say for sure what the squeeze does when talking with
Linux.)

Bill

Michel Fombellida
2004-06-24, 09:50
Hi
I am definitely affected by the pause issue and I am indeed on Windows XP.
Michel