Transport.standby(...) on Linn Selekt causes temporary standby followed by wake

I’m seeing an API behavior with standby which seems like a bug but might be intentional behavior. This is occurring with a Linn Selekt. This is a node-based extension using node-roon-api and node-roon-api-transport.

While music is playing on a zone, my extension calls:


When the call is made, the Selekt goes into standby mode. After a brief period, it comes back on and music continues playing.

My expectation is that calling standby should put the element into a standby state whether or not music is playing. This suggests that if music is playing, Roon should pause the music and then put the device into standby.

I can probably work around this by testing if music is playing and, if it is first pausing it. Or perhaps just always pausing. Ideally, though, I’d just call standby and not try to do additional state management.

Thanks for your help and time.

Verify what happens when you use the manufacturer native app to standby, instead of Roon API.

I’m not sure what set of steps you’re suggesting here. Are you suggesting I use the manufacturer’s app to initiate streaming and then do something - again in the manufacturer’s app - to put the device into standby? Or are you suggesting I use Roon to stream something and, while Roon is streaming to the device, use the manufacturer’s app to put the device into standby?

I’m also not sure why this a meaningful test. If you explain why the test is meaningful, that’ll help me understand why you’re making this suggestion.


This was not what I was suggesting, but this is helpful in establishing the baseline behavior. If this fails, something on your network is waking it up unexpectedly.

This. I think this is what you intend to do with your API call.

Two different ways to do the same thing. They should result in the same behavior, i.e. standby. If they yield different behaviors, then the implementation of one of the ways need more investigation. If they yield the same behavior, then something more fundamental needs to be investigated.

I think there can be a third way to test this. Use Roon Remote app to issue the standby (if that is exposed).

Thanks, @wklie.

This discussion is making me think that the problem here is me.

What I’m seeing is that putting an output in standby does not pause playback. It’s reasonable to expect a device in standby, to which music is being actively streamed, to wake out of standby. That’s what I’m seeing, and I was trying to understand why the standby API call didn’t pause playback.

Play/Pause are operations on Zones. Standby is on Outputs. The logical model is one zone → many outputs.

I think the obvious answer here is that since a zone can be playing to many outputs, putting one output into standby should not pause zone playback since doing so would unexpectedly pause the entire zone.

If I want to implement an extension that has a standby behavior, I need to figure out and implement what I want that to mean for the various case of zone w/one output and zone w/more than one output. That makes sense to me now.

Sound right?

Thanks for being a sounding board :slight_smile:

what I do in rooDial is currently this:, ‘stop’);
outputs.forEach(output => { });

This means I send a stop to the zone and then standby to all outputs of the zone, which in the simplest case is just one.

This did not work as you tested.

Tomorrow I will try waiting for zone ist stopped after I issue the standby commands to the outputs.

So I grant that the behavior I’m seeing might be considered by design. Given that, I tried this:, ‘stop’, function (msg) {
outputs.forEach(output => { });

Sometimes this works, sometimes I see the same behavior I was previously seeing.

If I have the Roon client up and running, I see the zone pause (in Roon), then I see the Linn device go into standby, then I see Roon go back into play while briefly displaying a status message indicating that playing is starting.

Something is going on here that I don’t understand. Realistically, this is not an important use case for me and it’s not a big deal if we don’t figure it out.