Page 1 of 1

Can't make multiple routes on Videohub via SDK

PostPosted: Mon Jan 07, 2019 3:18 pm
by Roddy Pratt
I've just stumbled over a TCP problem with Videohub SDK in firmware 6.4.1

We've had control working via TCP for a few years without problem, until I recently tried to make multiple routes at once using multiple VIDEO OUTPUT ROUTING commands. Basically, only the first two routes are made, and the others are silently skipped.

I can provide a Wireshark log if necessary, but it appears that if a single network packet contains multiple routing commands, only the first is executed. It seem that if the Nagle algorithm on the sending socket is disabled, all routes are made correctly. This really shouldn't be necessary.

Re: Can't make multiple routes on Videohub via SDK

PostPosted: Tue Jan 08, 2019 2:48 pm
by Xtreemtec
Sorry but have to check. Do you have the same FW version as SDK version installed on your videohub.?

Re: Can't make multiple routes on Videohub via SDK

PostPosted: Tue Jan 08, 2019 6:01 pm
by Roddy Pratt
Thanks for the reply.

SDK: We're not using the COM components - We've just implemented the Videohub Ethernet Protocol as described in the "Developer Information" section of the manual, so all the code is ours. So SDK version shouldn't matter.

I see 6.4.2 has just hit the support site. I'll see if that firmware changes anything!

Re: Can't make multiple routes on Videohub via SDK

PostPosted: Tue Jan 08, 2019 8:43 pm
by Xtreemtec
Still there could have been a change in the way the protocol works between versions. ;) So that was why i asked if you run the same version SDK and FW on the router. 8-)

Re: Can't make multiple routes on Videohub via SDK

PostPosted: Tue Jan 08, 2019 10:15 pm
by Roddy Pratt
Xtreemtec wrote:Still there could have been a change in the way the protocol works between versions. ;) So that was why i asked if you run the same version SDK and FW on the router. 8-)


Understood. To clarify, we're not "running" or linking with *any* BMD supplied software on the client. It's just our own code, using the documented protocol. If there had been a change to the protocol, I'd expect a change to the documentation.

The behaviour I'm seeing isn't described by the docs, and I suspect has been there forever. It's only a problem if you send a series of commands in quick succession without waiting for ACKs in between each one, which is something we haven't tried until now.