Incorrect Resume

[MatthewP]

I paused a song, then connected the player to my computer and deleted a different song.  When Rockbox resumed playing, it was on another track.  Is this a known problem?

[AlexP]

Yes, as the info stored for resume is an index - i.e. restart at this position in the third track.  If you delete e.g. track 2, then the third track is now track 4.

[MatthewP]

Can this be changed so that it uses the filename instead of an index?

[AlexP]

It could, and that would be nice I agree - I think the problem here is that the way resume info is stored would need to be rewritten (it isn't just a case of swapping them) and someone needs to do it.

Other things to think about - the filename referenced for resume is deleted, the same file appears multiple times in the playlist...

However, it is a valid bug even if it isn't quite as simple as it first seems to fix

[MatthewP]

This problem happens even when the file is deleted in Rockbox, when it's not connected to a computer.

[AlexP]

This problem happens even when the file is deleted in Rockbox, when it's not connected to a computer.

Yes, for the same reason.

[MatthewP]

When a delete happens outside the player Rockbox doesn't know it needs to update the index.  But when it's done on the player Rockbox should update the index when the delete function is executed.

[GodEater]

Yes, but the delete function does do this, as it has no way to know that the file you're deleting is currently being used in a playlist.

[MatthewP]

If the original firmware can manage this, Rockbox should also.  When a delete is performed, just search the playlists for references to the deleted file.  If it's there, remove it.

[Llorean]

You seem to have missed the point - the problem is that the file isn't referenced in the playlist.

Basically, the playlist says "the third file in the directory" rather than a specific filename - it's an index. Since playback is stopped at the time anyway, we don't know if the third file in the directory is still the same one it used to be (they could've had file added, or other files deleted) so when the user deletes the file, it can't know which index in the dynamic playlist is the right one to delete.

You'll notice static playlists (which have filenames in them) don't present this problem - a missing file will simply be skipped over.


If you think it's easy to identify reliably whether the file was removed and handle it in the case of such dynamic playlists, though, feel free to submit a patch. Maybe something's been overlooked.

[MatthewP]

Is the dynamic playlist directory in .playlist_control?  And the index in nvram.bin?  I'm not a developer but wouldn't something like this work?:

// pseudocode
delete_dir =  directory of file being deleted
playlist_dir = dynamic playlist directory in .playlist_control
if delete_dir = playlist_dir // deleting a file in the dynamic playlist
{
    decrement playlist count // update # of playlist entries
    if delete file index < playlist index
    {
         decrement playlist index // deleted file is before current file so update current position to reflect deleted file
    }
}

[MatthewP]

Does anyone have the time and know-how to implement this?

[Llorean]

I don't see how that solves the problem in your first post - if you deleted the file from the computer, how does Rockbox know it's missing exactly? Your pseudocode doesn't cover that at all.

As well, this would require the filetree code to know things about playback status, and depend on them. Generally it's beneficial not to have too many dependencies between separate areas. It can lead to new and stranger bugs.

It also doesn't address the situation of added files, or renamed files, or any other way in which the contents of the folder could be changed. For example, if I add two files from my PC then delete one on Rockbox, your code would have it move the index making the resume point even more wrong.

The simplest solution would be to make it clear in the manual that when folder playback is started, if the folder contents change, resume could be inaccurate, and not try to add any special magic that can muck up the code any worse. Since there is no way for it to be reliably accurate, being up front about it is basically the best you can offer.

 If it's really a problem, figure out a way to get the speed of index based playlisting, but actually store the filenames for verification purposes.

[MatthewP]

It doesn't solve the problem initially presented.  But the solution is still useful because I still need to delete many files through Rockbox.  This is not a issue with any other DAP's original firmware, so I'm surprised that Rockbox can't handle such a simple use case.

[Yotto]

A simple, non-programming solution is to not use the resume function.

Turn on bookmarks, and when you stop your music and hook your player to the computer, the bookmark will still load the correct file no matter what you do to the files. Unless you delete the file you were listening to, of course. Bookmarks don't like that too much.

Personally, I wish that the user could define "resume" as "Load last bookmark" instead of what it is now, but as a non-programmer I have no clue how to do it myself. I also have no expectations that "what I want" be "what is put in Rockbox"