node-sonos-http-api
node-sonos-http-api copied to clipboard
jishi
Ungroup after clipall/clippreset/sayall/saypreset fails
I've installed node-sonos-http-api on a pi and use it to play a sample throughout the house when the doorbell rings. After playing the sample, the speakers stay grouped and don't go back to their original state / music playing
Not sure whether it is related. Error log contains:
TypeError: Cannot read property 'recalculateGroupVolume' of undefined
at NotificationListener.notificationHandler (/home/pi/node-sonos-http-api/node_modules/sonos-discovery/lib/models/Player.js:368:25)
at emitTwo (events.js:131:20)
at NotificationListener.emit (events.js:214:7)
at parseLastChange.then (/home/pi/node-sonos-http-api/node_modules/sonos-discovery/lib/NotificationListener.js:125:17)
at
and
2018-11-10T12:16:17.680Z ERROR
{ error: 'action 'tts' not found' }
2018-11-10T12:16:28.629Z ERROR
{ error: 'action 'tts' not found' }
2018-11-10T12:16:51.391Z ERROR
{ error: 'action 'tts' not found' }
2018-11-10T12:35:44.461Z ERROR
TypeError: Cannot read property 'members' of undefined
at Player.recalculateGroupVolume (/home/pi/node-sonos-http-api/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:4:32)
at NotificationListener.notificationHandler (/home/pi/node-sonos-http-api/node_modules/sonos-discovery/lib/models/Player.js:368:25)
at emitTwo (events.js:131:20)
at NotificationListener.emit (events.js:214:7)
at parseLastChange.then (/home/pi/node-sonos-http-api/node_modules/sonos-discovery/lib/NotificationListener.js:125:17)
at
Problem occurs when you send an second clipall while the first clipall is still not ready. Maybe a locking mechanism would be usefull.
@qwark1 Sounds like you have players or zones disappearing or something. Do you power off your players frequently?
Either way it seems we are missing some validation or cleanup from zone changes, because seems like it's trying to restore a zone (group) that no longer exists.
I've removed the more distant players from the preset and never power off players. Even when I only use three players which are all in neighbourging rooms the problem keeps reoccuring. Tried to downgrade jsnode back to version 6, that did lower the number of occurences, but still it keeps happening.
I'm seeing occasional hickups for random players on my system, but not to the extent you are describing. Node version shouldn't matter.
Could you describe your system (number of players, how they are connected) and also, what grouping of players you normally use?
I do think there is some intermittent timing issue when it tries to skip the the last track in the queue, which is kind of weird because I never unload the queue from the players.
I have one boost which is connected to my main switch; all other sonos are connected wireless. Total system contains about 10 - 12 sonos players, including all variants (1, 3, connect, playbar and sub) - some solo, some combined to a stereo pair or 5.1 setup. Most are well in reach of the sonos mesh network, except maybe one in the attic, which is why i changed from a clipall to a clippreset with only one solo play:3 and two stereo pairs. Normally no grouping is applied and often when the clippreset is fired they are all playing music.
When a hickup occurs, the ungroup is never done and the clip for clippreset stays active on the speakers. If you select the queue, you see indeed the original queue at all players
hi jishi, very handy api.
I also see this issue when using sayall with my doorbell, if the visitor presses the doorbell button more than once the the sonos system is left in a partially grouped state.
If the second api call arrives while the first is in progress, will the second job take the partially grouped system state as its baseline to which it should return on completion?
Is there a way of locking out parallel jobs or limiting resources to a max of one?
Cheers
@sgraystar The idea is that it will keep track of all announcements ever made and apply what was before all of them, if you happen to invoke them before they finish. However, they only work for each individual action (say, sayall, clip, clipall) IIRC, which means that a mix and match of these might confuse it.
The announcement feature needs to be this really unstable state machine because there is nothing builtin Sonos to deal with it. It has been really hard to make it fully robust, mostly because there is no guarantees that the players actually manages to inform the API about what they are doing, so in an unstable network environment, it doesn't manage to get back to it's original state.
@jishi Would it be practical to implement a lock per action?
In my scenario a lock on Sayall would ensure that any duplicate doorbell keypress would be ignored until the in-progress Sayall action is completed. I'm thinking something like this https://stackoverflow.com/questions/50588525/node-js-detect-and-prevent-duplicate-processes
I understand a mix and match of actions would still confuse the system.
Cheers
+1 Vote! A lock on SayAll and ClipAll would be really usefull! While the SayAll or ClipAll is playing, no other SayAll or ClipAll action is executed.
@jishi I am still thinking about this, lots of people press the doorbell more than once!!
I have submitted a pull request to restrict/allow concurrent clipall/sayall actions.
Cheers
I have the same behaivor. I think it would be just great to add the point "clip" to the type instead of "track"
