Bug 12792 - play/pause/power switching responsiveness issues
: play/pause/power switching responsiveness issues
Status: RESOLVED WORKSFORME
Product: SqueezePlay
Classification: Unclassified
Component: UI
: unspecified
: PC Windows XP
: P1 major (vote)
: 7.5.0
Assigned To: Wadzinski Tom
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-11 04:30 UTC by Philip Meyer
Modified: 2009-11-03 11:43 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Meyer 2009-07-11 04:30:49 UTC
Trying SBT with noweb-sqlite branch tonight, having got a scan to complete (not totally successful, but I seem to have something at least).

I was interested to try out a fix that had been applied for Bug 3161 "Need more agressive auto-retry for internet radio".

I started with local music library playback, and I'm seeing lots of weirdness.  May not be associated with the fix for 3161 - not sure.

I use my SBT to control a Boom.  I started playing an album, and whilst playing I hit the power button on SBT home menu to turn off the Boom player.  The music continued for a good 10 seconds before stopping (I'm used to music immediately stopping).

I turned the power back on, and music started to play back instantly.
I pressed pause, and there was a delay before pause took effect, similarly when I pressed play there was a pause before playback resumed.
I then tried pause/play again a few times, and it seemed to be functioning normally.

But then with rapid pause/play touches, the SBT UI got very confused.  I got stuck in states where the box said it was paused, but the music was playing and the progress bar was updating.  Then the opposite - I had a play button, but the music was paused.
Comment 1 Blackketter Dean 2009-07-22 10:48:13 UTC
Moving to the product SqueezePlay because this bug appears to apply to any
player based on that application code.  Feel free to move it back if it's
specific to the single original product.
Comment 2 Ben Klaas 2009-08-26 07:53:30 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 3 Wadzinski Tom 2009-10-03 12:34:45 UTC
might not be an issue anymore. will retest before estimating...
Comment 4 Wadzinski Tom 2009-10-26 10:59:35 UTC
Nered to test to confirm
Comment 5 Wadzinski Tom 2009-11-03 11:43:50 UTC
I don't see any of these issues in the current software.