My suggestion:
Use the "press and hold LEFT" method to disconnect the player as the POWER
button behavior should not change because of the installed base of thousands of
players. It think it would be easy to getting used to that press hand hold LEFT
disconnects the player.

What is needed is a choice in the disconnected state to turn off the display. An
automatic (either automatically or by a timer) display shutoff could potentially
be confusing when press and hold LEFT is used for setup purposes. The choice for
handling the display shutoff must be handled in the player firmware as the
player is disconnected from the server.

Alternatively a button could be mapped to the following functionality:
1. Make the server turn off the client's display.
2. Disconnect player from network.
In this approach the server is responsible for turning off the player's display,
and I would guess small changes in the firmware is necessary. As stated above I
am not sure if this behavior should be mapped to "press and hold LEFT".

Either way, when in the "disconnected and display off" state, pressing POWER
should turn on the display in the connect to network menu. I am not sure how
easy this is to implement because in this scneario the POWER ON function needs
special treatment if the player is in the "disconnected and display off" state.
May be easier to map the "turn on display and go to connect menu" to the same
button as "disconnect and turn display off" (i.e. a toggle)?

Just some thoughts...

The comment that the behavior of the power button should not be changed due to 
the installed base of thousands makes me think that perhaps I'm being 
misunderstood just a bit.  For all the people that like the way the player 
currently behaves this feature would not change anything.  The default setting 
would be that the power button maintains network activity on power-down.  Only 
if someone actively sought out this menu option and changed it would that 
behavior change.

The idea of mapping a key would be okay.  Ideally I would map the Power key 
and use it as a toggle.  That would be a nice solution.

I really think that my original proposal of a menu option is the best solution 
though.  Microsoft is starting to put more emphasis on sleep modes.  I've seen 
multiple articles over the past few weeks.  Here's one:

http://www.geek.com/news/geeknews/2005Aug/gee20050826032031.htm

One of the other articles was even spouting numbers about the tremendous 
amounts of power that could be saved by people around the world utilizing 
these features.  By putting in this feature the SB2 will have a solution in 
place when many of its users decide to start using the sleep modes in Windows.

This is the first time I've used this bugzilla thing so if there is something 
I need to do please let me know.  How do I find out if this is actually going 
to get fixed?

Thanks for your time.

Brad

If the disconnect could be tripped from software, the button would not have to
be hard coded in firmaware.  All the server needs is a CLI command, and users
can edit the Default.map file to make use of it from ANY button, or modified
button (hold, hold_release, etc)

Agreed, the  client currently lacks the ability to be disconnected from the server and stay in setup.  A 
button map would work, as would a screensaver that disconnected.  I'll see about adding that 
capability, then the screensaver or button action should be trivial.

not going to make it in 6.2.

*** Bug 2476 has been marked as a duplicate of this bug. ***

Glad to see comments and activity on this.  I also agree that default mode should not be altered.  

It would also be helpful, in addition to the power button optionally stoping network activity, to have the option to set a variable delay after playlist completion that once expended, network activity would be halted.  i.e.  if I cue up some tunes to doze-off to; once the playlist is finished, the squeezebox would countdown then go to sleep and allow the server to do the same. 

Doug Frazee

It would be really nice if this kind of functionality could be realized in one of the releases in the near future.
Just installed the SB3 today and the first thing I noticed, after ofcourse playing some great music, is that the server won't go into standby because the SB3 is generating networktrafic even when it is off and no plugin is loaded for the screen (time-date for example).
The workaround of putting the SP3 in setup mode does work, but is quite anoying.

Regards,
Olaf.

Like Olaf I am a new SB3 user and agree 100% with the comments. Home users typically do not run their servers 7/24. Mine sleeps in S3 standby state (no fans) most of the time. 

I have a temporary work around. I power my SB3 off the stereo amplifier back panel. When I turn off the amplifier it cuts the AC to SB3. Not elegant but it works.

A real fix would be appreciated.

Otherwise the SB3 works great... interestingly enough, 192kb ripped AAC files sound better on the SB3 than when I play the original CD on my 15 year old CD player - same amp and speakers. That was an unexpected surprise and might lead to the retirement of the CD player from the living room.

Andrew....

Just wanted to echo the previous comments, really - this is my only serious gripe with the SB at the moment.

