gfto/videohubctrl

videohubctrl can be used to control Blackmagic Design Videohub SDI router device over the network.

videohubctrl's Issues

Build on windows?

Can i built on windows this software?

ALARM STATUS on Universal Videohub 288

Here's what the telnet interface reports on a Universal Videohub 288:

ALARM STATUS:
Fan 0: ok
Fan 1: ok
Fan 2: ok
Power Supply Slot 0: ok
Power Supply Slot 1: ok
Power Sufficient for Load: ok
Network Slot 0: ok
Network Slot 1: ok
Card Bus: ok
Card Firmware Version: ok
Logic Slot 0: ok
Logic Slot 1: ok
Logic Firmware Version Slot 0: ok
Logic Firmware Version Slot 1: ok
ProcessorLink: ok
Processor Firmware Version: ok
Crosspoint Slot 0: ok
Crosspoint Slot 1: ok
Bus Host Slot 0: ok
Bus Host Slot 1: ok
Bus Host Firmware Version Slot 0: ok
Bus Host Firmware Version Slot 1: ok

This appears to be informational only, there's not really anything actionable from an API perspective. But would be useful to present it to the caller / not error out on it.

Issues with Universal Videohub 288

When I point the code at a Universal Videohub 288 running firmware 2.3, although the code recognizes the device, it prints all empty listings for the inputs and outputs.

If I add a call to sleep(1); after calling connect_client(), that seems to leave enough time for the router network interface to "wake up" and return the information expected by the code. I then get mostly sensible output from --list-inputs for instance, but I also get some debugging output such as:

WARNING: Videohub sent unknown command!
...
WARNING: VIDEO OUTPUT STATUS command returned unknown status: 'N'

I'll try to dig a bit more into this and hopefully submit some PRs.

Incorrect units for timeout value

The -t / --timeout command line argument is defined as:

 -t --timeout <secs>        | Set connect/read timeout. Default: 15

This timeout value defaults to 15 and is clamped to between 0 and 60 in parse_args(), and is then passed to fdread_ex() which in turn passes it to poll(2), but poll(2) defines its timeout argument in milliseconds, not in seconds. This causes problems on larger routers such as the Universal Videohub 288, where the default timeout value of 15 msec is not enough to allow the router to send its complete response, causing read_device_stream() to fail to parse an incomplete response from the router.

Fortunately the current maximum timeout value of 60 msec (--timeout 60) seems to be sufficient in my environment to read the complete response from the Videohub 288, but that's not very robust.

A couple of possible approaches to resolving this:

• change the documented definition of -t / --timeout to msec, increase the maximum accepted value to (say) 60,000 aka 60 seconds: this has the advantage of not changing the behavior of the application for existing scripts, while making it clear that the parameter is in msec rather than seconds
• keep the definition of -t / --timeout in seconds, multiply timeout by 1000 either when calling fdread_ex() or when calling poll(2) inside fdread_ex(): this changes the behavior of the application for existing scripts, but presumably a working setup doesn't rely on timeouts being exceeded, so multiplying the timeout value by 1,000 shouldn't break anything?

All commands take too long to run

All commands take more than a minute to run. This is over an OpenVPN vpn but the ping time to systems on that network is only in the 20-50ms range. I'm going do some logging to see where the delays come from. I don't suppose there is an existing time logging feature?

For reference the device info as printed by the tool is below

  -------------------------------------------------------------------
  | Device address             | 192.168.137.3                      |
  | Device port                | 9990                               |
  | Model name                 | Blackmagic Smart Videohub 40 x     |
  | Friendly name              | Smart Videohub 40 x 40             |
  | Unique ID                  | 7C2E0DA63C9F                       |
  | Protocol                   | 2.8                                |
  | Video inputs               | 40                                 |
  | Video outputs              | 40                                 |
  -------------------------------------------------------------------