Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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
Attached to Project: Rockbox
Opened by Beau Steward - 2007-06-04
Last edited by Linus Nielsen Feltzing - 2007-07-05

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.

Closed by  Linus Nielsen Feltzing
2007-07-05 11:18
Reason for closing:  Fixed
Nils Wallménius commented on 2007-06-04 16:24

Confirmed on H320 with svn r13533

Beau Steward commented on 2007-06-04 21:39

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.

Douglas Valentine commented on 2007-06-05 16:52

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.

Beau Steward commented on 2007-06-06 05:00

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.

Steve Bavin commented on 2007-06-12 08:41

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.

Douglas Valentine commented on 2007-06-12 11:16

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.

Sarixe Avaliesz commented on 2007-06-25 12:02

Confirmed on Cowon IAudio X5 with rockbox-iaudiox5-20070624

Michael Sevakis commented on 2007-06-26 02:34

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.

Douglas Valentine commented on 2007-07-04 12:54

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.

Robert Keevil commented on 2007-07-04 18:53

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 

Steve Bavin commented on 2007-07-04 19:02

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.

Michael Sevakis commented on 2007-07-04 19:40

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.

Douglas Valentine commented on 2007-07-05 09:23

I can confirm that the patch seems to fix both bugs on my iPod nano and video 5.5G.

Steve Bavin commented on 2007-07-05 09:28

That playback code really should read “pcm_paused = false;”. audio_status() doesn’t return a bool for starters.

Robert Keevil commented on 2007-07-05 09:41

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.

Admin
Linus Nielsen Feltzing commented on 2007-07-05 10:00

However, we could fix it with this patch until Michael does it the right way.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing