- Status Closed
- Percent Complete
- Task Type Bugs
- Category Music playback
- Assigned To No-one
- Operating System SW-codec
- Severity Medium
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#7257 - Playback resumes while paused when pressing back
This is a fresh build on an iPod 5G. I downloaded the latest source and manually built it on kermit.pimpinwithmuppets.com build server.
What happens is if I pause the playback, then hit the back button to go back to the beginning of the song, it does go back to the beginning of the song, but resumes playback. On my custom WPS, it still shows “paused”, but the counters do count and it does play the music. If I hit pause/play, it will change the status of playback only, but does not affect actual playback. Hitting pause/play once again will pause playback.
This is not a new bug to me. When I last encountered it, I downloaded the latest source and built it on my build server, and it appeared to be fix. Unfortunately, I don’t have build releases and dates to back this up.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Confirmed on H320 with svn r13533
This seems to be intermittant. Results with conditions:
Bug occured while only thing plugged into it was headphones.
Bug occured while nothing plugged in (plug in headphones or speakers later to hear playback).
Bug did not occur while plugged into car charger adapter (everything worked properly).
So far the pattern is the bug happens when nothing is plugged into the accessory/power port.
I am also seeing the same problem with both my iPod 5.5G and my iPod Nano with the current SVN build from 5 Jun 10:11.
Unfortunately there is no longer a pattern to this problem as it occured while plugged into my car adapter today. It’s like it maybe stores the state, maybe doesn’t. Russian roulette if you will.
It happens here reliably on my H340 (no car mode in use). It also happens in the sim, but I think that’s due to a separate problem.
It also happens here every time on both my iPod nano and 5.5G iPod video.
I have not tested on my h140 as I have lent it to a friend,
but I can get it back to test on as well if it would help.
The problem also happens if I fast forward when pause as well as rewind on both DAPS.
Confirmed on Cowon IAudio X5 with rockbox-iaudiox5-20070624
I think it’s just a problem on SWCODEC in general and happens on all my players. I’m not sure why it happens but I did check and it doesn’t seem to be a bug in the playback engine but likely in the pcm buffer perhaps due to some refilling triggering pcm playback. I plan on taking a closer look later.
After a lot of testing this morning looking for the commit that caused ‘“Pause on Headphone unplug” option no longer works on IPods.’ (http://www.rockbox.org/tracker/task/7261) I think I have also found the commit that seems to causes this bug.
“19 May 19:30 Marcoen Hirschberg always reset the pcm_paused flag when stopping playback. fixes FS #7187”
As all builds tested before this commit do not show the rewind problem and all builds afterwards do.
I don’t know if this is the right approach, but the attached fixes the problem for me (plus
FS#7261) and as far as I can tell doesn’t break the fix forFS#7187Did you mean “pcm_paused = audio_status();” in playback.c? I’ve not tried the patch yet, just looked at it.
I’d think that it shouldn’t be necessary to actually test andr modify the pause status like this; can it not be regarded as independent of the stop/play status? There would need to be a different fix for
FS#7107, of course, so as not to assume that the two are tied in.I’m right in the middle of redoing the pcm layer a bit for all targets to be atomic with locks against the audio interrupt and to give the pcm buffer its own play/paused state. This patch definitely isn’t the right approach for a permanent fix since the problem really lies deeply in the playback.c behavior (yes, I take back the above comment in part) and the way it tracks its state in combination with some kludges in pcm. The pcm layer cannot concern itself with the audio status since it’s something that can be used independently of core playback.
I can confirm that the patch seems to fix both bugs on my iPod nano and video 5.5G.
That playback code really should read “pcm_paused = false;”. audio_status() doesn’t return a bool for starters.
Sorry, yes, it should. The change to pcm_playback.c was a remnant of me playing around, it should have been the same change as the other files. But as Michael said, it’s not the right way of fixing it anyway.
However, we could fix it with this patch until Michael does it the right way.