Rockbox

Tasklist

FS#8986 - File deletion target changes with trackchange - therefore 'wrong' file deleted

Attached to Project: Rockbox
Opened by Eddy (bascule) - Monday, 12 May 2008, 08:39 GMT
Last edited by Steve Bavin (pondlife) - Tuesday, 13 May 2008, 13:51 GMT
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Operating System All players
Severity Medium
Priority High
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This bug occurs when playing back a file and choosing to delete it from the WPS context menu while it is still playing.

If a trackchange occurs between choosing a file for deletion and actually pressing the 'Yes' option, the *new* currently playing file is deleted, rather than the one originally selected for deletion.

For example using the following playlist:
a.mp3
b.mp3
c.mp3
d.mp3

If b.mp3 is playing and a few seconds before the track ends, the user selects [context menu] > Delete

The screeen displays:

Delete?
b.mp3

SELECT = Yes
Any Other = No

Wait until c.mp3 commences playback, then press SELECT

The screeen displays:

Deleted
c.mp3

http://forums.rockbox.org/index.php?topic=16785.0 refers.
This task depends upon

Closed by  Steve Bavin (pondlife)
Tuesday, 13 May 2008, 13:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  Hopefully r17494 should sort this out.
Comment by Jonathan Gordon (jdgordon) - Monday, 12 May 2008, 10:02 GMT
I thought we didnt allow the delete option in the wps context menu because nasty things happen if you try deleting a file while its not fully buffered, and this...
should the option be removed?
Comment by Eddy (bascule) - Monday, 12 May 2008, 12:57 GMT
Personally I find it a very useful function whilst listening to podcasts etc. and I would not like to see it removed, especially as it was committed by a certain jdgordon ;-) http://www.rockbox.org/tracker/task/7437

However, unless the method by which the code determines the target file cannot be fixed, then maybe it should, as it is certainly not the behaviour that a user would expect and it will occur at exactly the time when a user is most likely to use the functionality i.e., at the end of a track.
Comment by Jonathan Gordon (jdgordon) - Monday, 12 May 2008, 12:59 GMT
haha, damn split personality :p
ok, a patch to fix the problem would be more than welcome....
Comment by Steve Bavin (pondlife) - Monday, 12 May 2008, 16:15 GMT
Does this help?
Comment by Eddy (bascule) - Tuesday, 13 May 2008, 13:40 GMT
Oh yes!

Thanks Steve, that patch works perfectly for me. Is it able to be commited?

My untrained eye doesn't see anything in the code or the functionality that could upset anyone...

Loading...