Position not remembered.
It seems that after my Droid Incredible updated to Froyo 2.2 it does not remember where I left off in podcasts after I reboot or chard the phone. Any Ideas on how to fix this?
+1 This seems to be the same issue I'm having but mine is when the DoggCatcher is either closed manually or I guess closed in the background by Android.
This is extremely frustrating and never had this problem before. Also a Dinc with 2.2
It sounds like the incredible on 2.2 does not seek properly.
What's probably happening is that DC is remembering the position. The app is exiting, and when it is restarted, DC loads the media file and seeks to the remembered position, but the seek is failing.
We can verify that DC is trying to seek to the correct position by inspecting the logs. If one of you could play an audio file for at least 30 seconds, exit the app (in the dc menu), then restart the app, and then send me the log file noting the approximate position where the audio file was playing when you exited the app.
Just sent you the log eric. Hope its something easy to fix.
Ok, so DC is seeking to the proper position after you restarted.
It seeked to 1620567 which when you divide by 60000 (one minute worth of milliseconds), you get 27...in minutes.
The MediaPlyaerService log entries below are actually coming from the android media player, not DC. So the media player is getting the instruction to seek to 1620567, but it doesn't seem to be honoring the request.
09-04 00:38:05.667 I/DoggCatcher( 9223): MediaPlayerController::PlayOrPause - [25ms]
09-04 00:38:05.687 I/MediaPlayer( 9223): MediaPlayer handleMessage what=5
09-04 00:38:05.687 I/MediaPlayer( 9223): MediaPlayer handleMessage what=1
09-04 00:38:05.687 V/MediaPlayerService( 69): getDuration
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] getDuration = 4289610
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] seekTo(1620567)
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] notify (0x3d390, 4, 0, 0)
09-04 00:38:05.687 I/MediaPlayer( 9223): MediaPlayer start()
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] setLooping(0)
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] setVolume(1.000000, 1.000000)
09-04 00:38:05.687 V/AudioSink( 69): setVolume(1.000000, 1.000000)
09-04 00:38:05.687 V/MediaPlayerService( 69): [173] start
09-04 00:38:05.687 D/AwesomePlayer( 69): [U5B] play (556)
09-04 00:38:05.687 D/AwesomePlayer( 69): [U5B] play_l (562)
09-04 00:38:05.687 V/AudioSink( 69): open(44100, 1, 1, 4)
09-04 00:38:05.687 V/AudioSink( 69): setVolume
09-04 00:38:05.687 V/AudioSink( 69): start
09-04 00:38:05.687 D/AudioPolicyManagerBase( 69): startOutput() output 1, stream 3
09-04 00:38:05.687 D/AudioHardwareQSD( 69): Enable ALT for speaker
09-04 00:38:05.687 D/AudioHardwareQSD( 69): ALT batt temp = 318
09-04 00:38:05.687 D/AwesomePlayer( 69): [U5B] play_l (635)
09-04 00:38:05.697 I/DoggCatcher( 9223): DoggCatcherWidgetProvider::Updating widget - [4ms]
09-04 00:38:05.707 I/DoggCatcher( 9223): DoggCatcherService::KeepAliveCount: 1 - [com.snoggdoggler.android.mediaplayer.MediaPlayerController@45d50fe8] fg: true - [14ms]
09-04 00:38:05.717 I/DoggCatcher( 9223): DoggCatcherWidgetProvider::Updating widget - [6ms]
09-04 00:38:05.717 I/DoggCatcher( 9223): MediaPlayerController::Prepared -> seeking media to 1620567 - [32ms]
FWIW, this issue doesn't affect video playback or even the new play as audio feature. Both those resume fine after an exit or changing files. Its just straight audio.
Since the play as audio feature basically takes a video file and runs it through the same code as audio files, that makes it seems like the audio player is failing to see only for certain mime types.
So what happens if you use the seekbar while an audio file is playing, does that work?
The reason I ask is that in the circumstances where you are running into the problem, DC loads the media files, seeks, and then starts to play.
If the seekbar is working for you then maybe the seek failures only occur if the audio hasn't started playing yet.
Earlier I tried doing the play first and then seek, but it resulted in some screeching while it was seeking.
Yes. Using the seek bar once audio has started playing works perfectly. The issue is only when the audio isn't playing. Any chance of using that for a fix or workaround ? Maybe play audio first then do the seek? Happy to test.
I just posted a beta that has this change. Please let me know how it goes.
Thanks.
Update: The latest beta while working initially still oddly seems to have the resume issue. I've sent logs to support to hopefully figure out what happened. It was a bit of a tease. :)
HTC Evo with Froyo 2.2 (Rooted running Fresh 3.2 ROM)
I'm ok with screeching if it will remember my position. Heck, mute the audio, seek and turn the volume back up?
I'm running a Droid Incredible with Android 2.2.
I'm having the same issue when re-starting DoggCatcher.
Any podcasts previously listened to are shown correctly in the audio listing. That is to say you can visually see how much has been listened to by the graphical bar. However, when attempting to resume a podcast, the track is restarted from the beginning.
At the bottom where the seek bar is located, the bar is always positioned at the beginning of the file even when you have already listened to a portion of the file.
If you execute
# setprop media.stagefright.enable-player false
Then you will use the original player, and the resume works perfectly.
Jim
Thanks for the tip...wish I could do that from inside the app.
This is happening with my EVO also. Is there any way to install an older version until this is fixed?
The bug is in the EVO rom, so older versions of DC won't help.
I've got a workaround that has worked for some EVO users that have helped me out...I'll be releasing it tonight.