Bookmark bug

[nerdrunner]

I listen to podcasts a lot on Sandisk Sansa C250/Rockbox, and once a podcast has been heard, I almost never want to hear it again, so I want to delete it as soon as possible.

Here's the bug:

Let's say there are 5 podcasts in a directory, and I choose to play the entire directory, so Rockbox makes a temporary playlist of the 5 titles in the directory.

After listening to podcast #1, but while listening to podcast #2, I go in & delete podcast #1.  Podcast #2 continues playing (and continues displaying "#2 out of 5").

The problem comes when I turn _off_ the Sansa C250/Rockbox, and it automatically generates a bookmark to remember where it was.

I then turn _on_ the Sansa/Rockbox, and it continues playing, but since it wants to continue playing "#2 out of 5", it "continues" playing the wrong podcast (the one that was originally #3 out of 5 before the original #1 got deleted).

One solution to this bug is for bookmarks to remember the actual file name of the file that was playing within the playlist instead of the index number into the playlist.

There's at least one mp3 player that handles this situation of deleted files correctly -- the "pTunes" player for the Palm Treo.  That player also generates playlists dynamically when asked to play an entire directory, but somehow stores its bookmarks in a way that identifies actual files, not numeric indexes into the playlist.

[Lear]

I then turn _on_ the Sansa/Rockbox, and it continues playing, but since it wants to continue playing "#2 out of 5", it "continues" playing the wrong podcast (the one that was originally #3 out of 5 before the original #1 got deleted).

One solution to this bug is for bookmarks to remember the actual file name of the file that was playing within the playlist instead of the index number into the playlist.

Actually, that is how bookmarks are created right now. When "playing" a bookmark, it does resume by name (in practice it first looks at the file at the index number, but if the name doesn't match, it looks for the file by name).

The problem here, I suspect, is that you don't actually resume the bookmark, but rather "Resume Playback" (via the main menu, the play button or the Start Screen setting). This works independently from bookmarks (so it works even if bookmarking is turned off), but has the limitation of being index-based only.

[nerdrunner]

Actually, I'm merely turning the player off & on.  Rockbox resumes however it resumes.  Unfortunately, it resumes the wrong podcast in the right place.

[Lear]

If Rockbox resumes just by turning the player on, then it must be due to the start screen setting, in which case bookmarks are not used. So, not a bookmark bug.

Oh, as a clarification, Rockbox uses the name when resuming directory bookmarks, not playlist bookmarks...

[nerdrunner]

You people are amazing!  This is a highly reproduceable _bug_.  So instead of theorizing, just try the sequence that I reported.  Thank you.

[gevaerts]

You people are amazing!  This is a highly reproduceable _bug_.  So instead of theorizing, just try the sequence that I reported.  Thank you.

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.