Bug 10524 - Playback restarts when paused
: Playback restarts when paused
Status: RESOLVED DUPLICATE of bug 10351
Product: SqueezePlay
Classification: Unclassified
Component: --
: unspecified
: PC Ubuntu Linux
: P2 normal (vote)
: 7.4.0
Assigned To: Richard Titmuss
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-01 15:54 UTC by radish
Modified: 2009-09-08 09:29 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
log file (2.87 MB, text/plain)
2009-02-02 09:26 UTC, Sue Chastain
Details

Note You need to log in before you can comment on or make changes to this bug.
Description radish 2009-01-01 15:54:51 UTC
I've noticed this a number of times now, as have some other commenters on the forum. Basically, when left alone paused the player sometimes seems to "partly" come out of pause mode and then gets somewhat confused. 

Details of the last time I saw this:

1. Started an album playing. 
2. Hit pause (on the fab4) and left it alone (screensaver was on).
3. Came back some time later to see the Now Playing screen showing. It was showing the last track of the album and the time counter was way out past the end of the track (i.e. it was showing something like 60 mins on a 4 min track) and still ticking. What was interesting is that the amp was on this whole time and it hadn't actually made any sound, so while it appeared to be playing it really wasn't. 

I also noticed that once this has happened the player wouldn't respond to commands from the screen or SC to play something else. Play/pause mode would change on demand but it was impossible to change the playlist, and whatever I did no sound would come out. This was fixed by a player reset (via the reset button). SC didn't need to be restarted.

I have tried leaving an SBC paused in the same way but haven't been able to reproduce the issue on that hardware.

I'm running the current latest nightly and associated Fab4 firmware:

Version: 7.4 - 24458 @ Thu Jan 1 01:14:58 PST 2009
Hostname: mrspuff
Server IP Address: 192.168.2.175
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: i686-linux
Perl Version: 5.10.0 - i486-linux-gnu-thread-multi
MySQL Version: 5.0.67-0ubuntu6
Total Players Recognized: 2

(ps it would be very useful if the Fab4 rev number could be reported on the status page).
Comment 1 Sue Chastain 2009-01-01 17:02:50 UTC
This pause glitch happened to me as well with SC 7.4 - 24458 running on Windows Vista. It's the same as described--I leave it paused and after a short time, the music appears to be playing again but there is no sound. It still advances through the playlist to where you lose your place when you resume playing. I have had it happen while playing albums as well as MusicIP mixes. I have been able to come out of it by going back to the song I was on and restarting playback.

I've also had the problem where a song will finish playing and then it gets stuck at the end with the time remaining showing -59:xx. The counter counts down to -59.30 and then resets to -59.59 and counts down again in a loop. It happened just now as I was typing this and it happened earlier today on another song. When this occurs, I have not found a way to get the music playing again except to unplug the power and reboot the Fab4--twice. After the second reboot it will restart playing from the beginning of the song that glitched and I can skip ahead to the next song.

(And, I'm not sure if this is specific to my Fab4 or not, but it always takes 2 reboots before I can connect to my server. The first time it never works. All this plugging and unplugging has me a bit concerned over the socket... it's already a bit wobbly.) 

This end of the song glitch might need to be a separate bug from the pause/unpause issue. I don't think they are related since the second issue has happened to me when the player was not paused.
Comment 2 Mike Cappella 2009-01-14 15:18:42 UTC
Happens repeatedly for me, in a very short amount of time.

Start a track on Fab4
Launch SP and connect to player above
On SP, hit space bar to pause.
Shortly after, playback will resume, w/o sound.
Hitting space bar again will say Paused.

firmware 3810, svn 24653.
Comment 3 Sue Chastain 2009-02-02 09:26:55 UTC
Created attachment 4739 [details]
log file

The Log starts from the beginning of the song "What's this Life for."
I paused using touch screen about 25 seconds into the song "What's this life for"
Fab4 status bar started incrementing in "chunks" as did the WebUI status bar, but neither were in sync. Fab4 was ~10 seconds behind what Web showed. Player stayed silent.
Status bar continued to advance ahead in "chunks" for the first song, but then when the next song started, the status bar went back to incrementing normally except there is no sound.
I paused again using WebUI 22 seconds into "Got my Mind Made Up (Original Version)" and it stayed paused.

SSH screen didn't show anything during all this--probably because Fab4 was only controlling squeezeplay and not playing itself.
Comment 4 Alan Young 2009-02-02 10:19:11 UTC
Sue, What player has MAC address 00:04:20:ff:ff:10? This is the one that was being controlled by the Fab4 in the log.
Comment 5 Alan Young 2009-02-03 10:21:40 UTC
Sue, what type of player was being controlled?
Comment 6 Alan Young 2009-02-03 10:24:33 UTC
The following extract from the log shows that the player is sent a pause command (after fade-out) but continues to play (silently, because of the fade-out), as indicated by the continuing advance of 'elapsed'. The latency of the response to the strm-p seems rather long.

[09-02-02 12:01:10.8314] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3140502, output_fullness=3512768, elapsed=19.863
[09-02-02 12:01:11.8463] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3145727, output_fullness=3520184, elapsed=20.913
[09-02-02 12:01:12.7568] Slim::Player::StreamingController::pause (1612) 00:04:20:ff:ff:10
[09-02-02 12:01:12.7820] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-audg: fullness=3143114, output_fullness=3525224, elapsed=21.813
[09-02-02 12:01:14.3031] Slim::Player::Squeezebox::stream (932) strm-p
[09-02-02 12:01:14.3036] Slim::Player::Squeezebox::stream (977) sending strm frame of length: 24
[09-02-02 12:01:14.3296] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3140502, output_fullness=3521120, elapsed=21.903
[09-02-02 12:01:14.3336] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3137890, output_fullness=3524432, elapsed=23.043
[09-02-02 12:01:14.3375] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-audg: fullness=3145727, output_fullness=3518600, elapsed=23.373
[09-02-02 12:01:14.3400] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMp: fullness=3145727, output_fullness=3518600, elapsed=23.373
[09-02-02 12:01:15.4864] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3143114, output_fullness=3513416, elapsed=24.093
[09-02-02 12:01:15.8269] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3145727, output_fullness=3525296, elapsed=24.843
[09-02-02 12:01:16.0623] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3145727, output_fullness=3523568, elapsed=25.083
[09-02-02 12:01:17.1851] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3143115, output_fullness=3517664, elapsed=26.223
[09-02-02 12:01:18.2508] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3140502, output_fullness=3525080, elapsed=27.273
[09-02-02 12:01:19.3767] Slim::Networking::Slimproto::_stat_handler (762) 00:04:20:ff:ff:10: STAT-STMt: fullness=3143115, output_fullness=3509960, elapsed=28.413
Comment 7 Richard Titmuss 2009-03-26 02:53:50 UTC
Alan, just to confirm are you saying that SP is ignoring the pause?
Comment 8 radish 2009-03-29 11:39:22 UTC
On initial testing this seems to be fixed with the combination of fw r5000 and SC r25724. I'm going to keep testing to confirm.
Comment 9 Dan Evans 2009-04-01 21:09:42 UTC
I continue to see this behavior, using r5048, while connected to SN.
Comment 10 James Richardson 2009-04-15 07:52:57 UTC
Alan: Could this be related to bug 9351
Comment 11 Alan Young 2009-04-15 08:02:19 UTC
Quite likely.
Comment 12 Richard Titmuss 2009-07-22 12:15:28 UTC

*** This bug has been marked as a duplicate of bug 10351 ***