This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6686 - Pause screen when adding to playlist
Attached to Project:
Rockbox
Opened by Mike Holden (mikeholden) - Thursday, 22 February 2007, 19:30 GMT+2
Last edited by Alex Parker (BigBambi) - Sunday, 06 June 2010, 00:50 GMT+2
Opened by Mike Holden (mikeholden) - Thursday, 22 February 2007, 19:30 GMT+2
Last edited by Alex Parker (BigBambi) - Sunday, 06 June 2010, 00:50 GMT+2
|
DetailsWhen adding a new playlist to the current playlist, the progress screen flashes past so quickly that you can't read it.
This patch adds a 2 second pause once the last file has been added, so you can read the status properly. |
This task depends upon
I will make another version of the patch shortly to address that issue as well.
Please disregard this until then!
The following issues are fixed:
1. When finishing inserting or queueing into a playlist, the final status message is displayed for 0 seconds, making it unreadable.
2. When inserting or queueing shorter playlists, the feedback is useless because it only updates every 10 files. Most of my playlists are for albums, and so many contain 9 files or less.
3. Status message at end of insert/queue operation is bogus. It says to press STOP to interrupt, but there is nothing to interrupt as processing of the playlist is already complete.
The fixes are as follows:
1. Completion status splash is now displayed for 2 seconds.
2. When we start to insert/queue, report status every 1 file. After 50 files, switch to reporting every 10 as before. This makes the feedback useful even for smaller playlists.
3. 2 new messages added which don't mention interrupting the operation.
Should be good to go now, if anybody feels like testing/committing :-)
I have been using this patch daily since I created it, and it hasn't skipped a beat. The only concern raised on this tracker and in the mailing list is that the delay is too long, but this was from someone who hadn't actually used the patch. I have reduced the message wait time to 1 second to address this issue. Apart from that, the main delay still remains that of waiting for the disk to spin up, which is the biggest part of the procedure. This patch doesn't perceptibly slow anything down.
Any chance this (minor) change could be considered for 3.1?