Issues with Universal Videohub 288

[jfpanisset]

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.

[jfpanisset]

This is related to issue #5 : the default timeout for reading from the device is 15 msec (rather than 15 sec), which is not enough time to get the much larger response from a Videohub 288: increasing the timeout to the currently longest supported value of 60 msec with --timeout 60 allows a complete message to be read before trying to parse, without having to add calls to sleep().

[gfto]

Now that the issue with read timeout is fixed, can you check if --timeout 60 works?

[jfpanisset]

I'll try soon and report back. It was working with --timeout 60 (msec), so presumably it should work with --timeout 60 (sec), but worth trying.

[jfpanisset]

It looks like commit 46b46e9 mostly breaks the app when talking to a Videohub 288. For instance when running without a --timeout value and thus using the new default value of 15 secs, it will take roughly 60 seconds before you see the output of the application. With --timeout 5 for instance the delay is 20 seconds.

The fundamental issue is that the Videohub Ethernet Protocol is broken by design, as connecting to port 9990 will just spew out formatted but unstructured ASCII, without any clear "end of message' confirmation. Older serial-based router control protocols would incorporate elaborate handshaking through ASCII control characters, a more modern design would spit out a clearly defined XML or JSON response, but in this case you are left with timing-based heuristics, or building in the knowledge that "for this specific type of router and software revision, I've received all the output I expect to receive for now".

Some quick tracing in fdread_ex() indicates that once there is no more input to be read from the socket connecting to the router, poll() is still called twice, and then fdread_ex() is called again, which results in in two more calls to poll(). This explains why you end up having to wait for 4x the specific timeout before proceeding.

Even if the logic is reworked to make sure that poll() is only called once after there is no more input to be read, that would still introduce a 1 sec delay for each interaction with the router, which could break some more complicated workflows.

My suggestion would be:

• back out of this change to go back to the msec based delay as before
• increase the maximum allowable delay value from 60 to something larger (say 500 msec?)
• document that the 15 msec default delay is sufficient for smaller routers, but that for a larger router, you may want to specify a 60 msec delay
• convince BMD to expose a more modern REST API that returns simple to parse JSON without any parsing or message completion ambiguity (right)