"resume playback" suddenly starts at beginning of playlist instead of whre I was

[mikebomb]

I reported this a long time ago as FS#12864.

[alexweissman]

First of all, just want to say that I love Rockbox.  It has turned my cheap Clip+ into a mighty music powerhouse.

But, I think I'm having the same problem that these guys are having with the new version (3.13).  My config.cfg file:

# .cfg file created by rockbox 3.13 - http://www.rockbox.org

Code: [Select]

volume: -24
start directory: /<microSD1>/
autocreate bookmarks: on
autoupdate bookmarks: on
autoload bookmarks: on
use most-recent-bookmarks: on
autoresume enable: on
database scan paths: /<microSD1>
tagcache_autoupdate: on
fmr: /.rockbox/fmpresets/preset01.fmr
start in screen: wps
playlist catalog directory: /<microSD1>/Playlists
Semitone pitch change: on
Maybe I'm not understanding the way that bookmarks and autoresume work, and how they interact with one another.  Basically, what I want is to be able to pause at any point in a playlist (dynamic or preset), and then either turn off my device manually or allow it to turn itself off automatically, and then have playback automatically resume at the same point in the same track where it left off.

It seems like sometimes it will behave in the desired manner, but sometimes it will just restart the playlist from the beginning.  If I let it play from the beginning of the playlist, then sometimes it will get to the track where I had paused and resume that track.  I'm assuming that it's not just a "random" behavior, and that there are some specific conditions when this happens.  But, it seems to be a somewhat complex set of conditions and I'm finding it difficult to tease out the cause.

I realize that Rockbox has a LOT of customizability, and I appreciate that.  But for this particular aspect, I just want my device to behave "normally".  What would be the sane, "express" settings to achieve this?

[[Saint]]

You should update your build, even if it doesn't fix the issue you're talking about, update it anyway.

The release build is very far from new, you're missing out on the better part of two years worth of bugfixes and improvements.


[Saint]

[alexweissman]

Alright, I'll try that when I get home tonight.  Should I just use the latest nightly build, or is there a build that is considered "stable"?

Also, I'm not sure but I think this issue might be related to the "auto power down" feature.  I think it might only happen when I pause a playlist, leave it alone, and then Rockbox automatically shuts down.  Then when I turn it back on, the playlist starts over from the beginning.  I'll try to test this a little more rigorously.

[alexweissman]

Ok, I tried a few experiments:

Experiment #1:
Database->Albums->Select Track
Play for a while
Pause
Wait for auto-shutdown
Turn player back on
Playlist resumes as expected

Experiment #2:
Playlist Catalogue->Select Playlist
Play for a while
Pause
Wait for auto-shutdown
Turn player back on
Playlist starts over at beginning

It is important to note that this only happens when I start playing a playlist that hasn't already bookmarked itself in some other way, such as if I paused the playlist and then started playing another playlist.  In that case, when I go back to the playlist it seems to resume where it left off (which is usually what I don't want to happen in that case, ironically).

Does Rockbox keep track of my position in a playlist exclusively through bookmarks?  Or, is there some other way?

[fredex]

after a loooong hiatus, I can add a little more information:

this problem restarting from power off does not occur with every playlist (re-reading above I see that I was not clear on that). Some books seem to do it a lot, and once they start doing it I"m at a loss as to how to fix it.

however: the play lists for these books are just a straight listing of filenames that seem to naturally sort into the correct order (alphabetical/numeric sort seems to be the default on rockbox), so that if instead of using the playlist, I go to the directory where the actual files are stored and play the first one, then all the rest properly play in order no matter how many times the player is paused or powered off/on.

I've also tried the (then) latest dev builds 2 or 3 times with my fingers crossed, but no joy: the issue will still occur.

[ThomasG]

First, I love rockbox, too: file support, vorbis ...

I’ve got the same problem on my SanDisk+. And it’s still there with 3.14 and also wasn’t before I updated to 3.13 (I guess) some years ago. (Unfortunately I don’t know which firmware I used before.)
Here are some hints from my direction, because now we may find what Fredex, Alexweissman and I have common.

