Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9682 - Resumes incorrect file after deletion from directory

Attached to Project: Rockbox
Opened by Mr. Crontab (mrcrontab) - Saturday, 20 December 2008, 08:57 GMT+2
Last edited by Alexander Levin (fml2) - Wednesday, 19 May 2010, 06:11 GMT+2
Task Type Bugs
Category Playlists
Status Unconfirmed
Assigned To No-one
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

I apologize if this is in the wrong category, I've done my best to choose the correct section.

Using the latest current build: r19503 on sansa e260

Description:
When playing back files from a directory on the filesystem, after listening to a file and deleting it, the auto resume feature chooses an incorrect file.

Example/steps to reproduce:
A directory has three files: 1.mp3, 2.mp3, 3.mp3.

Listen to all of 1.mp3. While 2.mp3 is playing, delete 1.mp3 from the filesystem. Power the player off. When powering the player back on, it will resume from the correct time position, but it will be playing 3.mp3 rather than 2.mp3.

It sounds like it is remembering which number on the directory playlist to resume, rather than the filename.

If this is a dupe or intended behavior, sorry! I only recently noticed it when listening to a large directory of 1 hour long mp3s, and deleting old ones as I go.


(JD edit: moved to manual to go with the other playlist/bookmark/database interaction lmiitations)
This task depends upon

Comment by Jonathan Gordon (jdgordon) - Sunday, 21 December 2008, 11:02 GMT+2
you're correct that it saves the playlist position in the folder so if you remove a file the playlist won't know. This is a minor annoyance but makes the save/resume handling very simple, so it probably wont be fixed any time soon (if ever)
Comment by Steve Bavin (pondlife) - Sunday, 21 December 2008, 12:42 GMT+2
I suppose the playlist should be saved along with the index. Then on resuming the (changed) folder wouldn't be reparsed, but instead the missing files just skipped on-the-fly.
Comment by Jonathan Gordon (jdgordon) - Sunday, 21 December 2008, 13:50 GMT+2
a possible solution is to store the current filename in the .playlist_control file so when it is resumed we can make sure the index and the filename matches. If it doesnt we have a few options how to try and find the right track... The downside to this is that the .playlist_control file will get filled up wth these save position lines and they are not easy to remove without lots of special handling code. This isnt really a problem, but I have a patch which sort of merges playlist control and bookmarks which uses these mutliple save positions as user bookmarks. If they are added automatically there will be way too many bookmarks and things might get messy... (2min of thinking....) CRAP! this could actually work... the reason that patch has been rotting on my hard disk for the last few weeks is because I couldnt figure out how to make the bmark browser useable... doing this would fix that problem also :D
Comment by Peter D. (PeterD) - Saturday, 28 February 2009, 08:37 GMT+2
I think that the theoretical best way to solve this is to save the file name. How much space can a single file name take if you keep it in a regular slot or even a file of its own? Of course if you want to save an indefinite number of bookmarks that is a different story.

There are other alternatives, the delete function could be extended to decrement the index (if the deleted file has an index less than the current file's index). But beware that files can be deleted via the computer as well as directly from the DAP.

Alternatively check time stamps on resume. If any file changes have occurred since the resume state was saved though up you hands in horror. No I'm not serious about that one.
Comment by Steve Bavin (pondlife) - Saturday, 28 February 2009, 17:14 GMT+2
As you can also delete a file whilst using a database playlist, this should be solved in a manner that's independent of the file browser being used. (Hopefully the above solution wouild work ok for any sort of playlist, but I'm just checking....)
Comment by menachem shapiro (menachem) - Thursday, 02 July 2009, 05:56 GMT+2
I have noticed the same bug with my Archos Recorder.

I have it setup so that when I shut off the player a bookmark is automatically created. I also have it setup so that when the player turns back on it will auto-resume whatever it was playing when the device was shut off.

One interesting thing about this is that if you browse to "Recent Bookmarks" and chose the bookmark, the correct file will play, even though files have been deleted from the directory.

I don't know why that bookmark works properly and the auto-resume bookmark doesn't work right, but maybe the logic for the "Recent Bookmarks" could be used for the auto-resume bookmark.

Loading...