OSC network commands

[DesignTagline]

I am having some issues with the OSC plugin triggering. I believe the issue is something to do with the translation of the sending application that has address and argument fields (only address should matter to FPP as I am not using conditions) 
I have the sending application using /stop  (I've tried a variety of commands)
And the FPP log says its getting OSC commands as I can see it in the FPP log

[Plugin] src/FPPOSC.cpp:499: OSC Process Packet
[Plugin] src/FPPOSC.cpp:499: OSC Process Packet
[Plugin] src/FPPOSC.cpp:499: OSC Process Packet

But no messages appear in the config tab. Sending the message to an OSC diagnostics application I see all the messages.
RECEIVE    | ENDPOINT(192.168.100.126:33863) ADDRESS(/Stop) STRING(1)
RECEIVE    | ENDPOINT(192.168.100.126:35400) ADDRESS(/Stop) INT32(1)
RECEIVE    | ENDPOINT(192.168.100.126:40827) ADDRESS(/Stop) STRING(1)

Is there any filtering or anything that FPP could be doing? I suspect the issue is the way FPP is processing the input

[DesignTagline]

I should note I am also chasing this with the manufacturer of the transmit device (enttec) as I believe it could also be something wrong in their OSC implementation and artnet triggering works for now so its not a show stopping issue for me.  

[DesignTagline]

Without diving too deeply I suspect the FPP is a lot more sensitive to malformed messages than Protokol. 
Sending a message from TouchOSC works for FPP and looking at it in Protokol (where it does show up) shows no difference however when I use wireshark I notice the length of the message is different. 
TouchOSC: 
0000   60 3e 5f 47 3d 8b 24 5a 4c 72 6c 3d 08 00 45 00   `>_G=.$ZLrl=..E.
0010   00 30 e2 1b 00 00 3f 11 3a 92 ac 1f 02 6c ac 1f   .0....?.:....l..
0020   04 65 ff ff 1f 40 00 1c cd 88 2f 62 75 74 74 6f   .e...@..../butto
0030   6e 31 00 00 00 00 2c 66 00 00 00 00 00 00         n1....,f......
Same message from sPlay
0000   60 3e 5f 47 3d 8b 24 5a 4c 72 6c 3d 08 00 45 00   `>_G=.$ZLrl=..E.
0010   00 44 5f 22 40 00 3f 11 06 dc c0 a8 64 7e ac 1f   .D_"@.?.....d~..
0020   04 65 96 45 1f 40 00 30 5e 29 23 62 75 6e 64 6c   .e.E.@.0^)#bundl
0030   65 00 00 00 00 00 00 00 00 01 00 00 00 14 2f 62   e............./b
0040   75 74 74 6f 6e 31 00 00 00 00 2c 69 00 00 00 00   utton1....,i....
0050   00 01                                             ..
It seems to add on #bundle before the actual OSC message. I suspect the issue is an enttec related one. 

[dkulp]

The FPP OSC plugin didn't handle OSC #bundles as I have never seen one.  None of the apps on my iPad that I use to generate OSC messages use bundles.    

I just updated the plugin to possible handle this.   If you could give it a try and let me know, that would be great.   It's completely untested as I don't have a way to test it so your feedback would be great.

[DesignTagline]

Hello Daniel, amazing work making the change so quickly.

I updated and tested this morning and had no luck I am afraid. Is there any diagnostic information I can send to assist?

Doesn't look like its processing the OSC messages at all now as nothing appears in the log.

[DesignTagline]

Enttec were not helpful and stated
Thanks for the detailed information.
Unfortunately, the team is unavailable to push out any quick turnaround S-Play changes, especially given that the S-play does appear to be sending out correct OSC data with its use of bundles being as per the OSC spec.

[DesignTagline]

I think that change broke the plugin as also sending non bundled OSC messages doesn't show up in FPP either.

[dkulp]

I think that change broke the plugin as also sending non bundled OSC messages doesn't show up in FPP either.

You may want to re-try updateing to the latest for both FPP and OSC.  I'm definitely seeing OSC events.
You cannot view this attachment.

[DesignTagline]

A reboot solved it and I can see OSC messages again (And I can see the bundles in the log) but its not processing them.

Is there a way of enabling more logging for you that may help you?

I've been running on 7.5 if moving to 8.0 would help I am open to it. 

[dkulp]

I just added some more debug logs during the bundle processing.  If you can update, then turn on the Debug level for plugins, and then re-test, it might be helpful to see what is output into the fppd.log.

[DesignTagline]

That looks to have helped. I get the following in the logs no matter if its an int, string or float
src/FPPOSC.cpp:499: OSC Process Packet
src/FPPOSC.cpp:548: Unknown OSC packet  23 62 75 6E

[dkulp]

Made a simple fix... can you update and try again?

[DesignTagline]

Thanks, its still not triggering or showing up on the OSC page but in fppd.log we get the following:
2024-08-18 12:45:22.409 (1857) [Plugin] src/FPPOSC.cpp:499: OSC Process Packet
2024-08-18 12:45:22.409 (1857) [Plugin] src/FPPOSC.cpp:518: Found #bundle Packet
2024-08-18 12:45:22.409 (1857) [Plugin] src/FPPOSC.cpp:526:    Index 20:  Size: 0    First: 6F68532F

[DesignTagline]

It seems like the issue is that it sees the bundle size as 0. That is about the length of understanding of that prompt. 

[DesignTagline]

Looks like more diagnostics have been enabled. Here is the latest from the log when sending a string value from the sPlay
2024-08-23 11:00:19.474 (1691) [Plugin] src/FPPOSC.cpp:499: OSC Process Packet
2024-08-23 11:00:19.475 (1691) [Plugin] src/FPPOSC.cpp:518: Found #bundle Packet: msglen: 36
2024-08-23 11:00:19.475 (1691) [Plugin] /opt/fpp/src/common.cpp:156: Msg Data: : (36 bytes)
2024-08-23 11:00:19.475 (1691) [Plugin] /opt/fpp/src/common.cpp:183: 000000: 23 62 75 6e 64 6c 65 00 00 00 00 00 00 00 00 01 00 00 00 10 2f 53 68 6f 77 30 00 00 2c 73 00 00    #bundle............./Show0..,s..
2024-08-23 11:00:19.475 (1691) [Plugin] /opt/fpp/src/common.cpp:212: 000020: 31 00 00 00                                                                                        1...
2024-08-23 11:00:19.475 (1691) [Plugin] src/FPPOSC.cpp:527:     Index 20:  Size: 0    First: 6F68532F