Rockbox

Tasklist

FS#9929 - context menu delete does not work as expected

Attached to Project: Rockbox
Opened by Peter D. (PeterD) - Thursday, 19 February 2009, 06:34 GMT
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 23 December 2009, 07:35 GMT
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

While playing an mp3 file a long press of Select (the central button) brings up a menu that includes "Delete". Select delete. Select again for "yes".

The "deleted" file continues to play. I would expect the file to be gone, and the next file to begin playing.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Wednesday, 23 December 2009, 07:35 GMT
Reason for closing:  Not a Bug
Additional comments about closing:  it might seem odd, but this is the expected behaviour... rockbox will keep playing untill it runs out of buffered data
Comment by Anthony Mercuri (cool_walking_) - Friday, 20 February 2009, 07:40 GMT
Not me. I would expect it to do exactly what it does.
Comment by Peter D. (PeterD) - Friday, 20 February 2009, 08:50 GMT
Really? You expect the "deleted" file to be irrevocably marked for future but not immediate deletion but to keep playing for the time being as if nothing had happened? That is perfectly explicable behaviour to me, a geek, but it was a surprise when I was trying to explain things to an elderly relative.

Usually it is easier to explain things when the behaviour is; issue a command and it gets executed NOW with *positive feedback* to the user, so that the uncertain doddering user knows that it worked and (more importantly) that the user has done the right thing.
Comment by Anthony Mercuri (cool_walking_) - Friday, 20 February 2009, 14:03 GMT
The file isn't "marked", it *is* actually deleted then and there. It's just that, because it's already been loaded into RAM, it can continue to play.
Comment by Peter D. (PeterD) - Friday, 20 February 2009, 17:43 GMT
As a geek with a fair knowledge of how things work internally, I totally agree with you.

Most people are not geeks. The user interface would be more obvious, and easier to explain if it was not playing phantom files that do not exist.

It would be easy to implement, easier to explain, and not hurt the geeks.
Comment by Johannes Linke (Jaykay) - Friday, 20 February 2009, 19:10 GMT
the first time i tried out rockbox i was really happy about the delete-function, and of course used it.

i had the same "problem" as peter, i was confused why the not-existing still plays fine. at that time i didnt know anything about buffering, as most normal users.

and i always checked three times whether the file was really deleted :)

does anyone know what it does when rockbox tries to rebuffer a already deleted file?
Comment by Anthony Mercuri (cool_walking_) - Saturday, 21 February 2009, 04:24 GMT
Just tried this in an iPod Video sim by playing an album, deleting the first song, and then using the "previous track" button to get back to first song. It played the second song in the album, showed the second song's metadata, but showed "1 of 10" (there were now 9 physical files, and 10 still in the playlist). Subsequent attempts to play the first song result in it playing the second song, but it now correctly shows "2 of 10". In "View Current Playlist", the first song appears as "1. (ERR) 01. Stone Magnet".

I then deleted the entire folder, skipped through a few tracks, which kept playing. Then I guess it hit one that wasn't buffered anymore, and all WPS information turned blank or "(root)" or "[1995] Electric Wizard" (folder name, where normally there is album name) or "07. Electric Wizard.ogg" (filename, where usually there is track title). Trying to skip between songs from this point did nothing. It just stayed on track 7 with the blank WPS. I went into "View Current Playlist", and saw this[1]. I played track 6 (it didn't actually play), and now it's frozen at that screen. The sim's "backlight" goes on and off in response to keypresses/timeout, but the selection bar does not move, and nothing (other than the backlight) appears to happen when clicking or holding any buttons.

I then did retraced this "delete the directory and keep skipping 'til you hit a track in the playlist that isn't buffered so the WPS goes blank", but instead of then attempting to play a file from "View Current Playlist", I went to the file browser and tried playing another, unrelated file, and got the same "button presses do nothing but turn on the backlight" freeze, at this screen[2]. I then did it a couple more times, but doing different things at the last stage. Stopping or pausing playback caused the freeze. Most plugins (of the few I tried) worked fine. MpegPlayer froze at a completely black screen, presumably because it stops playback when it starts up.

[1] http://dl.getdropbox.com/u/84704/rockbox_play_deleted_file.png
[2] http://dl.getdropbox.com/u/84704/rockbox_play_deleted_file_aftereffect.png
Comment by Boris Gjenero (dreamlayers) - Thursday, 26 February 2009, 05:56 GMT
The problem I see in the code is ability to delete open files. Typically, the file is just being read and when looking up the next sector in the FAT code will behave as it's end of file. However, worse things can happen.

If a file has already been buffered to the end and closed, it will play properly. I'm not sure that's a problem. It's easy to skip the track.

Tests done using the sim might be deceptive, because the sim uses host OS file operations which behave differently from Rockbox file operations.
Comment by Anthony Mercuri (cool_walking_) - Thursday, 26 February 2009, 07:41 GMT
Nope, not the sim. I just reproduced on my iPod 5G, with r20107 and  FS#9955  bootloader.
Comment by Johannes Linke (Jaykay) - Friday, 20 March 2009, 20:35 GMT
i just tried booting, selecting a file and deleting it as fast as possible, i.e. after ~2sec. the whole file (3,3min, mp3 256kbps) played fine. i guess rockbox also reads the file if its deleted, because its unlikely that rockbox buffered the whole file in 2 seconds.

and i guess there will happen some strange things when unbuffered parts of the non-existing files get overwritten by copying some files.

Loading...