Bug 507 - Have a preference for a confirmation dialog when adding to or replacing a current playlist.
: Have a preference for a confirmation dialog when adding to or replacing a cur...
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Player UI
: 5.x or older
: All All
: -- enhancement with 5 votes (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-21 22:19 UTC by Daryle Tilroe
Modified: 2011-11-06 23:22 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daryle Tilroe 2004-08-21 22:19:50 UTC
This is particularly to prevent the frequent accidental section of all of ones
songs for a playlist.
Comment 1 Dave Rodger 2004-08-25 07:40:35 UTC
I'm not sure if this would address the problem of repeated right-arrow presses 
(say, that get queued up because of delays on the server, then are processed 
rapid-fire.)  Could the confirmation message "clear" all previously sent arrow 
presses before proceeding?
Comment 2 Michael Brouwer 2004-08-30 09:37:51 UTC
This would not be an improvement IMHO.  I make playlists all the time by adding entire genres or just 
everything.  Having to confirm each addition would be annoying.

The real bug is that when you do select a really large playlist it takes a lot of time.  I believe this issue is 
being addressed on the sql db backend branch.

After all if selecting a playlist is instantaneous no matter how large it is why is it a problem if there are 
more than 50 songs in it?

As for the3 second comment: I believe the right arrow pressing issue has been fixed in a recent 
firmware update.
Comment 3 KDF 2004-08-30 11:15:28 UTC
if the goal of this kind of fix is to avoid a long wait, it may not accomplish
that.  To know how many songs are in a potential playlist, the server would have
to compile the playlist and count, which is what currently takes the bulk of the
wait.
Comment 4 Daryle Tilroe 2004-08-30 14:03:46 UTC
"This would not be an improvement IMHO.  I make playlists all the time by adding
entire genres or just  everything.  Having to confirm each addition would be
annoying.

The real bug is that when you do select a really large playlist it takes a lot
of time.  I believe this issue is being addressed on the sql db backend branch.

After all if selecting a playlist is instantaneous no matter how large it is why
is it a problem if there are  more than 50 songs in it?"

The problem is that it blows away your existing playlist without confirmation.
After some thought I think it should be implemented everytime an existing
playlist would be deleted or perhaps even modified (an add '+') no matter how
many selections are involved.  I do, however, see how some might not want the
confirmation.  Since this could easily be implemented as a preference (eg. [no
confirmation], [confirm on replace], [confirm on add], [always confirm]) I think
it is possible to make everyone happy.  I think I will change this bug to
reflect this feature rather than the confirmation for an arbitarily large size
of replacement/addition.

"As for the3 second comment: I believe the right arrow pressing issue has been
fixed in a recent  firmware update."

Unless it is fixed in a 33+ it is still a problem.
Comment 5 KDF 2004-08-30 14:19:01 UTC
daryle, I recommend that you join the checkins mailing list.  you can then see
what exactly is being updated with every patch submitted.  FW34 is noted as
having some improvements for many button press timing problems.
Comment 6 Blackketter Dean 2005-06-07 11:17:34 UTC
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.
Comment 7 Chris Owens 2008-12-18 11:48:53 UTC
Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.
Comment 8 Chris Owens 2010-05-06 15:54:35 UTC
Dean doesn't work here any more :)
Comment 9 Alan Young 2011-11-06 23:22:58 UTC
Unassigned bugs cannot have a priority.