BTW, as described in http://forums.slimdevices.com/showthread.php?p=99500#post99500 - anyone who currently finds their (Windows) PC is *no longer* entering Standby, due to the SB network traffic, should probably check that it isn't actually going on/briefly off/on etc - it's probably better to disable Standby entirely, if you don't want to have to unplug the SB from the mains whenever it's not in use.

Interesting that I had the opposite problem (which I fixed with a plugin), in that my PC was going into standby while music was streaming. See https://bugs-archive.lyrion.org/show_bug.cgi?id=2746

If you can prevent Windows from monitoring network traffic for the purpose of preventing standby then maybe this bug isn't an issue at all.  Of course.. it depends on what else you use your server for.

BTW.. Which are the BIOS or Windows settings that let windows monitor network traffic for the purposes of preventing standby?  My network traffic does not prevent standby.

(In reply to comment #11)
> Interesting that I had the opposite problem (which I fixed with a plugin), in
> that my PC was going into standby while music was streaming. See
> https://bugs-archive.lyrion.org/show_bug.cgi?id=2746

Good work on sorting that one out :)
 
> If you can prevent Windows from monitoring network traffic for the purpose of
> preventing standby then maybe this bug isn't an issue at all.  Of course.. it
> depends on what else you use your server for.

I'm intending to use the server for more 'general purpose' serving than just SlimServer, so don't think I can always rely on it getting a Magic Packet to wake it up. Incidentally, is it still the case that you need to press Power or Right (while connecting) to get the Squeezebox to do this, or is it now done automatically?
 
> BTW.. Which are the BIOS or Windows settings that let windows monitor network
> traffic for the purposes of preventing standby?  My network traffic does not
> prevent standby.

I just have the Power Management settings of my NIC so that "Allow this device to bring the computer out of Standby" is checked, and "Only allow management stations to bring the computer out of Standby" is *not* checked. AFAIK, the first option means that *any* network activity directed to the PC will wake it up, while the second means that only WOL magic packets will wake it up.

Untargetting for post 6.5 assessment.

This is an important feature, not a nice-to-have.

It is a reasonable and predictable consumer expectation that the power button really does shut something down.
As a very new user, I did not expect my SB to be always on.

I was amazed to find that "off" did not actually mean off where the network was concerned.
(I won't even comment on the silly clock polling method - at least that can be defeated easily)

By generating keep-alives every 2 seconds when "powered off", the SB is not a good network citizen when used on a wireless network.  I've yet to see this aspect mentioned.
One of the primary cracking methods used to penetrate wireless networks is MAC address spoofing.
The SB makes this pretty easy by broadcasting both its own and server addresses 24/7.
Now of course, when in use, the same behavior is displayed, but it is pretty amazing that during the wee hours or when I am on vacation, my SB will still be broadcasting a heartbeat.

Please address. Thanks.

I've voted for this bug (or should i say enhancement request) because
my home network setup relies on a SB3 which doesn't communicate (i.e.
doesn't send network packets) to the windows xp pc which runs slimserver.
Some info on my setup:
- The pc is configured to go into standby after 15min of inactivity
  (which it does when the SB is switched off, but then the SB sends
  a packet and the pc switches on)
- The pc is used also for other purposes like file and printer sharing
  by other windows xp clients (laptop, desktop) and therefore slimserver
  cannot take control of putting the pc into standby.
- As a workaround I have to switch-off the SB and this is not the way
  to use this hightech device.
Since I've confinced my familiy members, which are far to be technology
freaks, to use the SB a very user-friendly solution like just pressing
the power-off button of the SB remote should stop any network activity
from the SB to the slimserver.

Anyway: I love the SB, slimserver is great. Thanks to all people behind
these to gadgets!

Loris

Richard is doing some work that may translate to addressing some of these issues in the 6.5 release.  The rest we will look at for the next release.

As far as I know, a decent ethernet driver & forcing S1 or S0 should bypass that traffic and put it in to sleep anyway.  Have you tried updating your ethernet drivers to see if it helps at all?

There is no issues with putting the pc into S0 or S1. 
This works perfectly. The issue is that the pc doesn't 
remain in S0 or S1 because even when the squeezebox is
switched off it keeps sending some network pakets to the
slimserver and this lets the pc awake from S0 or S1.

I could configure the pc to react/start only when a
magic paket is received, but then all other clients
on the home-network (pcs/laptops of the other family
members) are not able to awake the pc-server by just
trying to communicate with it.

I hope I could make my problem clear, even with my
poor English. Btw, I understand that others have the
same problem as I do.

Thank you
Loris

It looks like the firmware has supported a server side disconnect since squeezebox2/3 firmware v23, but this has never been used by the slimserver. The slimproto command 'dsco' will disconnect the player from the slimserver, and leave the player in the setup menu.

It should be reasonably easy to implement a slimserver plugin to send this command to the player. Patches welcome.

would this be a candidate for an item in Settings? I can patch that easily enough, either as a few lines in the Settings module, or a Plugin that attaches to teh settings menu (more lines of code tho).  other option is to simply create a function in Common and allow users to make their own mapping from a button, or a cli command, etc.

>would this be a candidate for an item in Settings? I can patch that easily
>enough, either as a few lines in the Settings module, or a Plugin that attaches
>to teh settings menu (more lines of code tho).  other option is to simply
>create a function in Common and allow users to make their own mapping from a
>button, or a cli command, etc.

I'm not sure if I understood this right: Do you mean that this item is used 
to (A) disconnect the SqueezeBox from the SlimServer or (B) this itme is used
to configure the behavior of the power-off (red-button) of the remote control.
The behavior can be either "do not disconnect" (which is the way it is right
now) or "do disconnect" (which would be new and allow the pc with SlimServer
to remain in standby or hibernate modus until the SqueezeBox is switsch on
again).
Clearly I prefere (B). 

Not quite:

A) Use remote to go into Settings menu, choose Disconnect from SlimServer, Press RIGHT for a confirmation and Press Play to disconnect (or something to that effect)

