Grass Valley AMP Issue #2
Comments
|
Hey, thanks for investigating. This module has actually never been tested on any equpment (as far as I know). I have tried to find anyone to do some testing, but have had no luck. I have just written the module "blind", reading manuals. So I would guess the reason it does not send more commands is that it does not get in return what it expects. (I haven't looked at the code for a long time) Could you send me an example of a working conversation from dashboard or similar, so I could look at what the device actually answers, etc? |
|
Sure, definitely. Are you on the dev Slack? I can talk to you more on there and describe in more detail. I'm definitely more than willing to walk through with you and square this out. |
|
Yes I am :) Look for Håkon Nessjøen |
|
Lost you on slack, what was your name again? :P |
|
m.ulaky
…On Sat, Dec 8, 2018 at 3:11 PM Håkon Nessjøen ***@***.***> wrote:
Lost you on slack, what was your name again? :P
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/bitfocus/companion/issues/378#issuecomment-445496924>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFXOCVuExZNWPERI57YWNocvm9KVpe10ks5u3EcjgaJpZM4Y6vRO>
.
|
|
Doing a bit of packet sniffing here to see what's going on. When the instance is created for AMP it looks like it tries to send the "heads up a connection is coming" command to the receiving device but doesn't pad the correct number of bytes. I'm testing using Vtr2 -- as that happens to be my playback channel on this system. It appears all commends are followed by a new line "\n". What is sent by Companion (1.2 stable): "CRAT7204Vtr2" So the basic syntax is CRAT (which I believe tells it to create a connection) + 4 digit interger (equal to the number of following bytes [204Vtr2 = 7 bytes]) + the actual command. For channel 1 send: CRAT0007204Vtr1\n The play action in companion issues a command: "CMDS00042001" -- this is the same string works for me when sending TCP to the AMP device. When closing a connection with the AMP server it would be nice to do: STOP0000 (for example when disabling an instance.) The GV Documentation makes note that setting up and tearing down connections in unnecessary volume can cause instability or performance issues on the device. Sending the stop action doesn't result in any packets actually being sent -- seems like something is getting stuck. |
|
Hey Daniel,
Yes. I experienced the same behavior. Talking with Hakon it looks like the
original code was also waiting for a '/n' new line after each response
which actually doesn't hold true with responses from the server. He cleaned
up the code and fixed the bug and it seems to be working. I'm going to test
it when I get back into the studio but Hakon said he was able to have a
conversation with ProPresenter without issue with the new code.
On Sun, Dec 9, 2018, 12:56 Daniel Merchen ***@***.*** wrote:
Doing a bit of packet sniffing here to see what's going on. When the
instance is created for AMP it looks like it tries to send the "heads up a
connection is coming" command to the receiving device but doesn't pad the
correct number of bytes.
I'm testing using Vtr2 -- as that happens to be my playback channel on
this system. It appears all commends are followed by a new line "\n".
What is sent by Companion (1.2 stable): "CRAT7204Vtr2"
What works: "CRAT0007204Vtr2"
So the basic syntax is CRAT (which I believe tells it to create a
connection) + 4 digit interger (equal to the number of following bytes
[204Vtr2 = 7 bytes]) + the actual command.
For channel 1 send: CRAT0007204Vtr1\n
For channel 2 send: CRAT0007204Vtr2\n
// I don't have a 4 channel unit to test against, but their documentation
states the channel just iterates like below.
For channel 3 send: CRAT0007204Vtr3\n
For channel 4 send: CRAT0007204Vtr4\n
The play action in companion issues a command: "CMDS00042001" -- this is
the same string works for me when sending TCP to the AMP device.
When closing a connection with the AMP server it would be nice to do:
STOP0000 (for example when disabling an instance.) The GV Documentation
makes note that setting up and tearing down connections in unnecessary
volume can cause instability or performance issues on the device.
Sending the stop action doesn't result in any packets actually being sent
-- seems like something is getting stuck.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/bitfocus/companion/issues/378#issuecomment-445570953>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFXOCZe0ZLDlaf158HqwyBm63ZYCqpD5ks5u3XkNgaJpZM4Y6vRO>
.
On Dec 9, 2018 12:56, "Daniel Merchen" <notifications@github.com> wrote:
Doing a bit of packet sniffing here to see what's going on. When the
instance is created for AMP it looks like it tries to send the "heads up a
connection is coming" command to the receiving device but doesn't pad the
correct number of bytes.
I'm testing using Vtr2 -- as that happens to be my playback channel on this
system. It appears all commends are followed by a new line "\n".
What is sent by Companion (1.2 stable): "CRAT7204Vtr2"
What works: "CRAT0007204Vtr2"
So the basic syntax is CRAT (which I believe tells it to create a
connection) + 4 digit interger (equal to the number of following bytes
[204Vtr2 = 7 bytes]) + the actual command.
For channel 1 send: CRAT0007204Vtr1\n
For channel 2 send: CRAT0007204Vtr2\n
// I don't have a 4 channel unit to test against, but their documentation
states the channel just iterates like below.
For channel 3 send: CRAT0007204Vtr3\n
For channel 4 send: CRAT0007204Vtr4\n
The play action in companion issues a command: "CMDS00042001" -- this is
the same string works for me when sending TCP to the AMP device.
When closing a connection with the AMP server it would be nice to do:
STOP0000 (for example when disabling an instance.) The GV Documentation
makes note that setting up and tearing down connections in unnecessary
volume can cause instability or performance issues on the device.
Sending the stop action doesn't result in any packets actually being sent
-- seems like something is getting stuck.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/bitfocus/companion/issues/378#issuecomment-445570953>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFXOCZe0ZLDlaf158HqwyBm63ZYCqpD5ks5u3XkNgaJpZM4Y6vRO>
.
|
|
I just tried with da4d677 and noted the connection doesn't set up as noted above (looking a second time, it may simply be stripping the 0's out of the byte count). Perhaps that change hasn't been pushed to the repo yet. For the sake of documentation, I'm using a Grass Valley K2 Solo 3G. |
|
I pushed some changes yesterday, it should be able to send play/stop/load clip. I have also done more work locally to list files. But that is not ready for pushing yet. Could you please try the latest version. and if it does not work with the K2, I would love if you could send me a wireshark pcap file of the network conversation. |
|
Hey Daniel, |
|
Awesome -- tried it with the most recent build, Play, Stop, Eject worked I didn't have any success with load clip when specifying the string/clip name - the dropdown list did populate with available clips but I wasn't able to use it to recall them just yet. I'll have to circle |
|
Any news on getting the record to work? |
|
Nevermind I see it's working now, thank you! |
What it the status on this? Please file a new issue if needed |
|
The LOAD CLIP command is not working properly in T2-4k right now. |
Trying to use the AMP protocol module and for some reason when I try to send a record command it sends the initial command to connect to open the connection and connect to the right channel but won't send any subsequent messages. I was trying to use it with an ATOMOS Shogun Studio which does work via Dashboard and via our Carbonite AMP connections so I think it may be a bug?
It also seems like when I connect to PacketSender to deubg the issue the initial command to connect to the right channel is missing the padding on the number of characters descriptor. Not sure if that's associated with it at all, but just something I noticed.
The text was updated successfully, but these errors were encountered: