icedream / go-stagelinq Goto Github PK

Curious if you've seen any evidence of a StateMap "keepalive" feature to detect dead connections on the client side? I've seen instances where the Denon stops sending updates to the subscriber, yet the subscriber (go-stagelinq) and OS consider the TCP connection up so it continues to obediently wait for updates.

So we tested this with two SC5000s.

go-stagelinq found the two decks (with two IP addresses).
Loading a song from USB stick on deck 1, it would get the data correctly and printf'd it.
However, loading a song on deck 2, it wouldn't show up.

In the log, we first see the initial state of both decks, but from that point forward only actions on deck 1 where the USB stick would be printf'd. Deck 2 never printf'd anything from that point forward.

Would it potentially make sense to add context support to NewStateMapConnection so that we can receive a ctx.Done() or initiate a cancel signal? I'm pondering how to gracefully shutdown multiple StateMapConnection when one of them closes its send channel due to error. If they all shared a parent context, I was thinking a graceful shutdown could be initiated when the failure of one should initiate a shutdown of all.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update module golang.org/x/text to v0.17.0
• Update robherley/go-test-action action to v0.4.1

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

• Reveng'ing the protocol
• PoC for protocol implementation
• Drafting API
• Restructuring PoC to conform with drafted API
• Testing

No matter what I've tried, I can't get it to connect to an MCX8000 controller.

Keep getting this error:

• Reveng'ing the protocol
• PoC for protocol implementation
• Drafting API
• Restructuring PoC to conform with drafted API
• Testing

This seems to be a new service as of engine os 2.x. Did not analyze at all yet.

• Reveng'ing the protocol
• PoC for protocol implementation
• Drafting API
• Restructuring PoC to conform with drafted API
• Testing

There is state for "Lead" track (ie: which one is currently playing / similar to ProDJ-Link "on-air" state).

I was wondering, is there any guidance (even if it's basic) on sniffing / wiresharking stagelinq to see if I can discover new state values? I'm hoping to uncover a the "lead" track state and contribute to this and other projects.

Is there a way to differentiate between devices?

I'm developing an OBS overlay to display the currently playing track in each channel. On the Prime 4(+) I get messages with state names /Engine/Deck[1-4]/.*. so from that device I can easily differentiate the four channels. From a pair of SC5000 I get messages from them both and they're each sending /Engine/Deck[12]/.*, so purely parsing the state name isn't enough.

For a given session, I can differentiate between devices by IP address, but between sessions the devices may get different addresses via DHCP. I'd like to get some durable identifier that I can combine with the Deck. portion of the name to keep the channel ordering consistent in the overlay. I can potentially use ARP to get the MAC address associated with the device's IP and use that, but it would be nice if there were something directly in StagelinQ.

Running stagelinq-discover, the output indicates that it's using the wrong format string placeholder for values. The output looks like this:

2024/01/24 19:17:42 	/Engine/Deck3/Track/TrackName = map[string: type:%!s(float64=8)]
2024/01/24 19:17:42 	/Engine/Deck4/Play = map[state:%!s(bool=false) type:%!s(float64=1)]
2024/01/24 19:17:42 	/Engine/Deck4/PlayState = map[state:%!s(bool=false) type:%!s(float64=1)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/ArtistName = map[string: type:%!s(float64=8)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/TrackNetworkPath = map[string: type:%!s(float64=8)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/SongLoaded = map[state:%!s(bool=false) type:%!s(float64=1)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/SongName = map[string: type:%!s(float64=8)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/TrackData = map[state:%!s(bool=false) type:%!s(float64=3)]
2024/01/24 19:17:42 	/Engine/Deck4/Track/TrackName = map[string: type:%!s(float64=8)]

I think it should look like this:

2024/01/24 19:20:24 	/Engine/Deck3/Track/TrackData = map[state:false type:3]
2024/01/24 19:20:24 	/Engine/Deck3/Track/TrackName = map[string: type:8]
2024/01/24 19:20:24 	/Engine/Deck4/Play = map[state:false type:1]
2024/01/24 19:20:24 	/Engine/Deck4/PlayState = map[state:false type:1]
2024/01/24 19:20:24 	/Engine/Deck4/Track/ArtistName = map[string: type:8]
2024/01/24 19:20:24 	/Engine/Deck4/Track/TrackNetworkPath = map[string: type:8]
2024/01/24 19:20:24 	/Engine/Deck4/Track/SongLoaded = map[state:false type:1]
2024/01/24 19:20:24 	/Engine/Deck4/Track/SongName = map[string: type:8]
2024/01/24 19:20:24 	/Engine/Deck4/Track/TrackData = map[state:false type:3]
2024/01/24 19:20:24 	/Engine/Deck4/Track/TrackName = map[string: type:8]

The log.Printf call is using %s for the map[string]interface{} when it should be using %v. PR forthcoming.