Page 1 of 1

DR TCP Transport Control - behavior issues

PostPosted: Mon May 17, 2021 8:28 am
by Max Paperno
Hello!

I'm working on a basic client for the Resolve TCP Transport Control, v1.2 as described in the DR manual, Chapter 121 (of the v17 edition). Although it's mostly working "as advertised," I've run into a couple issues so far.

DR Studio v17.2 Build 11 (same issues with 17.1), Win 10 (20H2 19042.985, latest updates as of this post). Using Python's socket implementation. Client and DR "server" are on same machine.

  1. When sending play command, all the forward play speeds work as expected. Eg. sending:
    Code: Select all
    [04:00:00:00] [70:6c:61:79] [00:00:80:3e]
    [cmnd length] ["play"]      [0.25 (little-endian)]

    will play forward at 1/4 speed, 0.5 at half speed, 1.0 at full, etc. However, doing the same thing with a negative play speed seems to confuse DR.

    If I send -0.25 (00:00:80:be), Resolve just crashes, with this in the debug log:
    Assertion failed: m_PlaySpeed > 0.0f, file C:\jenkins\workspace\resolve\Resolve\Cyclone\UI\Player\UiPlayerModel.cpp, line 5943

    But, if I send -0.5 (00:00:00:bf), then it plays backwards w/out crashing... at 1/4 speed. I have to send -0.75 (40:bf) for -1/2 speed, -1.0 (80:bf) for -3/4 speed, and -1.5 (c0:bf) for -x1 speed. After that, -2.0 (00:c0), -4 (80:co), -8 (00:c1) all work as expected.

    Either I'm missing something, or something is a bit off :P in the DR code?
  2. On the Fairlight page, the play speed values are interpreted in some other bizarre way... sending 0.25 starts 1x playback, going up to x16 when sending 8.0, but then when going back down, from, say 8.0 to 4.0, the playback speed actually increases to x64, like the 4.0 is being treated as relative instead of absolute. Pretty hard to describe, but clearly not working like on all the other pages.
  3. The goto command also acts strangely. It doesn't actually move the playhead (or change the preview), except on the Color and Deliver pages. On the other pages the command seems to be ignored... but it's more complicated than that.

    When on any UI page, after sending a goto, a subsequent gettc reports the same timecode which was just set with goto, as if the command worked (which on Color & Deliver, it does).

    If the UI is on the Cut or Edit pages, the goto is ignored but gettc keeps reporting incorrect position until the playhead is manually moved.

    If the UI is on Media or Fairlight, the goto appears to be ignored, unless you switch to any other page after that (w/out moving the playhead)... where you'll find that the position has actually changed to the TC specified in goto.

    Maybe I'm not understanding what goto is supposed to do?

Does anyone actually use this protocol? I can find zero information on it, except what is in the manual (and one old thread on this forum regarding the "advanced" setting to enable remote control).

I can't find any other/better (and inexpensive) way to smoothly control forward/reverse playback speeds ([Shift]J/K/L are too "chunky"]. So I got a Python script which reads from a HID and sends playback commands to DR via TCP socket. Seemed like it should be easy. The playback speeds work great, except as mentioned above. I would like to use goto for quick scrubbing/jumps per x frames/seconds (after gettc/getframerate). I plan to publish the code once I know what works or not (but I could post it sooner if anyone wants to play/test).

Let me know if I can provide any further information. I tried to keep this as brief as possible for now. :?

Thanks!
-Max

Re: DR TCP Transport Control - behavior issues

PostPosted: Mon May 24, 2021 5:54 pm
by Max Paperno
Code: Select all
> ping BMD

Pinging BMD with 3,545 bytes of data:
Reply from forum.blackmagicdesign.com: Destination unreachable

Re: DR TCP Transport Control - behavior issues

PostPosted: Mon Aug 09, 2021 6:14 pm
by ambustion
Hey Max,

I found same as you, I just think it only works properly in full integers. What's more is some commands only work in color page, and some in edit. Would be very interested in seeing what you have working so far if you are interested in sharing. I have everything working you mentioned with python, but first time trying tcp so would love to compare.

