Rockbox

Tasklist

FS#12864 - Automatic Resume behavior inconsistent on 3.13

Attached to Project: Rockbox
Opened by Michael Bauminger (mikebomb) - Friday, 24 May 2013, 05:18 GMT
Task Type Bugs
Category Music playback
Status Unconfirmed
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Release 3.12
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

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.
This task depends upon

Comment by menachem shapiro (menachem) - Friday, 24 May 2013, 05:57 GMT
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.
Comment by Michael Bauminger (mikebomb) - Friday, 24 May 2013, 22:46 GMT
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
Comment by Richard Thompson (hungerdunger) - Saturday, 08 June 2013, 19:30 GMT
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+.
Comment by Michael Bauminger (mikebomb) - Sunday, 09 June 2013, 08:16 GMT
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.
Comment by Leon (travelfotografer) - Wednesday, 12 June 2013, 04:49 GMT
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"
Comment by Albert Bloomfield (abloomfield) - Friday, 16 August 2013, 18:13 GMT
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.
Comment by Michael Bauminger (mikebomb) - Friday, 16 August 2013, 19:57 GMT
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.
Comment by Albert Bloomfield (abloomfield) - Sunday, 18 August 2013, 18:42 GMT
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.
Comment by Jonathan Gordon (jdgordon) - Friday, 15 November 2013, 05:58 GMT
Michael,

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.
Comment by Michael Bauminger (mikebomb) - Friday, 15 November 2013, 07:51 GMT
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.
Comment by Jonathan Gordon (jdgordon) - Monday, 18 November 2013, 09:30 GMT
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 http://www.rockbox.org/wiki/DevelopmentGuide and download the development virtual maching that you can run in virtualbox, then http://www.rockbox.org/wiki/HowToCompile 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.

Loading...