Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#7257 : Playback resumes while paused when pressing back



FS#7257 - Playback resumes while paused when pressing back

Attached to Project: Rockbox
Opened by Beau Steward (Nimdae) - Monday, 04 June 2007, 03:47 GMT
Last edited by Linus Nielsen Feltzing (linusnielsen) - Thursday, 05 July 2007, 11:18 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This is a fresh build on an iPod 5G. I downloaded the latest source and manually built it on 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.
This task depends upon

Closed by  Linus Nielsen Feltzing (linusnielsen)
Thursday, 05 July 2007, 11:18 GMT
Reason for closing:  Fixed
Comment by Nils Wallménius (nls) - Monday, 04 June 2007, 16:24 GMT
Confirmed on H320 with svn r13533
Comment by Beau Steward (Nimdae) - Monday, 04 June 2007, 21:39 GMT
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.
Comment by Douglas Valentine (Dwyloc) - Tuesday, 05 June 2007, 16:52 GMT
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.
Comment by Beau Steward (Nimdae) - Wednesday, 06 June 2007, 05:00 GMT
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.
Comment by Steve Bavin (pondlife) - Tuesday, 12 June 2007, 08:41 GMT
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.
Comment by Douglas Valentine (Dwyloc) - Tuesday, 12 June 2007, 11:16 GMT
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.
Comment by Sarixe Avaliesz (sarixe) - Monday, 25 June 2007, 12:02 GMT
Confirmed on Cowon IAudio X5 with rockbox-iaudiox5-20070624
Comment by Michael Sevakis (MikeS) - Tuesday, 26 June 2007, 02:34 GMT
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.
Comment by Douglas Valentine (Dwyloc) - Wednesday, 04 July 2007, 12:54 GMT
After a lot of testing this morning looking for the commit that caused '"Pause on Headphone unplug" option no longer works on IPods.' ( 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.
Comment by Robert Keevil (obo) - Wednesday, 04 July 2007, 18:53 GMT
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 for  FS#7187 
Comment by Steve Bavin (pondlife) - Wednesday, 04 July 2007, 19:02 GMT
Did 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.
Comment by Michael Sevakis (MikeS) - Wednesday, 04 July 2007, 19:40 GMT
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.
Comment by Douglas Valentine (Dwyloc) - Thursday, 05 July 2007, 09:23 GMT
I can confirm that the patch seems to fix both bugs on my iPod nano and video 5.5G.
Comment by Steve Bavin (pondlife) - Thursday, 05 July 2007, 09:28 GMT
That playback code really should read "pcm_paused = false;". audio_status() doesn't return a bool for starters.
Comment by Robert Keevil (obo) - Thursday, 05 July 2007, 09:41 GMT
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.
Comment by Linus Nielsen Feltzing (linusnielsen) - Thursday, 05 July 2007, 10:00 GMT
However, we could fix it with this patch until Michael does it the right way.