B) A command "disconnect" so that users could do their own hack.  In your case, edit Default.map so that power = disconnect, or CLI users could send <playerid> disconnect.

I don't like the idea of having a ui for another preference to alter the way the power on/off works.  That just means one more support question has to be added to the list when users say "my player keeps dropping off". Clearly my overall preference is an item in settings, since it is very deliberate, and isn't something that gets done and forgotten about.

As a user rather than a customer support worker, I would _strongly_ push for option B. 

Having to do four actions when all one wants to do is turn off the SB box and have it disconnect is no better than having to pull the power cable out of the back to make it disconnect.

Its a fair point about this change adding a little to the burden of customer support; but its only one simple question. Most users savvy enough to make the mod would probably quickly remember if prompted so!

See Richard's note that the dsco command will disconnect the player from the server.  that should allow a plugin to be made quite readily.

Also note that pressing and holding the left arrow button for a few seconds will disconnect the player from the server.  

ok, so if this is to be left for third party plugin, should this be marked as wontfix?  Or perhaps this is another candidate for a new type of classification along the lines of "waiting for a Plugin author"

I understand your point of view: you have to consider the impact
on support. And I'm not competet to suggest how the features 
should be implementet. What I want to explain my experience as user.
I bought the SqueezeBox and configured the SlimServer at home. I loved
this duo and all features it offered (RSS, podcast, internet-radio, etc)!
After a while I reduced the menu items on the SB to only "Browse Music"
and since then all family members including my kids (7 and 10years) are
using this duo even more than I do. The< have to power on, browse to whatever
they like and power off. Simple. I would rather prefer to do a hack somewhere
(and probably i need your suppport for doing it ;-) than changing
the user behavior, leave the SB in the setting mode and educating
my family to not misconfigure the SB.
Best regards, Loris

Come on guys; it's been almost a year!  Why not just fix it, option B please

What do the Slim Devices employees define as "disconnect"?  Do you consider pushing and holding the left arrow as "disconnect"?  If so, that is not the behavior I would want.  What I would like is for nothing to be on the screen or perhaps a dim clock so as to not wear out the screen over time (plus it just looks dumb in that setup mode).

Here's a quick summary of workarounds to this issue that people can use today:

1.  Use the Wake On LAN (WOL) feature which will send a "magic packet" to your computer with SS.  This is what I'm using and it works very well.  The only thing that's a minor pain is that I also have a laptop which shares files and printers with the same desktop where SS is installed.  In order for the laptop to wake the computer I had to download a special command line utility and then wrote a batch file so that it would send out a magic packet to my desktop in order to wake it up for a print job.

2.  Plug the SB into your stereo.  Nice and simple!

3.  Before turning off the SB first connect to SqueezeNetwork.  That way when you turn off the player it will maintain network connections with SqueezeNetwork rather than your PC.  This is a pretty good fix, but takes some extra time when you turn it off.

