Support and General Use > Audio Playback, Database and Playlists

Incorrect Resume

<< < (3/4) > >>

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" :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page