forwarder not working alpha 8 & 9

panec · 27. November 2020

It might be that I do not know how to use it, or that it does not work. The amount of information about how to use it is sparse and I might be missing something. I have testes this on Alpha 8 & 9 versions.
What I have is:

Server RPi4 with Hyperion NG Alpha 9 (192.168.1.75) that is driving the LEDs with following config:

JSON Server on port 19444
Flatbuffers Server on port 19400, timeout 60s
Protocol Buffers Server on port 19445, timeout 60s
Forwarder is disabled

Grabber RPi3 with Hyperion NG Alpha 9 (192.168.1.77) that is capturing an image from RPI camera that I want to forward to server with the following config:

Flatbuffers Server is disabled
Protocol Buffers Server is disabled
Protocol Buffers Server is disabled
Forwarder
- JSON clients 192.168.1.75:19444
- Flatbuffer clients 192.168.1.75:19400

In the logs there is nothing that would suggest that the grabber instance connected to the server.
On the grabber there is a note that the service is starting:

Zitat

2020-11-27T15:37:11.404Z [hyperiond FLATBUFCONN] (INFO) Connecting to Hyperion: 192.168.1.75:19400
2020-11-27T15:37:11.405Z [hyperiond NETFORWARDER] (INFO) Forward now to json targets '192.168.1.75:19444'
2020-11-27T15:37:11.405Z [hyperiond NETFORWARDER] (INFO) Forward now to flatbuffer targets '192.168.1.75:19400'
2020-11-27T15:37:11.406Z [hyperiond COMPONENTREG] (DEBUG) (ComponentRegister.cpp:36:setNewComponentState()) Json/Proto forwarder: enabled
2020-11-27T15:37:11.406Z [hyperiond NETFORWARDER] (INFO) Forwarder change state to enabled
2020-11-27T15:37:13.462Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:351:setCurrentTime()) Set visible priority to 240
2020-11-27T15:37:13.464Z [hyperiond HYPERION] (DEBUG) (Hyperion.cpp:559:handlePriorityChangedLedDevice()) priority[240], previousPriority[254]
2020-11-27T15:37:13.816Z [hyperiond FLATBUFCONN] (DEBUG) (FlatBufferConnection.cpp:176:sendMessage()) Connecting to Hyperion: 192.168.1.75:19400

Alles anzeigen

but there is nothing on the server side to suggest that the connection came thru.
The netstat on the grabber shows this:

Zitat

pi@raspberrypi:~ $ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.77:ssh 192.168.1.110:50450 ESTABLISHED
tcp 0 1 192.168.1.77:57346 192.168.1.75:19400 SYN_SENT
tcp6 0 0 192.168.1.77:8090 192.168.1.110:50391 ESTABLISHED
tcp6 0 0 192.168.1.77:8090 192.168.1.110:49377 ESTABLISHED

Alles anzeigen

192.168.1.110 is IP on my desktop from which I access them.

Any suggestions what I missed or is it a genuine bug?

Luke28237 · 1. Dezember 2020

Hi,

I am having the same issue, tried many ways but cannot get it to work.

Hope there will be a solution soon.

Luke

mg3point · 11. Februar 2021

I'm working through a similar issue. I have two pi4 on Alpha9, one for lights around my tv, the other for an led strip i inlayed into a couch drink-rail. Seems if I reboot everything the connection works fine.

You essentially want the pi with the grabber to have forward enabled and the flatbuffer pointed to the pi you want receiving. Then on the receiving pi you want the flatbuffer checked so it will receive the data. This defaults to a timeout of 5 seconds and it should "soft timeout" but I have noticed that sometimes it does not come back after the signal to the grabber has been turned off and turned back on later.

It's a bit of an intermittent issue, I'm going to try setting the timeout on the receiving pi to 999999999 (that's like 11 days or something) and see if it keeps it online. If this does not correct the issue, I suspect it's something on the forwarding pi disabling something when it detects no signal.

Jetzt mitmachen!