I like KDF's "option B" that was proposed as far as future fixes go.

Subject: Re:  add menu option to stop network activity after pressing OFF


On Aug 24, 2006, at 5:45 AM, Slim Devices Bugzilla wrote:
> What do the Slim Devices employees define as "disconnect"?  Do you  
> consider
> pushing and holding the left arrow as "disconnect"?
Yes.

>   If so, that is not the
> behavior I would want.  What I would like is for nothing to be on  
> the screen or
> perhaps a dim clock so as to not wear out the screen over time  
> (plus it just
> looks dumb in that setup mode).
The screen is unlikely to wear out.  We have units that have been in  
the field for 4 years on (SLIMP3) on the clock with no visible burn- 
in.  This isn't an issue.

> 3.  Before turning off the SB first connect to SqueezeNetwork.   
> That way when
> you turn off the player it will maintain network connections with
> SqueezeNetwork rather than your PC.  This is a pretty good fix, but  
> takes some
> extra time when you turn it off.
That's another excellent way to disconnect from your SlimServer.

>> 3.  Before turning off the SB first connect to SqueezeNetwork.   
>> That way when
>> you turn off the player it will maintain network connections with
>> SqueezeNetwork rather than your PC.  This is a pretty good fix, but  
>> takes some
>> extra time when you turn it off.
>That's another excellent way to disconnect from your SlimServer.

It's only another excellent way to disconnect for people who understand
what the whole technical setup is. But I like the SqueezeBox (not the SlimServer)
to be usable by anybody whow knows to switch on/off a device using a
remote control and understand that music can be organized by artist/album
and tracks. I could tell people (familiy member, but also guests & friends)
to connect reconnect to squeezenetwork. My kids used to do it when the didn't
understand how to use the SB. And often they stopped usind it or I had to
support them when they had to listen to music. 
It is like telling people to change the tv to the extnernal video input
when they don't want to see the normal tv programm. They may do it, but
they don't understand why. They expect to press the power off butten. 
And later the power on when they want to resume watching tv. That's the
behavior I and others expect from the SB.

Best regards, Loris

At the risk of sounding harsh, based on employee comments, SlimDevices user interface design criteria seem to be biased toward developer/support convenience and not end-user expectations.  This is not going to help the growth prospects of your company guys.  Your elegant little device is looking less elegant all the time when you start suggesting users use multiple steps just to shut something off.

Support consequences are irrelevant to me as a customer - don't make your problems mine.  The customers paid a premium price for the box, so if its design costs you money in support questions, well... design a better interface. 

Had I known my ongoing use and enjoyment of this device was going to require a DIY kit mentality, I would have thought twice about its purchase. Off means off, silent, disconnected, period.  The keep-alives should be the option that requires extra steps.

I second the comments about non-technical users not being able/willing to go through extra motions just to shut something down and then turn it back on again.  We live in the age of the IPod, not the reel to reel tape deck.
I wouldn't even try to train my family on such a procedure as the protests and eye-rolling would be too much to endure.

A plug-in to silence network traffic from a device that's supposed to be off?  Emphatically no thank you.

As someone else said, just fix it. 
No user hacks, no config files, just default off behavior in the firmware like the other 100 devices in my home.

This is a developer tool.  Not all developers are employees.  There has to be some place where developers can talk freely without being stomped with "but I'm the customer and I don't want to hear about develoepr problems".  Don't like it, please do not use this tool as a forum.

Please, consider my suggestions off the table.  I am choosing to have nothing more to do with this issue as I have many other things to do, including my real day job.

Subject: Re:  add menu option to stop network activity after pressing OFF


On Aug 24, 2006, at 9:52 AM, Slim Devices Bugzilla wrote:
> At the risk of sounding harsh, based on employee comments,  
> SlimDevices user
> interface design criteria seem to be biased toward developer/support
> convenience and not end-user expectations.
That's not it at all.  The truth is that the vast majority of  
customers are happy with the always connected behavior of the  
product, it's fundamental to how it works.  We recently did add  
support for Wake-on-LAN to answer the needs of a small but vocal  
group of customers.

> This is not going to help the
> growth prospects of your company guys.  Your elegant little device  
> is looking
> less elegant all the time when you start suggesting users use  
> multiple steps
> just to shut something off.
The real question is what is "off".  The player is an always- 
connected device, capable of displaying a clock or other screensaver  
when "off".  This requires the computing power of the host computer.

