Support and General Use > Audio Playback, Database and Playlists

Bookmark bug

<< < (2/2)

gevaerts:

--- Quote from: nerdrunner on November 03, 2009, 09:07:24 AM ---You people are amazing!  This is a highly reproduceable _bug_.  So instead of theorizing, just try the sequence that I reported.  Thank you.

--- End quote ---

People are not claiming that there is no bug. They are trying to find out where it is, so it can be fixed. Just looking at it happening is not going to help there, "theorizing" is.

Yotto:
This has been a problem for me since I started using Rockbox years ago.

The "bug" is in the "resume playback" feature. I put "bug" in quotes because I believe I reported it and was told it was not a bug, but I could be mistaken. It was literally years ago. Possibly over 3.

The "resume playback" feature does not use file names, and I remember seeing a very good reason why it did not use filenames, but I cannot recall what that reason is. It instead uses a number that represents a file's location in the directory. So, when you delete a file, you change this number for all files beyond it in the directory.

I fixed this for myself by turning off "resume playback" and just never using it again. I have my Rockbox set to go to the menu. When I turn it on, it is in the menu, I hit "Bookmarks" and then select the podcast bookmark. And bammo, correct place.

Note: You need to fiddle with your bookmarking settings. Turn on "Bookmark on stop" and "Maintain a list of recent bookmarks." I have those set to "Yes - Recent Only" and "Unique Only"

torne:
"Resume playback", whether selected from the menu or used as the start screen setting, does not *use* the bookmark system. Bookmarks are not based on indexes, and if you used an actual bookmark this would work fine. Thus, there is no bookmark bug here, and talking about bookmarks is confusing the issue.

"Resume playback" uses a different, simpler way to remember where it was, and it's based on an index as you guessed. The behaviour you have does seem like a bug, but fixing it may not be entirely trivial: there are more kinds of dynamic playlist than just ones created from a directory.

Wild speculation: you could notice when the user deletes a file which is in the current dynamic playlist, and update the playlist to remove it? That still won't handle the player being modified externally...

JdGordon:
As has been said.. this has nothing to do with the bookmark system... the problem is because you are not removing the track from the playlist, deleting the file on disk does nothing.

Navigation

[0] Message Index

[*] Previous page

Go to full version