It's super handy for grabbing stills or jumping to notes from a treelist if you are making guis at all though. Seems pretty solid in the color page.

Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Aug 14, 2021 8:56 pm
by Max Paperno
Hi Brendon,

FWIW, I submitted a support ticket regarding this issue to BMD, and eventually that led to this reply on June 10th (2021), but I haven't heard anything since then.

I was advised that a developer was assigned to look into the case. This limits our current visibility in the progress of this case, but I will let you know if we get any specific responses or follow-ups.


For this and other similar reasons (lack of support, constant bugs, proprietary everything) I've decided not to invest any more resources into DR or BMD at this time.

Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Aug 21, 2021 1:27 am
by ambustion
Too bad. I agree it'd be great to have a line of communication with the developers. They add things I want every update for API and I just use it to increase productivity in my own workflow so understand if you are not using it to just poke around as a bonus it would be frustrating.

If I get any headway I'll share with you as well.

Re: DR TCP Transport Control - behavior issues

PostPosted: Thu Oct 07, 2021 10:58 am
by piersdeseilligny
I'm getting this exact same behaviour in Resolve 17.3.1. If anyone working on Resolve reads this, can we hope for a fix in a future update?

Re: DR TCP Transport Control - behavior issues

PostPosted: Thu Oct 14, 2021 1:10 am
by Peter Chamberlain
This TCP control is really designed some years ago for the color page for a remote ctl to use in viewing sessions so its functionality is basic. It't not trying to be nor meant to be a protocol to make a full featured TCP controller.
We now have a better control across all pages with the Speed Editor via BT or USB.

Re: DR TCP Transport Control - behavior issues

PostPosted: Fri Oct 15, 2021 8:25 am
by piersdeseilligny
Thank you so much for the response! While the speed editor is great to use while editing, it isn't something I would want to ask someone else to use while I'm editing or grading - whereas a device such as a stream deck, or a locally hosted web page accessible via a phone, etc.. that can control resolve via this TCP protocol could be more flexible in certain use-cases, can be used by several people at a time, etc...

Obviously the speed editor will always be a lot smoother and better integrated (simply because of the significantly broader feature set than is exposed to developers) but that also means that having the TCP Protocol behave as expected and described in the manual wouldn't lead to software which overlaps with the speed editor in terms of functionality or use-cases, which is understandably something I imagine Blackmagic Design wants to ensure.

A working TCP Protocol would simply open up a few more doors to users and developers for a few scenarios which are admittedly niche, but could really benefit from the quality-of-life improvements enabled by functional TCP control.

Re: DR TCP Transport Control - behavior issues

PostPosted: Fri Oct 15, 2021 8:45 am
by Max Paperno
Peter Chamberlain wrote:This TCP control is really designed some years ago for the color page for a remote ctl to use in viewing sessions so its functionality is basic. It't not trying to be nor meant to be a protocol to make a full featured TCP controller.
We now have a better control across all pages with the Speed Editor via BT or USB.

We're just looking to use the documented functionality, which is currently broken and/or not clearly described (eg. nothing about it being just for the color page). No one said anything about "full featured TCP controller." Not sure what the SE has to do with this either (can the SE be controlled via API? don't think so), and besides it does not actually provide the type of playback control I was looking for.

If similar functionality could be achieved via the Python/Lua API, that would be a workable replacement for the TCP protocol.

Re: DR TCP Transport Control - behavior issues

PostPosted: Fri Oct 22, 2021 8:16 am
by piersdeseilligny
Just looking at the 17.4 release notes, i've seen "Scripting API support to set playhead position on the timeline."

Will test it out, but sounds super promising!

EDIT: Yep, it works great. Thank you so much for implementing this!

Re: DR TCP Transport Control - behavior issues

PostPosted: Fri Nov 19, 2021 4:00 pm
by SeldomSeenKid
Hi There!