Unfortunately for some folks, Window's idea of what constitutes  
network activity is a little broken.  We need to be very careful when  
making these changes to make sure that the existing users who depend  
on the current behavior don't find their players acting strangely.

Luckily, you can disconnect completely in a single step (either by  
pressing and holding the LEFT arrow button or connecting to  
SqueezeNetwork).  We've even added the ability to create a plugin to  
make this even easier in the future.

We've kept this bug open to discuss other improvements.  That's what  
we're doing now.  The solution isn't simple or obvious.

> That's not it at all.  The truth is that the vast majority of 
> customers are happy with the always connected behavior of the 
> product, it's fundamental to how it works.  We recently did 
> add support for Wake-on-LAN to answer the needs of a small 
> but vocal group of customers.
I'm also happy with the connected behavior. And I do not ask
to remove it (also I think the other don't want to remove it).
I'm asking to ADD another behavior: the off-means-not-connected
behavior. 

> Unfortunately for some folks, Window's idea of what 
> constitutes network activity is a little broken.  We need to 
> be very careful when making these changes to make sure that 
> the existing users who depend on the current behavior don't 
> find their players acting strangely.
I understand and agree. Default should be no changes in the
behavior. But the user should have to possibility to change
it if he chooses to do it. The user has already the possibility
to change other aspect of the behavior: brightness of the display, 
screensaver, size of fonts, menu items, etc. It's certainly a
strength of the products and a reason people like them.

> Luckily, you can disconnect completely in a single step 
> (either by pressing and holding the LEFT arrow button or 
> connecting to SqueezeNetwork).  We've even added the ability 
> to create a plugin to make this even easier in the future.
I could also plug out the network cable. Or turn off power 
supply for the SB. It works but I is a tecnocrativ workaround.
It is not a solution that matches the general SqueezBox quality
standard and doesn't fullfill common user expectation on how
power-off should work!

> We've kept this bug open to discuss other improvements.  
> That's what we're doing now.  The solution isn't simple or obvious.
I'm thankfull for this and I appreciate the possibility to
bring up my point of view. Since I'm not a developer I stressing
again and again on the behavior/functionality and not the
implementation. When I see the many features and properties
of the SB which can be configured on the SlimServer I simple
(and I may be wrong) assume that an additional property on one
of the several player setting forms on the SlimServer should
be easy. Maybe more hard is to change the firmware of the 
SqueezeBox in order to receive the property-value from the 
SlimServer and then act according.
(OOps, now I'm starting arguing on development matters.
 I should better stop it. Sorry)

Best regards. Loris

(In reply to comment #32)
> This is a developer tool.  Not all developers are employees.  There has to be
> some place where developers can talk freely without being stomped with "but I'm
> the customer and I don't want to hear about develoepr problems".  Don't like
> it, please do not use this tool as a forum.
> Please, consider my suggestions off the table.  I am choosing to have nothing
> more to do with this issue as I have many other things to do, including my real
> day job.

Nobody stomped on you.
Your suggestions were constructive - especially the one about Settings.
Free speech in a forum cuts both ways.
Should you decide not to contribute, that's obviously your choice.

I contributed my perspective and experience with software development and consumer products.
If I wanted to hack to turn off a device. I would have built a media server box from scratch and not plunked down $300 for a SB.
Like it or not, this company has moved beyond it's first more or less homemade device.
Depending on customers to write their own plug-ins to solve functionality issues is not a sustainable approach IMHO.
I think it's a mistake to implement workarounds for core functions that should be more properly addressed in company-controlled firmware.
Turning the box off (completely) is clearly a core function.

(In reply to comment #33)

No stomping intended...

> The truth is that the vast majority of  
> customers are happy with the always connected behavior of the  
> product, it's fundamental to how it works.  

Really?  And on what empirical data do you base that statement?  Nobody asked me when I bought the device or since.
As you know, most users of a consumer device are passive and will not complain unless something is seriously broken.
It plays music - it works, QED.

I'd bet you a large sum that the "vast majority" of your customers have absolutely no idea that this behavior even exists.  Just like the vast majority of wireless users leave their networks wide open or use sub-standard encryption.
Take a poll of new customers and ask them what they think happens on their netowkr when they push off on the SB remote.  I think you'll be surprised.

> The real question is what is "off".  The player is an always- 
> connected device, capable of displaying a clock or other screensaver  
> when "off".  This requires the computing power of the host computer.

I beg to differ.  In it's current configuration, your device is "always active seeking a connection" not always connected.
This is a subtle, but important difference.
A clock or screensaver most certainly does not "require" a host computer, that was a design decision on SD's part.

> We need to be very careful when  
> making these changes to make sure that the existing users who depend  
> on the current behavior don't find their players acting strangely.

Oh boy does that one takes me back to a past life...  :-)
We can't remedy the bug because people have come to depend on the faulty behavior.
That kind of thinking is the reason why Windows' various functions are so wacky in the first place.

BTW, I am a current user who most certainly finds my player acting strangely because it's sending packets all the time when off.  
None of my other networked devices exhibit this behavior as a default.

Please cut the cord and make silent-off the default behavior when pushing off, and keep-alive-off a config option.
The current users so dependent on the keep-alives are the more technically competent users anyway and will simply flip a bit if given the option.

Subject: Re:  add menu option to stop network activity after pressing OFF


On Aug 25, 2006, at 9:55 AM, Slim Devices Bugzilla wrote:
> Really?  And on what empirical data do you base that statement?
Because of the many thousands of players we've sold, the complaints  
have been essentially limited to a couple of people, including the  
ones in this bug.  If it were a major issue, we would have heard  
about it from our support team, etc...

> As you know, most users of a consumer device are passive and will  
> not complain
> unless something is seriously broken.
> It plays music - it works, QED.
Exactly right.

> I'd bet you a large sum that the "vast majority" of your customers  
> have
> absolutely no idea that this behavior even exists.
Right.  That means it's working great.

> Take a poll of new customers and ask them what they think happens  
> on their
> netowkr when they push off on the SB remote.  I think you'll be  
> surprised.
My guess is that they'd have no idea.  And it just works for them.

>> The real question is what is "off".  The player is an always-
>> connected device, capable of displaying a clock or other screensaver
>> when "off".  This requires the computing power of the host computer.
>
> I beg to differ.  In it's current configuration, your device is  
> "always active
> seeking a connection" not always connected.
It's trying to be.

> This is a subtle, but important difference.
> A clock or screensaver most certainly does not "require" a host  
> computer, that
> was a design decision on SD's part.
Absolutely.  We push as much functionality into the server as possible.

> BTW, I am a current user who most certainly finds my player acting  
> strangely
> because it's sending packets all the time when off.
To avoid this behavior, for the time being, don't use the OFF button,  
rather push and hold the left arrow button for a couple of seconds.

> Please cut the cord and make silent-off the default behavior when  
> pushing off,
> and keep-alive-off a config option.
Sorry, that would break the behavior for the vast majority of users.

> The current users so dependent on the keep-alives are the more  
> technically
> competent users anyway and will simply flip a bit if given the option.
That's backwards.  The users who need the keep-alives are the ones  
who need immediate feedback for when their connection goes down and  
to maintain always-on behavior, as designed.

We'll keep this bug open to address your request for an easier way to  
have the player disconnect completely from the server.

> We'll keep this bug open to address your request for an easier way to  
> have the player disconnect completely from the server.
I'm glad to hear this. Please consider that for me (and I think also for 
others) the "easier way to have the player disconnect completely" should
be an integral part of the way users do power off, because that what they
want to do: power-off. Should be as transparent as closing the fridge door.
The light in the fridge also off. As an fridge user I do not have to think
in two steps. ;-)

