PDA

View Full Version : Bug 1181: firmware upgrade & squeezenetwork



fry
2005-10-27, 06:45
This is my first post to the forum and I should say that I'm delighted with the SB2. Couldn't wait for it once I decided to buy. Excellent product despite the minor occasional hiccups.

Here's an interesting problem related to bug 1181(firmware) and maybe others(server). I didn't add a comment to bug 1181 for exactly this reason.

The facts:
I recently bought a new SB2 wireless.
I use the SB2 w a range extender - the signal strength varies between 86-88%.
The firewall is well configured - the symptoms below are the same w or wo the sw firewall. When I upgraded the server the rules were manually updated by me to point to the new executable - which is point moot since I can shut it down for the duration of the test.

What's OK:
The SB2 and slimserver 6.1.1 work together flawlessly.
This server apparently has a different version of the firmware than the one required for squeezenetwork. SB2 shows it as being ver 15. Worked OK for a day, and yesterday(Oct 26, 2005) it asked for an upgrade while connected to squeezenetwork.

What's NOT:
Slimserver 6.2/6.2.1(nightly) are unusable as they are - at least for me (Win XP SP1). 6.2.1 didn't install the service (didn't check why). 6.2.0 installs fine, the service starts nicely but SB2 & the server can't find each other.

Why did I upgrade *8-)
An upgrade is performed every time I switch between slimserver & squeezenetwork.
Squeezenetwork's firmware version is shown by SB2 as ver 26. However, once that upgrade is made, the brightness is fixed (to dimmest setting) and cannot be adjusted while connected to squeezenetwork. Also, more apparent while changing the volume, the screen flickers and looks unstable.
The player can connect and play the radiostations MOST of the time.
Sometimes after an attempt to connect to squeezenetwork it will:
- shutdown before reporting a succesful connection. Power button (remote) needed to restart & restarts as connected w dim display
OR
- it says it can't connect
The above is true w 6.1.1 & 6.2.0 server versions with & without the firewall.

What would be nice:
I would like to be able to cancel the attempt to connect at least rather than be forced to upgrade.
(bug 1181) squeezenetwork should accept different firmware versions; the reason being that a defect in the current server version will make this resurface.
In the near future I plan to use the slimserver on a FreeBSD box and the latest version may or may not work on that platform - maybe I'll have to stick to the ports version. The ability to run the server on smth other than Windows was a deciding factor in buying this particular hardware so this is important for me.

TIA,
Fry

Maditude
2005-10-27, 23:24
> This server apparently has a different version of the firmware
> than the one required for squeezenetwork. SB2 shows it as being
> ver 15. Worked OK for a day, and yesterday(Oct 26, 2005) it
> asked for an upgrade while connected to squeezenetwork.

Yah, I (accidentally) got into the SqueezeNetwork menu on one of my sb2's, and HAD to go through a bunch of crap with upgrading the sb2 firmware (and waiting and waiting, it took a good five minutes before the sb2 started responding to the remote). Got out of it as soon as I could (and had to downgrade the firmware, at least that didn't take so long, but it did make me step through ALL of the wireless network config [wpa, etc...]
I found it quite annoying.

> What's NOT:
> Slimserver 6.2/6.2.1(nightly) are unusable as they are - at
> least for me (Win XP SP1). 6.2.1 didn't install the service
> (didn't check why). 6.2.0 installs fine, the service starts
> nicely but SB2 & the server can't find each other.

SP1? You really ought to hit windows-update...

> What would be nice:
> I would like to be able to cancel the attempt to connect at
> least rather than be forced to upgrade.

Amen to that.

> In the near future I plan to use the slimserver on a FreeBSD
> box and the latest version may or may not work on that platform
> - maybe I'll have to stick to the ports version. The ability to
> run the server on smth other than Windows was a deciding factor
> in buying this particular hardware so this is important for me.

Slimserver works fine on FreeBSD. I started out with the downloadable .tar.gz files from slimdevices.com's website, but have since switched to the ports version. The ports version tracks the major releases in a timely fashion. The nice thing about the ports collection is you just do the usual 'make; make install', then add a line 'slimserver_enable="YES"' to your rc.conf, and you're done. Simpler than a windows install! :-P

mikelis
2005-10-28, 06:47
about a week after i got my new SB2, the sqeeze network asks me every time i connect to upgrade my firmware. i go through the process and the sb2 reboots but next time it asks me again to upgrade. mthis is annoying. sb2 remains at level 15 and never actually seems to update. i'm running 6.1.1 of the slimserver software.

james

fry
2005-10-28, 06:49
> Yah, I (accidentally) got into the SqueezeNetwork menu
...
> I found it quite annoying.
I didn't have to go through the network setup again but I did check the settings just to make sure.
And since it's my first SB I played around and hit this twice more just hoping a fix is available. I think I'll wait for the cancel option before I try it again.

> SP1?...
True, but it's just a test machine - I won't use it as a server.
It just so happened that my freeBSD machines are being upgraded w reconfigured hw and I didn't finish yet. But I didn't let that stop me ;-)

>... but have since switched to the ports version. The ports
> version tracks the major releases in a timely fashion.
I was wondering about that and I was tempted to get the files from here.

> The nice thing about the ports collection is you just do the
> usual 'make; make install', then add a line
> 'slimserver_enable="YES"' to your rc.conf, and you're done.
Makes it all worthwhile, isn't it?

> Simpler than a windows install! :-P
Ha! Almost anything is simpler in the end than trying to keep windows in a usable state for long.

Just for the sake of completeness I should also point out that the installation doesn't leave the service in a startable state.
I had to explicitly change it to log on as myself instead of the default Local System account (6.1.1 & 6.2.0)

Maditude
2005-10-28, 07:31
> Just for the sake of completeness I should also point out that
> the installation doesn't leave the service in a startable state.
> I had to explicitly change it to log on as myself instead of the
> default Local System account (6.1.1 & 6.2.0)

I've written a number of "service" programs for win32 (for work) and, if you want to be able to write to anywhere other than the EventLog, you pretty much need to have them "log on" as a particular user. Have never messed with the InstallShield side of things, but the guy here who does, says it's not something that can be automated.