My OLA is going shutdown suddently

33 views
Skip to first unread message

Ivan Kevin

unread,
Jul 28, 2021, 7:54:29 AM7/28/21
to open-lighting
Hi everyone,
On my OLA (installed on rasp pi 4) I executed my code for receiveing Artnet Packet. So far is working but after few minutes I got the following message:

common/io/Descriptor.cpp:361: Failed to send on 6: Connection reset by peer
common/rpc/RpcChannel.cpp:308: Failed to send full RPC message, closing channel
ola/OlaClientWrapper.cpp:71: Server closed the connection

Has anyone here already got this ? 
Could someone tell me why it happens, what I could have done wrong and how could I solve it?

Thanks in advance.

Peter Newman

unread,
Jul 29, 2021, 4:54:58 PM7/29/21
to open-lighting
Hi Ivan,

Do you mean you've written your own bespoke code linking to OLAd via the client API? Can you try running ola_dmxmonitor instead and see if it still crashes then (to work out if it's your code or olad/the Art-Net sender at fault):

Can you also share the olad -l 4 logs:

How did you install OLA, from a deb, from source or? What version does it report?

Ivan Ngonou

unread,
Aug 11, 2021, 9:54:48 AM8/11/21
to open-l...@googlegroups.com
Hi Peter, thanks for your feedback.
Exactly, I've written a program which is linked to Olad via OLA Client. 
I got this version of OLA: 0.10.7.   For the installation I've just followed the first steps on the link: https://dave.thwaites.org.uk/raspberrypi/ola-on-raspberrypi.html. (apt-get install ola).

When it crashes, the Arnet transmitter still works, but no more data is intercepted by the program. only when I restart olad and my program, it does work again. 

Here are the last entries of olad -l 4 report:
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/EPoller.cpp:306: ss process time was 0.000010
common/io/EPoller.cpp:306: ss process time was 0.000004
common/io/EPoller.cpp:306: ss process time was 0.000004
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/EPoller.cpp:306: ss process time was 0.000012
common/io/EPoller.cpp:306: ss process time was 0.000010
common/io/EPoller.cpp:306: ss process time was 0.000004
common/io/EPoller.cpp:306: ss process time was 0.000004
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/EPoller.cpp:306: ss process time was 0.000011
common/io/EPoller.cpp:306: ss process time was 0.000007
common/io/EPoller.cpp:306: ss process time was 0.000005
common/io/EPoller.cpp:306: ss process time was 0.000013
common/io/EPoller.cpp:306: ss process time was 0.000011
common/io/EPoller.cpp:306: ss process time was 0.000008
common/io/EPoller.cpp:306: ss process time was 0.000007
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/EPoller.cpp:306: ss process time was 0.000011
common/io/EPoller.cpp:306: ss process time was 0.000013
common/io/EPoller.cpp:306: ss process time was 0.000005
common/io/EPoller.cpp:306: ss process time was 0.000005
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/EPoller.cpp:306: ss process time was 0.000010
common/io/EPoller.cpp:306: ss process time was 0.000006
common/io/EPoller.cpp:306: ss process time was 0.000005
common/io/EPoller.cpp:306: ss process time was 0.000008
common/io/EPoller.cpp:306: ss process time was 0.000011
common/io/EPoller.cpp:306: ss process time was 0.000009
common/io/Descriptor.cpp:361: Failed to send on 38: No such file or directory
common/rpc/RpcChannel.cpp:308: Failed to send full RPC message, closing channel
olad/plugin_api/Universe.cpp:360: Sink client 0x6c15a8 has been removed from uni 1
olad/plugin_api/Universe.cpp:360: Sink client 0x6c15a8 has been removed from uni 2
olad/plugin_api/Universe.cpp:360: Sink client 0x6c15a8 has been removed from uni 3
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 38
Received Segmentation fault
/lib/arm-linux-gnueabihf/libolacommon.so.0(+0x1b1f64)[0xb6c08f64]
/lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0x0)[0xb669b120]


On other side, I would like to know how OLA use to manage the Artsync signal in case we got many receivers. Has anyone any idea?.
Furtheremore is there any methode to increase the number of Artnet port IN so that I could receive more than 4 Universes?