I am trying to connect to DVR using a TCP client but it refuses to connect.
I have added "System.Remote.Control = 1" to my preferences (incl. a restart and try to connect to port 9060 as written in the manual.

Am I missing something here?

Re: DR TCP Transport Control - behavior issues

PostPosted: Tue Nov 23, 2021 3:15 pm
by piersdeseilligny
SeldomSeenKid wrote:Hi There!

I am trying to connect to DVR using a TCP client but it refuses to connect.
I have added "System.Remote.Control = 1" to my preferences (incl. a restart and try to connect to port 9060 as written in the manual.

Am I missing something here?


Does the example C code from the manual work for you? I had a bit of difficulty connecting to DVR until I used the example C code as a guide, to ensure I was sending the right data in the right order. It's a bit fiddly, and easy to accidentally disconnect if you don't send Resolve exactly what it's expecting,

Re: DR TCP Transport Control - behavior issues

PostPosted: Tue Nov 23, 2021 7:24 pm
by SeldomSeenKid
Hi Piers,

The main issue is, that "netstat" (I am on Windows 10) doesn't even show port 9060 as listening. So DVR doesn't open it.

I don't use C for now but connecting from a 3rd party scripting software. I am 100% sure that this software handles the socket correctly since I can connect to everything else. I am also sure that my OS doesn't block this port as I added an exception to the firewall just to be 100% save). I also tried opening port 9060 from my scripting environment and it worked fine. So no blocking from OS side.

My assumption is that TCP transport control is only available in the Studio version, while I am using the free version.

BTW: I am using version 17.4.2.009 but previous versions just behaved the same way.

Re: DR TCP Transport Control - behavior issues

PostPosted: Wed Dec 22, 2021 4:06 pm
by SeldomSeenKid
After wrestling some hours with my attempt to implement a smooth remote transport control, I want to add my two cents just in case someone is willing to try something similar.

I am not using TCP but a LUA script with its own MIDI connection. My goal was to implement a smooth scrub or shuttle to be used with my X-Touch device. I was exited when I read that SetCurrentTimecode has been implemented and gave it a try.
I found that is is not useable for anything else but positioning the playhead, which works as advertised. Using it to emulate something like scrub or jog just doesn't work even when using it together with play.
I felt back to my plan B which is using a keystroke emulation. Its jerky but at least I do have sound while "scrubbing" (which isn't the case with SetCurrentTimecode).
Interesting enough: There IS smooth scrubbing in DR! If I connect my X-Touch via MCU MIDI and press the SCRUB button while in Fairlight, I can use the dial-wheel to scrub through my timeline as smooth as warm butter - including sound. Unfortunately this is only available in Fairlight.

If I can express a wish for Christmas: Dear Santa @ BDM R&D, I was a modest and diligent boy all 2021. I worked hard with your software to get the best out of my poor equipment. I know that I am not your target audience but my budget is small and my ambitions are big. If you can please add some butter smooth transportation commands to your API, I promise I will buy a Studio license in 2022...
... not kidding!

Yours sincerely Michael

Re: DR TCP Transport Control - behavior issues

PostPosted: Fri Feb 04, 2022 5:25 pm
by Octavian Mot
@Max or anyone who tried to control via TCP Protocol using python sockets

I'm trying to send the 'connect' command, but can't figure out how to encode the command string in this simple script:

Code: Select all
import socket

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    command = "7 connect" # <--- this needs to be encoded
    s.connect(('127.0.0.1', 9060))
    s.send(command)
    data = s.recv(1024)

print('Received: ', repr(data))



What is the proper way to do this?

Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Feb 12, 2022 1:02 am
by Igor Riđanović
I've developed this client playback controller app using the TCP/IP protocol. It's been five years and I can't remember the details, but I remember running into multiple issues that required some thinking to solve. It certainly would have been easier had the API been available at the time. I don't think I found the protocol buggy, it's just that it was limited.


Re: DR TCP Transport Control - behavior issues

PostPosted: Sat Feb 12, 2022 1:12 pm
by Octavian Mot
Hey Igor!

Yes, I've seen your test on youtube a while back!

I'm trying to trigger play/stop from a python script via TCP since the API doesn't have a play/stop function.

I tried multiple encoding functions and combinations, but nothing seems to do the trick...

Was your app also in Python?

Re: DR TCP Transport Control - behavior issues

PostPosted: Mon Feb 14, 2022 5:00 am
by Igor Riđanović
Yes, that was Python 2.7.