Hi Daryle.  I'm a little confused by this.  The current behavior is to only display the players that the 
server has heard from since it was last started.  This prevents the accumulation of players that are no 
longer in use (a particular problem with software-based players.)   Are you suggesting that every player 
that's ever connected to the server be shown all the time?

Actually yes, because otherwise they are hidden and either cluttering up the
prefs file when they should just be deleted ('forgotten') or inaccessible when I
would like to make changes or tweak settings.   IMHO the accumulation you refer
to is actually made worse by hiding them.  I know several times I have gone into
the prefs file to manually clean up or change settings for hidden players (for
example makeng some changes to my work softsqueezes, while I was thinking of it,
from home).  Right now without manually hitting the file a user could end up
with dozens of stale player entries in the prefs file after some months of
fooling around with multiple hard and soft players.  I know I would like to
always see a list of all my players whether or not they have been turned on
since the the last time the server has run.

I'm still confused.  Are you saying that the prefs should be purged?  Or that the inactive players should 
be displayed?  My feeling is now that for the average user that the current behavior is right.  Even the 
accumulation of hundreds of players in the prefs file isn't a substantial burden and showing players that 
are long gone probably isn't a good idea.  

What might make sense is to hide players that haven't been heard from for a particular amount of time 
(1 day or so?) Rather than relying on the server's process lifecycle. How does that sound?

> I'm still confused.  Are you saying that the prefs should be purged?
> Or that the inactive players should be displayed?

The latter; "inactive players should be displayed". This gives the user the
opportunity to purge them or alter settings from the web interface.

> My feeling is now that for the average user that the current
> behavior is right.  Even the accumulation of hundreds of players
> in the prefs file isn't a substantial burden and showing players
> that are long gone probably isn't a good idea.  

Thats sort of my point that they would not accumulate if the user saw them and
could delete them.  I think that having old stuff accumulate out of sight is a
bad idea.  A loose analogy is the windows menu feature that hides little used
selections; except this is even worse in that there is no way to see the stuff
short of editing the text file.

> What might make sense is to hide players that haven't been
> heard from for a particular amount of time (1 day or so?)
> Rather than relying on the server's process lifecycle. How
> does that sound?

That length of time will never be right for everyone.  Since you don't think the
average user will be interested in keeping the prefs clean or altering settings
on less used players perhaps the best solution would be some short of server
preference: e.g. "Show all Players".

I expect this will, in fact, break a great deal of the current architecture.  If
the server allows access to non-existent player settings, we'd have crashes all
over the place due to calls to non-existent clients. 

We could get around that issue by creating instances of players at startup time that have been heard 
from in a while.  Essentially, we'd decouple the creation of player objects from the initial connection if 
they'd been heard from before.  This isn't a big issue right now, but it's something to think about.  It's 
one of the last "features" that depends on the startup time of the server for behavior.

> I expect this will, in fact, break a great deal of the
> current architecture.  If the server allows access to
> non-existent player settings, we'd have crashes all over
> the place due to calls to non-existent clients. 

This confuses me quite a bit.  How is showing all players
different from showing disconnected ones that happen to have
been in contact since the last restart?  I have often changed
settings on disconnected players via the web interface.  AFAIK
it only alters the prefs file and then the next time they
are in communication again the settings are applied.  What
am I missing?

the difference is, that players in the prefs file may not have been discovered.
 players that you have disconnected since starting the server have been
discovered and the server has a client object established.  the architecture
would have to change such that a client object then exists for existing players
and non-existing players.  to me, this leads to a mess.

> the difference is, that players in the prefs file may not
> have been discovered. players that you have disconnected
> since starting the server have been discovered and the
> server has a client object established.  the architecture

This is where my lack of knowledge of the terminology and
operating specifics of slimserver is a real handicap.  I presume
that when a client ids itself initially to the server it
creates some sort of memory resident 'client object' that is
then populated by any matching prefs entries, then manipulated
as required (with corresponding prefs changes).  Is this
roughly correct?

> would have to change such that a client object then exists
> for existing players and non-existing players.  to me, this
> leads to a mess.

I guess the kludge would be to sniff the prefs file for all
players and acivated client objects in advance.  You say this
leads to a mess; by this do you mean just potientially having
a lot of memory resident objects if you never house cleaned?

yes, the client object is created via the discovery process.  Thus, without a
client, you'd have to recover the client object from somewhere else.  the mess
comes from adding code to handle this, as well as handling responses for
non-existent clients such that the server is aware is a dead client, but doesn't
cause a crash or waste resources (ie, starting a transcoded playback to
non-existent clients).

perhaps the player list could show all clients found in the prefs file, but
block all functions for inactive ones, save for 'forget player'.  my personal
opinion is that this is a lot of rework for little gain.  I just can't see the
real use of this.  I've been using hte same prefs file since day one and with
all its old player data, I'll agree its annoying to find things when editing
manually, but I never need to do that for regular use, nor do I find the file
too large to keep around, especially compared with 87Gigs of music library.

it mainly depends on what functions you feel are required for inactive players.

Notice you change to enhancement, fine with me.  Although I did notice that
someone else on the list noticed the amount of old player 'crud' in the prefs
file.  It was also suggested that it needed to be cleaned up or deleted to get
an upgrade problem to go away.  Not that this would necessarily fix the latter.

To answer you previous note:  I would say all features would be the best.  When
I notice this annoyance the most is upgrading and testing new features.  For
example I'm sitting my my PC/server in the basement and decide to try out the
new scroll delay/speed features.  I download and install the new slimserver. 
Then I have to run upstairs to turn on the Squeezebox, back down to tweak the
setting, and back up to test it out.  Just a little pain, but good exercise :-).
 Perhaps also a good excuse to by a wireless laptop.

Moving bugs that won't be immediately fixed in 6.1 release. Please review and update if this is an error 
or if this bug has already been fixed.  Thanks.

This will be needed for SN integration, so I will take it.

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

Yeaaahhh!!!  Two years and my enhancement is finally getting some respect. ;-)

As far as the web UI is concerned... I think it would be best to not show these inactive players directly on the home page under 'Settings'.  For one, it will potentially clutter up that page, particularly for anyone who has a lot of inactive software players.  Secondly, this is currently the best way to see at a glance which players are actively connected.  Instead, provide a link to 'Inactive Players' and then present a list of all players on another page, with some kind of indication of which are active and which are inactive.

This will certainly need some discussion, but I was considering something like:

Server Settings
Player Settings for Living Room
Player Settings for Bedroom (on SqueezeNetwork)
Player Settings for Kitchen (offline)

etc.

you may want to consider a cleanup routine.  For those who have dynamic ip's and streaming clients, you could end up with many defunct players.  it might be good to have a setting for the number of days to automatically forget.

when combined with the enhancement for default new player config, this would make a really good manager for this type of application

Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.