Thanks for you help.
Mit freundlichen Grüßen / Best regards / Sincères salutations

Ivan Ngonou
B.Eng. in Elektro- und Informationstechnik
Diversity Manager bei Godhis Foundation e.V.
+49 176 56 87 98 29


--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "open-lighting" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-lighting/dc_pYqThy8A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/beb3a301-deaf-455c-b418-902242a524d6n%40googlegroups.com.

Peter Newman

unread,
Aug 12, 2021, 12:36:48 PM8/12/21
to open-lighting
Thanks for confirming. So as a first step, as I mentioned before, can you try running ola_dmxmonitor instead and see if it still crashes then (to work out if it's your code or olad/the Art-Net sender at fault):

You say it crashes after a few minutes, is that a pretty constant amount of time, or does it vary much? Anyway if ola_dmxmonitor works for say twice the average crash time, then it's probably the OLA client or your code at fault. If that also crashes then it's olad/the Art-Net sender causing the issues.

Assuming it's the OLA client/your code, you could use ola_recorder to capture a specific sequence of Art-Net that definitely crashes it, then try playing back from part way through the file to see if it's a particular sequence of DMX frames or just the number of received frames:

However the olad core shouldn't die when the client disconnects, so ideally we'd fix that somehow! See a similar issue here, which was due to lots of updates within OLAd, I wonder what frame rate your device is sending at:

You could try the --no-use-epoll option, which may stop OLAd crashing if there is a bug just in our epoll implementation, but its unlikely to stop the client/your program crashing.

If you're able to share your code, we might be able to help troubleshoot it. Otherwise you could start removing the more complicated bits of it to see if you can make it not crash and narrow down the cause of the issue. If you can give a high level overview of what your code actually does that might point to potential causes of issues.

We don't currently handle ArtSync input, or output. See the relevant code here:

We've got some equivalent behaviour in our SPI plugin which I keep planning to pull out into a class so we can re-use it in other places (like Fadecandy, Nanoleaf, here etc) but I haven't yet done so. I don't know if you want to take a look at that?

For extra ArtNet In ports, see the discussion in here, the standard restricts most simple fixes unfortunately:

Ivan Kevin

unread,
Aug 25, 2021, 5:05:33 PM8/25/21
to open-lighting
Hi Peter,
Thank you for your interesting reactions. OLA crashed because of my code.  I got this solved and I can reveice up to 15 Universes and not more. I want to manage more than 15 universes but  that requires apparently to create universes with differents subnets. I wish to have such a list of universes:
Uni 1: 0:0:1
Uni 2: 0:0:2
Uni 3: 0:0:3
Uni 4: 0:0:4
Uni 5: 0:0:5
Uni 6: 0:0:6
Uni 7: 0:0:7
Uni 8: 0:0:8
Uni 9: 0:0:9
Uni 10: 0:0:10
Uni 11: 0:0:11
Uni 12: 0:0:12
Uni 13: 0:0:13
Uni 14: 0:0:14
Uni 15: 0:0:15

Uni 1: 0:1:1
Uni 2: 0:1:2
Uni 3: 0:1:3
Uni 4: 0:1:4
Uni 5: 0:1:5
Uni 6: 0:1:6
Uni 7: 0:1:7
Uni 8: 0:1:8
Uni 9: 0:1:9
Uni 10: 0:1:10
Uni 11: 0:1:11
Uni 12: 0:1:12
Uni 13: 0:1:13
Uni 14: 0:1:14
Uni 15: 0:1:15

Is that possible.
Thank you in advance

Peter Newman

unread,
Aug 26, 2021, 9:38:27 AM8/26/21
to open-lighting
Hi Ivan,

Would you be able to share your code, or a small reproduction case? Regardless of what you do, OLA itself really shouldn't crash.

The Art-Net stuff is probably better covered in:

But in short it would be a change to how it currently operates at the simplest and isn't something that's a problem when following the Art-Net spec (due to the limit on the number of ports).

Do you mean your second list of universes should be 16-32 rather than 1-15 again?

The easiest way (if you're happy for them to start at 1 always) might be to add a mode where it just maps the OLA universe number to the full net:subnet:universe pattern.
Reply all
Reply to author
Forward
0 new messages