Bugzilla – Bug 10175
Customising drop-down selection list in SqueezeCentre breaks player settings syncing with SqueezeNetwork
Last modified: 2009-06-27 04:54:31 UTC
This is on SqueezeCentre v7.2.1 on Windows Vista, although this behaviour has always been like this. If one syncs player settings (SqueezeNetwork Integration is enabled in the web interface) and one customises any of the the drop-down list selections (e.g. Now Playing Information, Title Format, Font, or Standby Font), the actual player behaviour differs between SqueezeCentre and SqueezeNetwork. For example, the Font may be set to Standard on SS but ends up being set to something else on SN). I've seen this where I've customised one of the lists to include only one item (e.g. Font is Standard and selection on SS). I think the behaviour is caused by an assumption that the lists aren't customised and that the position in the list of a particular setting is the same on SS as SN.
Not exactly related, but see bug 10174 for a problem with the Now Playing screenscaver when drop-down lists on SqueezeCentre are customised.
Nigel: what players are you using, and what firmware versions do they have?
I've got 2 x SB2s (firmware v113), 1 x SB3 (firmware v113) and 1 x SBB (firmware v33).
QA Confirmed, SC > SN integration is not tight. SC> Modify Player > Basic Settings > Now Playing Information: set all options to null Set 1 option to Spectrum Analyzer and Remaining Time (11) wait 30sec for SC>SN sync (watch log to see the sync happen) Play a stream on SC to see now playing = SA&RT Stop Stream Move player to SN Play a stream and notice Now Playing = NULL Go to Settings > Player > Device > Display Notice that Now Playing is set to 'nothing' Look at the drop down list and notice all options are available. Expected behavior would be that the only option listed would be SA&RT just like I set it in SN ---- Note: Now Playing is not the only option affected, all options modifiable are affected.
Bug 10174 may be related or have a fix for this already, Andy to confirm
Bug 10174 appears to be fixed, but this bug remains (just checked using today's 7.3.3 svn checkout).