Art-Net RDM devices are not automatically removed if they stop responding to ArtPoll

[ld3300]

Running "OLA olad version: 0.10.7" on a raspberry pi 3 B+, "cat /etc/debian_version" returns 9.8 I have artnet configured with port 0-3 patched to universes 1-3 respectively. I have a python script that is sending a continuous scrolling vertical bar on all 3 universes. When I enter "ola_rdm_discover -u 1" I get the UID response as expected (in this case 4354:00010020) If I power off and disconnect the ethernet cable from my artnet device and again do an "ola_rdm_discover -u 1" the same UID continues to show up. This behavior persists if I reboot the raspberry pi, the UID still shows up on an "ola_rdm_discover -u 1", even though the end device was never powered back on. If I try "ola_rdm_get --universe 1 --uid 4354:00010020 device_info" i get "Error: Response Timeout" (as I would expect as the device is not actually present.)

It seems that the rdm discover is returning a buffer somewhere instead of checking that the device still exists on the network.

Update: adding -f or -i to ola_rdm_discover does not make the device go away.

[peternewman]

Hi @ld3300

Is this a native Art-Net device and RDM responder, or an Art-Net gateway with a DMX/RDM device connected?

Can we have olad -l 4 logs: https://www.openlighting.org/ola/get-help/ola-faq/#How_do_I_get_olad_-l_4_logs

We'll probably need a Wireshark/tcpdump capture too please.

OLA doesn't do any disk based caching, so I'm a bit confused there.

Does the device successfully respond to a device_info when it is online? Have you used identify device to confirm the UID you're seeing is the device you're expecting?

Manufacturer 4354 is City Theatrical ( http://rdm.openlighting.org/manufacturer/display?manufacturer=17236 ), I assume this is some interface product with Art-Net input.

If I was to guess, it feels like either OLA isn't being restarted, hence still knowing about the UID, or the device you've unplugged isn't the one listed in the discovery.

The -f you mentioned should make UIDs appear and disappear as expected.

[ld3300]

Hey @peternewman thanks for the help

It is a native Art-Net device and RDM responder. It is a City Theatrical 5910 Multiverse Transmitter (final stages of testing). My setup is a Netgear GS110TP switch with rPi, Win10 PC, and CTI 5910 connected (no other devices in system).

It does successfully respond to device_info and all the other implemented PIDs I've tested when it is connected and powered.

Attached is my olad -l 4 and wireshark. pi is 169.254.21.80. CTI 5910 is 169.254.3.0. PC is 169.254.135.7

All commands are done at the terminal CTI 5910 powered and on network when pi is booted In the olad log, line 658 is the device_info get request after i unplugged the City Theatrical unit when I get an RDM Request timed out. I did several ola_rdm_discover -u 1 commands after that and the UID is still listed (even 2 hours later).

Often, if my RDM device joins the network after the pi running ola then it will register for Art-net DMX data, and will output it, but will not be detected by an ola_rdm_discover -u 1 command until olad is stopped and restarted

Also, I am running all devices to accept a DHCP address with no DHCP server, so all IPs are in the 169.254.x.x domain.

ola_log.zip

[peternewman]

Just to confirm @ld3300 , you mentioned you'd tried ola_rdm_discover -f; can you confirm you've tried this sequence:

1. ola_rdm_discover -u 1 -f
2. Device listed
3. ola_rdm_get -u 1 --uid <uid> device_info
4. Device info response
5. Depower device
6. ola_rdm_discover -u 1 -f
7. Device still shows as present?
8. ola_rdm_get -u 1 --uid <uid> device_info
9. RDM timeout?

You were saying before that if you now rebooted the Pi and repeat the steps above, the device is still listed in ola_rdm_discover -u 1 -f, is that still the case?

As per the man page, discover with neither -i or -f just lists the UIDs in the universe: http://docs.openlighting.org/ola/man/man1/ola_rdm_discover.1.html

[peternewman]

Indeed looking at the captures confirms my theory, there is one TOD per universe when OLA is started, and none subsequently, so it hasn't polled to find out the responder has gone away.

[peternewman]

Looks like this is sort of related: https://github.com/OpenLightingProject/ola/issues/124

[ld3300]

@peternewman Thank you. I did not completely understand the -f requirement. It does in fact go away after a few seconds if -f is added to the command (ola_rdm_discover -u 1 -f). I guess I wrongfully assumed that using the raw command each time was actually broadcasting the discovery. I am not sure what I was doing wrong with -f the first time when I wrote the issue. It looks like it may be related to that other issue. Let me know if there is anything I can do to test and help.

[peternewman]

I think we don't generally do background discovery, apart from when requested in the Web UI, as it might de-prioritise DMX transmission when you want it, hence needing to use -f. The short delay will be waiting for a reply, or in this case timeout, from the Art-Net device.

I think the other issue is about a bug in the behaviour of a gateway device (and possibly a bug in a specific device), rather than a native Art-Net RDM device, so I'll retitle this.

It doesn't look like your Wireshark capture includes anything when the RDM was failing, but I guess we may be able to use a lack of ArtPollReply packets to either remove UIDs or trigger a rediscovery.

On a different note, I assume you're aware of our RDM tests, to check your implementation of RDM on your responder (although you might like to try the bleeding edge master release for even more tests): https://www.openlighting.org/rdm-tools/rdm-responder-tests/

And the model collector within them to publish some info on it when it's released.