• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.12
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mikebomb - 2013-05-24
Last edited by speachy - 2021-09-20

FS#12864 - Automatic Resume behavior inconsistent on 3.13

This may be all players; I have only had experience with the Sansa Clip+ and Clip Zip. On version 3.13 the Automatic Resume feature works inconsistently, especially on the 2nd+ file of a playlist.

In version 3.11.2, the feature worked correctly on my Clip+. If I paused the player and the player turned off due to the timeout, when I turned the player back on and pressed the “Home” button or “Resume Playback”, the entire playlist would be back in place and playback would resume at the spot I paused. If I was 30 seconds into the third file in a playlist, playback would resume at that point. When that file finished, the next file in the playlist would start. Pressing “Previous” or “Next” would play the previous or next file in the playlist.

In version 3.13, this feature does not always work correctly. In fact, it rarely works correctly when playing a file that is not the first file in a playlist. Some times it works fine. Most times when I try to resume playback, it instead plays the beginning of the first track in the playlist. Some times when that happens, if I manually navigate to the track I was in when I paused, it will resume that track from the correct position rather than starting it over from the beginning.

This behavior is seriously agitating. I use my player to listen to multi-hour podcasts broken into separate files for each hour. If I get a phone call and pause my player I expect my player to automatically shut itself off after a few minutes, and it does. When I start the player again, I want to be able to pick up just where I left off. On versions prior to this, I could. In 3.13 it does not work 9 out of 10 times.

Closed by  speachy
2021-09-20 20:07
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Only took eight years. :)

I have this problem when I:

1) Stop playing, automatically creating a bookmark
2) Plug my Clip+ into the computer, and add files to the directory. (This problem only seems to occur if the file I added end up sorted earlier on the list (i.e. alphabetically) than the file I was playing)
3) Unplug my Clip+ and turn it back on.

Automatic Resume starts the correct file, but from the beginning of the file instead of the saved point.

My workaround: Enable a List of Recent Bookmarks and use that to play the file. Everything plays as expected.

This behavior is not connected to "Bookmark on Stop" and "Enable List of Recent Bookmarks." I do not have "Bookmark on Stop" set and do not want to create a bookmark every time I stop playback. I use bookmarks and have "Enable List of Recent Bookmarks," but I use them to track which playlist I am listening to and bookmark inside a playlist only when I want to stop listening to one playlist and listen to another for a while. That enables me to resume the first playlist where I left off. Bookmarking has been working perfectly for a long time and is so important to me that it is THE reason I insist on Rockbox and players that support it. I would find something like an iPod unusable because it has no Bookmarking.

The bug I am reporting has to do with the Automatic Resume feature, which most players have, including the iPod and the stock firmware on the Clip+ and Clip Zip. When the player is turned off during playback (including when the player is paused during playback), whether manually or by timing out, the player should resume both the playlist and the track at the point the player was when it was turned off.

This feature worked fine at least through version 3.11.2. I never loaded 3.12 so I cannot comment on it. The feature no longer works correctly in 3.13

I can report exactly the same problem with my Clip+. Every few days I transfer a playlist of around 10 - 12 podcasts. Automatic Resume sometimes works for the first two or three restarts, but once it goes wrong and reverts back to the first file, it does it every time until I transfer a new playlist. As I usually have the Clip on my belt underneath overalls (and often with dirty hands) this is obviously very frustrating.

I have no idea about the workings of Rockbox, but out of interest I have tried: 1) pausing playback and letting the Clip+ turn itself off; 2) pausing playback and turning the machine off; 3) turning the machine off while the track is still playing. But in all cases the result is the same.

I only Rockboxed my Clip Zip last week, but used the Auto Resume function on that successfully to listen to a 110-track audio book over roughly 10 sessions, so I wonder if the problem is confined to the Clip+.

No, I had this behavior on both a Clip+ and a Clip Zip.

I wish we could get someone on the development team to take interest in this.

I can also report that in 3.13, the "Resume Playback" on "Startup/Shutdown → Start Screen" no longer works correctly. It will remember the last played position only for the first track in the dynamic playlist, but if I switch off the player while playing any other track other than the first track in the dynamic playlist, on power on again, playback will resume from the start of the first track in the dynamic playlist.

The above behavior happens on both my Clip+ and FuzeV1 when 3.13 is loaded.

I have reverted back to 3.12, and both Clip+ and FuzeV1 now have the correct "Resume Playback" behavior.

So something changed between 3.12 to 3.13 that broke "Resume Playback"

I just want to point out that the reported version is marked as 3.12, but it's 3.13 that it's happening on. I had to revert to 3.12 because of this bug. I am using an iPod video. It would be nice if someone could figure this one out.

It was reported as 3.12 because at the time I reported it, that was the latest version I could choose. 3.13 was not an option. I made it clear that the behavior actually occurred in 3.13 in the Bug Title.

I have twice or three times logged on to the IRC asking if a developer would take a look at this. I have yet to see a response and from the header of the bug, it appears that no developer has yet taken this on.

I was trying to reproduce it and it seemed to be working fine now. I don't know what was different except that I didn't leave it on very long. I was going to do a git bisect to try to find the first revision it went bad, but if I can reproduce it quickly that becomes rather hard to do.


jumping onto IRC for 5 minutes when almost all the devs are asleep is really not helpful…

If you want to see this regression(?) fixed the absolute best thing you can do is bisect the changes and narrow it down to the git commit which broke it. That means downloading the source, find the a known good version, then using "git bisect" find roughly where it broke.

Sorry, I do not know who the developers are or where they live, so I really do not know when they are asleep. In any case, I thought they would see the post whenever they logged on. I cannot do what you suggest because I have no familiarity with Rockbox's programming language, source code, Linux, etc. I am just a stupid user who wishes that one of his favorite Rockbox features had not been broken and would be fixed.

If you feel that you are just a stupid user then there isnt much you can do but sit and hope someone cares about this issue (which by the looks of it isnt really going to happen). If however you realise that everyone helping out was in your position at some point in time - then chances are you will be able to at least find the broken commit (which is the tedious and difficult part) so someone else can do the coding part to fix it.

so, goto and download the development virtual maching that you can run in virtualbox, then and follow the steps to build and run your own rockbox build (you can ignore the "before you start" heading). Once you're at that point (which is the trickiest part really) come on IRC and I (or anyone online) will gladly help you with git bisect which will help you identify exactly which change broke this behaviour.

This may be the same as FD#13126, in which case this has been fixed in master.

This may be the same as FD#13126, in which case this has been fixed in master.

This may be the same as  FS#13126 , in which case this has been fixed in master.

Sorry about the triple post.

And the incorrect FS: The correct FS# is  FS#13136 

It is the same, and thank you very much!


Available keyboard shortcuts


Task Details

Task Editing