Rockbox

What kinds of files (codec) are affected? Is it always or just sometimes? Does it only affect long files?

not sure if its related, but I just updated to r16156-080124 on my X5 and my resume playback is broken also. I get a short(but loud) buzz sound before resume starts, this happens even when switching from stop mode(long play) to 'resume playback' also, if you stopped in the middle of a song.

I was also getting somewhat frequent track truncation, it would go to the next song before the current one was finished, if i went back and FF to the end of the track, i could hear the ending fine.

the files i noticed it on was a VBR mp3 files. I reverted back to an older rockbox ver. and both problems went away.

Jim, could you maybe try to pinpoint the exact revision with which the issue started to appear? It would be very useful to know. You can do a binary search between the one you know is faulty and the one you know is ok; it shouldn't take much tries before you find the exact first faulty one.

Are there archived copies of old builds anywhere? I couldn't find any :-(

I have the same problem on my Sansa E250 and it started with the r16105-20080119 build (it works for me on the r16099-20080118 build).
In fact, playback in general got very flaky right around that time.
Some MP3 tracks, such as the podcast edition of "Wait, Wait, Don't Tell Me", won't play at all.
Some OGG CD rips play but they may take a long time to start playing the first time, or the controls will freeze for several seconds when playback begins.

Looking at the changelog, I think it's most likely the spinlock patch(es) that caused some of these problems (not that I know what's wrong with them).

matt: I've found archived builds by going here: http://www.rockbox.org/daily.shtml and clicking on the "old" link below the model you have.

Awesome, thanks Charles for the link

Yup, I can confirm mine bites it on 16105, but works as usual on 16099. and it goes from bad to worse on the next version up; spinlock being the one thing that change on both versions. not that i've even blinked at the source yet.... thanks for the pinpoint charles! I didn't realize how hooked on rockbox I had become, my audio routine had been seriously altered ;-)

I haven't tried really looking at the source code yet either, but this looks like the kind of complex change that requires a holisitic understanding of the enitre structure of the OS. Not the sort of thing for a new developer [me] dipping their toes into the project for the first time to try to work on.

I do find it interesting that the bug so far seems to occur on MP3 files (which are presumably decoded by special hardware in the Sansa), but not on OGG files which are decoded in software. That, and the fact of a recent spinlock/mutex patch makes it seem like it is almost certainly a hardware/thread synchronization issue. And they can be REALLY hard to debug. I wonder if anyone can reproduce it in a simulator?

Matt: I think the spinlock patches look like they were specific to the r16105 version. Their repetition on the r16114 page is probably a side-effect of the way the changelogs are generated.

All files are played in software on the Sansa, including MP3. I believe it may be a race issue in the playback engine. Maybe the playback starts before the audio codec is initialized properly?

I signed up because this is really beginning to annoy me and I've got more information that could help.

The resume function has also broken on my iriver H140 with my last rockbox update (no more than 2 weeks ago). I don't run files under 60mb. Resume on MP3 files seems to work fine. However, none of my OGG files will resume, the player automatically moves to the next file.

It seems strange that on other machines it's the MP3s that won't resume, whereas on my iriver it's the oggs. Unfortunately I don't know any programming so I can't hypothesise why that might be.

I haven't tried really looking at the source code yet either, but this looks like the kind of complex change that requires a holisitic understanding of the enitre structure of the OS. Not the sort of thing for a new developer [me] dipping their toes into the project for the first time to try to work on.

I do find it interesting that the bug so far seems to occur on MP3 files (which are presumably decoded by special hardware in the Sansa), but not on OGG files which are decoded in software. That, and the fact of a recent spinlock/mutex patch makes it seem like it is almost certainly a hardware/thread synchronization issue. And they can be REALLY hard to debug. I wonder if anyone can reproduce it in a simulator?

Matt: I think the spinlock patches look like they were specific to the r16105 version. Their repetition on the r16114 page is probably a side-effect of the way the changelogs are generated.

Yikes! Sorry about the last comment, I shouldn't have let Firefox Repost when I refreshed the page.... Doh!

Anyway, I still don't think anything more recent than r16099-20080118 will be useful until this is fixed.

It happens to me as well starting with the 161xx SVN. I'm using an E200R Rhapsody, and use primarily 128Kbit MP3's and over 90 percent of the time when I power off the player, the track resumes at the beginning of the track instead of where it stopped.