(In reply to comment #37)
While I grow weary of this argument, your young company needs to learn from others' mistakes in the technology industry.  I have been in your position many times and understand that tack you have chosen to pursue on this issue - it is misguided and wrongheaded.  Perhaps my posts baited you - sorry.

I thought as a company, that you were on the right track because of the open attitude displayed in your forums, but your position in this discussion of such simple issue tells me I may be mistaken.  

As an technologist, investor and VC, I can tell you that the attitude displayed in your post does not inspire confidence.  A company that purports to be on the leading edge of a niche market such as audiophile media servers should not be satisfied just because support is not being deluged by complaints.  NEVER assume that because people don't call you, all is well.  Most unsatisfied customers in any industry simply dump the offending product and go to the competition.  You'll never hear about it.  This is why companies spend millions on mystery shoppers and focus groups.  You just can't make those types of assumptions and survive in the long run.

> > I'd bet you a large sum that the "vast majority" of your customers  
> > have
> > absolutely no idea that this behavior even exists.
> Right.  That means it's working great.

What a flippant response to a serious point.  Apply this attitude to the battery recalls ripping the laptop market right now.  I'm guessing only a handful of people realized that the warming sensation in their lap was potentially lethal, yet here we are.

> > The current users so dependent on the keep-alives are the more  
> > technically
> > competent users anyway and will simply flip a bit if given the option.
> That's backwards.  The users who need the keep-alives are the ones  
> who need immediate feedback for when their connection goes down and  
> to maintain always-on behavior, as designed.

What?  Feedback from where, the server?  Nonsense.
Always on behavior is great except that you've designed a device with an IR remote as primary control.
Once control at that access point has ceased (IE the Off button is pushed), you can assume the user no longer requires this device to be on.  Even more advanced users controlling the device with a PDA or other browser-based interface will most likely be in close proximity to the SB itself.

I respectfully suggest you remove "vast majority" from your vocabulary until you can support such a statement with facts.  Customers never want to hear "well nobody else is complaining, so it must be okay..." as a response from a company.  Don't wait for a groundswell before you address an issue.

I look forward to this issue being addressed in a manner in keeping with other network devices sold throughout the world.  To the best of my knowledge and that of the peers I have consulted, yours is a device standing alone in this regard.  That is not a competitive advantage to be cherished.

Subject: Re:  add menu option to stop network activity after pressing OFF

Let's take this discussion out of the bug system, it's gone beyond  
the technical issue at hand.

Feel free to email me at dean@slimdevices.com.

Dean,
I'm not going to get into the trenches as others on this bug form to eloquently have.  

WOL functionality is useless if the Squeexebox/transporter does not allow the server to go to sleep.  Read up on the Sonos forums, WOL, energy efficiency/responsibility & NAS HDD spin-down are topics of discussion.  In the MCE community, S3 standby or "Away Mode" power management are desired.

Squeezebox WOL is broken and needs to be fixed.  Pressing and holding the left arrow button is a workaround, not a reasonable solution.  It makes sense that the current behaivior must remain the default (only since the product was released this way).  There should, however, be a configurable option that truly turns the device OFF when the OFF button is pushed.

Well said.

I'm out of the trenches having said my piece.


(In reply to comment #41)
> Dean,
> I'm not going to get into the trenches as others on this bug form to eloquently
> have.  
> WOL functionality is useless if the Squeexebox/transporter does not allow the
> server to go to sleep.  Read up on the Sonos forums, WOL, energy
> efficiency/responsibility & NAS HDD spin-down are topics of discussion.  In the
> MCE community, S3 standby or "Away Mode" power management are desired.
> Squeezebox WOL is broken and needs to be fixed.  Pressing and holding the left
> arrow button is a workaround, not a reasonable solution.  It makes sense that
> the current behaivior must remain the default (only since the product was
> released this way).  There should, however, be a configurable option that truly
> turns the device OFF when the OFF button is pushed.

Today I got back from a short holiday and my hotmail was loaded with a discussion about who is right. To be honest I don't think this bug reporting tool is about who is right or wrong. From my perspective everybody who has written in this bug report does have very good arguments. That's why the behavior of the power off button should be configurable!

Personally I like the clock option of the SB2, but really don't understand why the server is necessary for something simple as a clock! Because of this server dependance, I would like to have 3 options:
- the default behaviour like now
- completely off
- connect to squeezenetwork (because of the clock).

Which one should be the default..... I really don't care, as long as I get the different options.

Regards,
Olaf.

A thought on the "dsco" protocol command - it doesn't seem that this could achieve the desired result of "disconnect + power off" if triggered from a plugin.

If the operation has to be sent as a sequence of two commands, and the first is a disconnect, then the second command will never get there... leaving the player disconnected but switched on.

If that's the case, would this require an extension to the SB protocol (and consequently a firmware update) with a combined disconnect + power off command? E.g. "dcpo"

Subject: Re:  add menu option to stop network activity after pressing OFF

There is no power-off capability on Squeezebox.  Transporter does  
have the ability to power down the analog sections, but the CPU is  
always running.

Network hardware with correct wake-on-lan support will not wake on any activity, only on a specially crafted wake-on-lan packet.

Powering down additionally is not a firmware bug, but we'll certainly consider it for future hardware, particularly since there is rigorous new legislation in several countries.