Bugzilla – Bug 8981
Sync'd players & Line IN oddity
Last modified: 2009-09-08 09:28:18 UTC
When I have players synced, and I tell 1 player to switch to "line-in" then ALL players switch to Line-In. Even those players like the Duet that do not have a line in, or the Transporter which have Multiple Line In's. What should be the expected behavior when all players are synced and 1 is told to switch to line-in?
It should be removed from the group, like it was powered off.
So the 1 player should be removed from the group, and the rest of the group should continue to play, correct? I couldn't find a spec page on this, can you link it for me please.
I thought we were talking that line in ought to be mixed with song playback. In that case it would make good sense to be able to sync and have line in active. Is that not the plan? cc'ing Alan as well.
We decided to punt on mixing by default for the first release, though add it as an option. I think that if a player is set to Line In, it should drop from a sync group (like if you power off). No spec for this yet, as you just discovered this case. :) Alan: Can you take a look at this?
I propose to cause (a) the auto-play of line-in in when plugged in, and (b) play from the UI menu item: to force the player out of any sync group first. This will be a permanent unsync, not temporary. For 7.3 I would add a check in overridePlayback to fail and display an error if trying to play line-in when synced (via favourites, for example).
I think Dean's current thinking for the behavior of the line-in detection is just to make the line-in option also appear on the device home menu, in addition to its usual location in the menu structure. IIRC Ben is working on this.
Change 22623 as described in comment #5. Retarget to 7.3 for remaining changes.
I don't think we need an error warning here, let's just have some reasonable, intuitive default behavior (i.e. permanent or temporary unsync.) Closing, but let's keep an eye on customer feedback on the behavior.
The current change means that if you switch to line-in via the UI or as a consequence of plugging in the jack, then the player is automatically, silently and permanently unsynced (if it was synced in the first place). This is fine, in my opinion. It works because the command to play line-in is interpreted in the context of a specific (line-in-capable) player. If, however, (for a synced player) you try to play line-in via favourites, tune-in-URL or from a playlist - anything that just presents a line-in URL to the streaming-control code (old or new streaming) - then the results are unpredictable, and to some extent always wrong. This is because the command to play line-in is interpreted in the context of the sync-group, more-specifically the sync-group master. It may be that the sync-group master (unpredictable from a user point of view), can play line-in, in which case the master will play-line and the others will play nothing. Other scenarios lead to internal errors. No useful user feedback is given. My proposal was to detect this second situation - trying to play line-in (or digital-in) via a URL when synced - and generate a user-visible error.
If we moved to the Line-In-is-always-on model, then this would be moot. Alan: is there any way to disambiguate what player context triggered the line in URL request? Of course, the best solution would be to stream the line in to the other players over the network. :)
No, not easily. Of course, it is only software ... There are several use-cases where streaming out to other players would be useful.
This appears to be addressed in SqueezeCenter 7.2-22834
This bug has been fixed in the latest release of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.