Build 16096 (the one I'm using to help check a battery life extension patch) works fine. But any SVN's after it, breaks resume playback on power up.

It is a very annoying bug, and I hope someone who knows about the build history can find out what change caused it.

In the meantime, it looks as if 16096 will be the last build I use until I see this repaired.

So 16096 works, but 16097 doesn't? That doesn't make sense, the change was only to the manual.

16096 is the one I'm using because it is the latest one with the the battery mods I'm using.

I think 161xx is where it started. 16105 is where people say that it started, so I think the 160xx series should be fine. My previous post was inaccurate. 16096 is the last one built with the battery optimizer patch that I can use, so that's what I meant.

Reproduction Steps: (For any Devs that may be watching)

1. Power On Player
2. Set Start Screen to Resume Playback (Settings/General Settings/System/Start Screen
3. Queue up a list of songs via database (I use Albums All Tracks)
4. Set Shuffle Mode On (I don't think its related, but thats how I normally use the player)
5. Start playback of a song, Let the song play at least 15 to 20 sec.
6. Power off the player, note position in song during power off.
7. Restart the player.

After Reboot, briefly, the player will show the last position you started at (depending on your WPS) and then quickly reset to 0:00 and restart the song. Sometimes the Resume feature will work, approx. 10% of the time, and sometimes the player will skip to the next track. I can't accurately reproduce it working normally or the skip ahead, but the restarting the track happens the most anyway.

I have exactly the same problem with my Iriver H320. 16099 is working fine but not the newest versions. I only have OGGs so I don't know if the auto resume works with MP3.

This also happens on my Sansa E280

When I listen to a audio book and then switch off the player.
The next time I switch it on, the position rewinds to 00:00 and the track counter increments but it is still the same track.
its especially annoying when you are listening to a book.

I signed up to just to confirm my experience with this on the iPod 80 GB (gen 5.5).

After a power cycle, 'Resume Playback' reverts to the beginning of the track for mp3, and skips to the beginning next track in the playlist with ogg.

I am currently using the Feb. 13, 2008 build, but builds from the last few days are also definite culprits. I've updated a few times over the last few days, and reverted all settings.

It's an annoying problem for me because I listen to long podcasts intermittently in the lab, with long periods of office work in between lab sessions. So I'd just like to add a vote that this be addressed.

Thanks. Otherwise I just love this software.

Just want to confirm this bug on a Sansa E270. I first noticed the problem with the build from (or around) 1/21/2008. Yesterday I installed the 2/18/2008 build and there is still a problem with auto-resume and .mp3 files.

Interestingly, the problem didn't manifest itself immediately. The first half-dozen or so times I powered down and back up, resume seemed to work fine but today, it's skipping to the beginning of the next track again. (With the 1/21/08 build it would also sometimes skip back to the beginning of the current track and play from there...)

I've just downgraded to 16099 build to see if the problem goes away, as others have suggested.

Doh... make that 'Yesterday I installed the 2/12/2008 build...'


So far 16099 seems to be ok.

For me the current build r16346 works and resumes both ogg and flac (the only file types I use). The previous build I had r16290 didn't work, so some how this was fixed between those two revisions. I tested the current revision on both a Gigabeat F40 and iPod Mini 1st Gen 4GB. Resuming an audio file works perfectly for me now. Hopefully you all can test the newest build and see if it works you guys too.

I've just tried the 16354 build (Iriver H320) and it still doesn't work ! Worst of all : I can't find the 16099 anymore ! Can anybody help me ?
Thank you,
Denis

16354 didn't fix nothin on my 4th gen grayscale. still with 16099. as for finding 16099, wow, that's a bummer...

r16354 does not fix the problem. I updated to today's build and auto-resume is still as broken as it was.

Anyone have a copy of 16099? I accidently rm'd mine (d'oh!)

wait a minute, turns out I do have 16099 for the ipodvideo64mb. I'll post it here.

Tried attaching to my post but it didn't work. If anyone needs 16099 for the ipodvideo64mb, email me at my profile address.

I still need the r16099 revision ! But I suppose the ipodvideo64mb version won't work on my iriver H320... Sigh !

Could this be related to a bookmarking issue? Starting at around the same time, there have been reports that bookmarks don't work correctly. The player goes to the correct track and then starts the track from the beginning instead of at the bookmarked time. I am looking for a working build of the iaudio X5. If anyone has one they can send me, I'd appreciate it.

I don't use bookmarks...

There might be an improvement on this issue with r16392. Could someone report?

The current revision seems to have cured the problem on my Sansa E280.

i guess it was the fix from "23 Feb 17:46 Magnus Holmgren" that did the job.

Thanks.

Now it's atarting from the correct position of the file
(IPOD 5.5G). I am using r16374.
Thanks!