Changing the firmware update process

[Philip Downer]

I have been spending some time today looking at removing the need to
press the Brightness key in order to kick off the Firmware Update
process. I hadn't planned to remove it totally I was thinking of
building in an option to the server settings to disable the need to
press the brightness button, with the default being that the user would
need to press the button still to start the process off.

Could someone from SlimDevices or anyone else confirm if I have
understood this process correctly.

When the SB detects that there is a new version of the firmware
available it sits and waits for the brightness key to be held for a
certain amount of time. This appears to be done in the firmware as the
IR Map file lists the brightness.hold (or is it held) as being dead.
Whats more the server waits for a slimproto frame from the client which
conatins an update request UREQ (on newer models anyway) which I assume
the firmware sends once it has acknowledged that the brightness key has
been held for X seconds.

I'm assuming that in order to bypass this stage I can just push the
image to the squeezebox, completely ignoring the brightness key/UREQ
process. I'm also assuming that I need to block the keypad (infra-red
remote) during this process.

Is there anything that I'm missing out here that I need to be aware of
or do I have it all completely wrong

Regards,
Phil

[dean]

When SlimServer detects that a new firmware image is needed, it
blocks the player UI and displays the upgrade message, telling the
user what to do. This is just UI.

Independently, the firmware looks for 5 seconds of BRIGHTNESS button
IR signal. When it sees this, it goes into firmware update mode and
sends the UREQ message to the server.

The server, upon receiving the UREQ message sends a firmware image to
the player.

This way you can force a re-upgrade of the player firmware at any
time by pressing and holding the BRIGHTNESS button (although this
isn't really that useful.)

So, to change the behavior to allow a server triggered update to
happen a firmware change would need to be made to allow the server to
trigger the upgrade.

I don't think we'll attempt this for the upcoming 6.2 release, but we
should continue to discuss for a subsequent release.

[Philip Downer]

On Fri, 2005-09-23 at 10:49 -0700, dean blackketter wrote:
> So, to change the behavior to allow a server triggered update to
> happen a firmware change would need to be made to allow the server to
> trigger the upgrade.

I was afraid that this may be the case, but I can understand why it was
implemented in this way.

> I don't think we'll attempt this for the upcoming 6.2 release, but we
> should continue to discuss for a subsequent release.

Ok, thats great, I won't bother listing the reasons why I think it
should go in as I'm sure you're already aware of them. Is it worth
submitting a bug/feature request to buzilla so that people can vote on
this as I can't see one already.

Thanks for the quick response.

Phil

[Ben Sandee]

On 9/26/05, Philip Downer <pdowner (AT) centroidal (DOT) com> wrote:
>
>
> Ok, thats great, I won't bother listing the reasons why I think it
> should go in as I'm sure you're already aware of them. Is it worth
> submitting a bug/feature request to buzilla so that people can vote on
> this as I can't see one already.
>

Philip,

I would add your comments to this enhancement request:

http://bugs.slimdevices.com/show_bug.cgi?id=641

Ben

[Philip Downer]

On Mon, 2005-09-26 at 08:40 -0500, Ben Sandee wrote:
> On 9/26/05, Philip Downer <pdowner (AT) centroidal (DOT) com> wrote:
>
> Ok, thats great, I won't bother listing the reasons why I
> think it
> should go in as I'm sure you're already aware of them. Is it
> worth
> submitting a bug/feature request to buzilla so that people can
> vote on
> this as I can't see one already.
> I would add your comments to this enhancement request:
>
> http://bugs.slimdevices.com/show_bug.cgi?id=641

Right, have done so, thanks for pointing this out.

Phil