Like they said, it sometimes works like intended and often doesn’t. Then it resumes with the first track of the list.

I tried it with m3u (ANSI) and m3u8 (UTF-8) lists, with characters like apostrophe, with blank line at the end and without, to see if that’s the problem. I made a simple m3u list within the same folder like the files (so no path, just the filenames). It happens in all different cases.

Sometimes it happens only on one song. I can reproduce it by always going forward to THAT song, pressing Power to stop and “Resume Playback”. Then it happens on another track and suddenly everything is working right again. And then the problem returns. I just have to chose the track by going forward and stop (so it plays only for a second). I can’t see any pattern in this behaviour.

The ".playlist_control" file’s content always looks like following even if the player does not forget the song. But where is the current song stored? The only other written file is “nvram.bin”.

P:2:/playlists-shuffled/test:0-utf.m3u8

Regards
Thomas

[Bilgus]

I think this is fixed in the latest dev versions http://build.rockbox.org/

[ThomasG]

Unfortunately the (at this moment) latest development build for Sansa Clip+ (build 7a8c9da) didn’t fix it. Problem is still there.

[Bilgus]

can you make a sample of the smallest possible case for which it occurs and upload it somewhere for someone to peruse
like 3 songs and a playlist that doesn't resume properly?

[qhorin]

Just switched from an ancient custom build on my now sadly defunct Clip+ to a bleeding edge custom build (mainly for your power saving and multiboot patches, Bilgus, thanks!) on my new ClipZip.
Ran into the same exact issues described here and in FS#12864.

I know that the following observations are basically worthless until I have verified with an unmodified non-multiboot dev build, but here is what I have noticed so far:

• The bug appears only sporadically and is thus hard to reproduce. Sometimes the exact same playlist will resume correctly, sometimes it won't.
• Dynamically created playlists from folders with a lot of (500+) files and quickly pausing multiple times after skipping many (5+) tracks seem to produce the issue more often than folders with less files.
• I am booting rockbox from my external sdcard. All my media is on this storage device.
  The resume bug (so far) only appears when working with relative (or rather symlinked? loopmounted? not sure how rockbox handles storage integration into root) paths (/MUSiC/* instead of <microSD1>/MUSiC/*)

Will check back in once I can provide some actual information on how to reproduce this behavior with a current dev build.

[Bryanhoop]

I'm running into the same issue, and would like to add a bit more info.

When I am listening to a playlist and then turn off the player, 95% of the time the playlist will begin at the beginning of the first track. When this doesn't occur is usually when I immediately restart the player within 1-2 seconds.

When I browse to a file in a folder, play it, and restart the player, it will pick up where I left off 100% of the time.

Using Clip+, latest dev build.

[kostkoro]

Hello. It is an old topic, but I'd like to contibute, with a different approach, and, hopefully, a solution.
I recently had the issue of playlist resuming from the very first track, after a shutdown. My player is an iRiver H340 with a Toshiba disk of 80Gb. Rockbox is 3.14.
Some playlists I added recently were behaving as above. I had compiled the playlists with Media Monkey 4.1.24.1083. I have configured it (in settings) to export m3u playlists in UTF8. I also export them in the root directory of my laptop. I use the same folder structure in both my laptop and the H340, eg. \Music\somefolder\somefolder, etc.
The tracks in these playlists were in absolute path, but driveless, and more important, with no "\" at the beggining: eg.
Music\somefolder\song1
and not: \Music\somefolder\song1
The player recognized them and played them fine, ecxept for the resume problem.
I had many other playlists with the "\" at the begining of the tracks path and the resume were fine, from the point where they had stopped.
So I changed the path (from Music\somefolder\song1 to \Music\somefolder\song1), saved the playlists, copied them to the player and the problem went away.
The change of the path was easily performed with Notepad: replace "Music" with "\Music", replace all, and save as m3u.
I hope this helps.