Hitting Pause Button causes jump backwards in playback when I resume
Every time I pause a podcast, usually by hitting the pause button on my headset, it skips backwards in time when I resume. It almost seems to correspond to the time it's been paused. IE if I pause for two minutes, the show has jumped back about two minutes when I resume. It's almost as if there's some internal backwards-running clock designed to make me go insane from hitting resume. This is on the latest version of the app and a 2.2 Nexus One. Same problems existed in 2.1... I am not talking about the clock display or time played. I rarely look at the device. I'm talking about the audio actually jumping backwards in time when I finally resume.
I've got an open bug on this one - http://mantis.snoggdoggler.com/view.php?id=546
I added a reference to this post.
Thanks for posting.
I was running 1.1.1390 and didn't have this problem. I've just upgraded to 1.1.1462 and now I'm getting the rewinding.
What device and android version are you on?
Phone is T-Mobile G2, aka HTC Hero.
DC is version 1.1.1462.
Up to yesterday my phone was on Android version 1.5 and I was getting the error. Last night I upgraded to 2.1 and from the very brief test I just did - pause playback, lock phone, wait a couple of minutes, unlock and resume - it seems to be OK now.
I also uninstalled/reinstalled DC earlier because of a different error, so not sure whether it's that or the OS upgrade that's fixed it.
Let me know if it happens again.
I checked the code differences between those two version and didn't see anything that jumped out at me. If it happens again, we could consider getting you back to 1390 as a test just to be sure.
I am having the exact same problem and have been having it for the last several versions of doggcatcher. It appears the podcast progress clock lags behind real time. I timed the podcast progress clock with a stopwatch and for one minute of real time the progress clock only advanced about 40 seconds. So when I resume after pausing it takes me back to the progress time duration even though it's actually way behind the actual duration that I have listened. And the longer you listen to a podcast the more out of wack it becomes causing it to skip back 5-10 minutes if you have been listening for a while. I am running the latest version of Doggcatcher 1.1.1462 on a Motorola Droid running Android 2.2.
So...
Does this happen with all podcasts or just some (or one)?
Does this happen when you push the pause button and then play immediately afterwards or is this after DC has been idle for a while? From your description it sounds like immediate.
Which rom are you using, I didn't think the droid was on 2.2 yet?
Is this for downloaded audio or streamed audio?
I'm not too surprised by audio strangeness in 2.2. The audio engine was replaced with a different one in 2.2. I've notice a couple times that a pause and immediate resume resumes to a position about 10 seconds earlier than it should. That's pretty interesting what you noticed about the progress clock being out of synch with real time.
There's one bit of my code that I need to verify to see if it's a DC or android problem. If when you press pause and then play, DC is just telling the mediaplayer to pause and then resume, then it's likely the problem is in android. If DC is pausing, then seeking to the new position, then playing, I might have a problem with where I am seeking to.
I'll check it out and get back to you.
I found that when DC was pausing and then resuming, it was doing a seek to the play position right before the resume. This shouldn't be a problem, but it may be causing some of the strange behavior people are experiencing.
Since it is unnecessary to do the seek when resuming the same audio file, I removed it. I referenced a mantis issue at the bottom of this thread but that really is a different issue, so I created a new one for this issue - http://mantis.snoggdoggler.com/view.php?id=580
It will be in the release after next.
It would be great if someone that is still experiencing the problem could join the beta group to test this out so I know things have improved. If you are interested, please send me an email and I'll set it up. I should get this to the beta group this week.
It only happens with shows from 2 podcasts both of which are from the same site (smodcast.com). The same thing happens when I play the files in the stock android music player where the duration clock lags behind actual time. But when I resume after pausing in the stock player the audio begins where I left off listening and not the location of the duration clock. But with Doggcatcher after resuming from pause it plays the location of the duration clock which behind what I have actually listened to whether I resume immediately or after DC has been idle for a while.
I am using the FRG01B Froyo rom on the Droid and listening to downloaded audio.
So what's going to happen with the update after next is just what happens with the android music player. The exception is when DC exits. Then you're going to resume back at where the duration clock is because the audio needs to get reloaded into the media player and seeked to the proper (or improper) position...that's going to put it at the clock position.
You might want to contact the publisher and let them know. They might be able to adjust the audio encoding parameters so that this isn't a problem any longer.
Hi, I've got an unmodified Moto Droid running 2.1, and my version of this problem is that when hitting resume after any amount of time paused, it begins playback anywhere from 10-30 seconds before OR after the point at which I paused it.
I have the exact same problem. I notice on all my podcast. The counter moves slowly, as a previous poster noted. I have a Moto Droid. I hope this problem is fixed because the player is unusable at this point.
Is this just with one feed or all feeds?
If the current position is not being correctly reported and there's either an encoding problem in the audio or a bug in the android media player. An encoding problem could possibly be corrected by the publisher.
The beta testers just got a release last night that will cause playback to resume in the correct position (as long as the app has not been exited). I don't think there's anything I can do about the position being reported incorrectly, I would know when it is being reported correctly or by how much.
If you want to join the beta to see if it helps, just let me know, you're welcome to.
Same problem here. Have original moto droid. This problem makes the app unusable for me. I won't use it until this is fixed. I read the release notes for the recent upgrade and still doesn't address the problem. However, I wonder if anyone has used it after the update and noticed if it was fixed.
The version with the fix for this has not been released to the market yet, but the beta testers do have it. I'm currently looking for someone to join the beta to confirm that it fixes the issue. If you want to join, let me know and I'll set it up.
If I can get the fix verified, I plan on releasing it to the market on Friday.
If DC had exited after you paused, then that is an issue that would not have been resolved by the fix in the beta. The beta addresses pause/resume while the app remains running.
I had suspicion that what you described could happen (based on a couple of other posts), but I wasn't sure.
Do you recall if you were using the widget in the morning or were you using the main UI?
I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=584
I just posted a new beta, please give it a try if you can.
Anyone else interested in joining the beta, just create an account here and email me the username...need some Droid X users, I know you're out there.
Thanks.
READ THIS
You're description of it seeming like there was some kind of 50% multiplier on how far forward the resume happened is exactly what was happening.
I created a faq article to explain the details behind this, what we can do about it and what is left over (what we can't work around).
http://www.snoggdoggler.com/node/972
Thanks to everyone for posting all the details here...this one was a little challenging to figure out but we got to the bottom of it.
I'm pretty certain that the reason the beta failed for you was that the app exited between the time you paused in the morning...you did other activities, and then resumed during lunch. This is covered in the faq article.
FWIW, I still experience this problem in Beta 1.1.1478.
I paused a podcast when I arrived at work this morning, used the phone for various other activities, and then during lunch, returned to Doggcatcher to resume listening. It was a good 30 minutes behind the point I'd paused earlier in the AM.