Bug 14687 - Volume resets after playing an album
: Volume resets after playing an album
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Sync
: 7.4.0
: PC Windows Vista
: -- normal (vote)
: Investigating
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-08 20:53 UTC by Ritchie Argue
Modified: 2010-02-12 20:53 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ritchie Argue 2009-10-08 20:53:50 UTC
I have a problem with volume resetting to a previous value after an album is finished playing. It seems like it only occurs when I have multiple players synced.

Setup:
1 Squeezebox server

1 Receiver, not synced.

1 Receiver, synced, volume out locked to 100% (digital audio out)
1 Receiver, synced, volume variable (analog outs)
1 Boom, synced, volume variable

1 SB Classic thingy, not synced.


Summary:
All players are connected to the same server.
When I play an album on either of the unsynced players, if I adjust the volume, the volume remains at the adjusted setting after an album finishes. If I then select a new album, it plays at the previously set volume.
When I play an album on the synced players, the volume always starts off at some specific level (what the volume was at one point, when it stopped retaining it). If I then adjust the volume to a different level, it plays out the remainder of the album at this level. After the system stops, if I select a new album to play, it will play at the previous volume. When combined with bug 13922 this makes for some annoying interactions every time I select a new thing to play.

This occurred in 7.3.x. It resolved itself for a couple of days when I upgraded to 7.4, but has started occurring again.
Comment 1 James Richardson 2009-10-12 16:27:34 UTC
QA to investigate
Comment 2 Ritchie Argue 2009-10-12 19:53:04 UTC
I can add that it seems like my synchronized players are having trouble staying in sync now as well, and when they try to re-sync, the volume may reset. In addition one of the players may just cut out and stop playing instead.
Comment 3 Ritchie Argue 2009-10-14 22:06:41 UTC
Lately the following behaviour has been occurring:

- Sync group is playing at a volume of my choosing. Both Receivers show bright white playing indicator. Boom shows usual "now playing" screen.

- Sync group will pause, presumably because one of the clients needs to rebuffer, and the whole mess has lost sync.

- Sync group starts playing again.
  - The two wireless players (Boom, Receiver) reset their volumes to some consistent but arbitrary value (currently 20).
  - The Boom now playing screen is active.
  - The wireless Receiver shows dim white, but usually keeps playing? Rarely it cuts out completely.
 - The wired Receiver shows the bright white indicator, and since its volume is fixed to 100%, no problem.


Sometimes a track change will kick the wireless Receiver back on, but just at the moment it is stuck. Sometimes powering the receiver off and on will fix things for a while.

Some additional notes on my setup: the wireless Receiver is closer to the router than the Boom is, Receiver signal is typically ~90% as reported by SBS, Boom signal is typically ~80%.

Whenever the wireless Receiver cuts out, it is still responsive to wireless commands to turn itself off/on etc. This seems to imply that it is still active on the network.
Comment 4 Ritchie Argue 2009-10-14 22:08:29 UTC
I should be more specific in the configuration of the sync group:

1 Receiver, wired, volume locked out to 100% (digital out)
1 Receiver, wireless, synced variable volume (analog outs)
1 Boom, wireless, synced variable volume

It is the wireless Receiver that seems to be having the most difficulties.
Comment 5 Ritchie Argue 2009-10-14 22:21:29 UTC
- When the volume changes on its own, the change is reflected through to the web interface immediately - I can watch it jump on the web page.

- When the wireless Receiver (kitbox) is still playing in "offline mode" (dim white indicator), volume changes still work. Not sure how that Receiver has decided to indicate that it is not playing.
 
bedbox
Player Model: boom
Firmware: 50
Player IP Address: 192.168.0.192
Player MAC Address: 00:04:20:1e:2b:92
Wireless Signal Strength: 88%
 
bitbox
Player Model: receiver
Firmware: 65
Player IP Address: 192.168.0.191
Player MAC Address: 00:04:20:17:13:eb
 
kitbox
Player Model: receiver
Firmware: 65
Player IP Address: 192.168.0.107
Player MAC Address: 00:04:20:16:45:ab
Wireless Signal Strength: 85%

I couldn't see anything in the server log since yesterday when a server reboot was logged. Not sure if I need to turn debug logging on specifically to catch this sort of thing..
Comment 6 James Richardson 2009-10-30 11:25:32 UTC
Ritchie: I am still unable to replicate this issue.  Can you please try resetting your server prefs and try again?

Launch the SB Control panel, click on Advanced, Cleanup.  Select both check boxes then click Run Cleanup.  After that, stop/start the server.
Comment 7 Ritchie Argue 2009-10-30 12:14:49 UTC
I will give that cleanup a shot when I am home on the weekend.

I have given up on sync for the problematic Receiver lately, as it cannot maintain a stream when synced with another player. The volume reset seems to be related to sync, as I have not had it occur since I stopped syncing. I haven't had time to revert to 7.3.x to see if the stream continues and it is simply a volume reset problem again at that point. I haven't been home a lot lately and frankly I just want it to work _at all_ w/o fiddling with it, so if that means I can't use sync then that's the way it'll have to be for now.

Thanks for looking into this for me.
Comment 8 Ritchie Argue 2010-02-12 20:53:04 UTC
I should note that somehow I managed to fix this issue late last year. However, it started doing it again this evening. I will try to reset things per your instructions James and see if that helps. I am now running 7.4.1.

Sync is still a bit sketchy, as reported in #14352.