Hi,
Wondering if anyone can help me, I am trying to control Caspar with Rossvideo Dashboard, I am trying to use the OSC commands but the Caspar Client crashes every time.
Does anyone have any idea what I could do?
Regards Birkir
what version of the client?
there is a recent build which should improve stability
I am using an older version,
Client is 2.0.8
Server is 2.0.7
Will try newer versions and report back.
I have no idea if a recent build of the client will work well with 2.0.7. That build of the server is incredibly old (from 2015!)
Tried newer versions of Client and Server.
Client is 2.2.0
Server is 2.4.0 beta1
Client still crashes 
I got the wrong version of client, I found 2.3.0 after I posted this and it still crashes
Oh ok, thats a shame.
Make sure to open a bug report with some more details such as the osc path you are using at Issues · CasparCG/client · GitHub and I might be motivated to try and fix it
I have recently done extensive testing of the OSC control system, and crashes are very rare for OSC message receive. The distribution of client 2.2 as part of server 2.2 does have an issue of crashing when the client emits an OSC message, but the later version that Julian suggests is good.
Sometimes, when there is no other reason for a detected problem, it is worth deleting the client database then restarting the client to create a fresh instance of the database. The client database on the windows client defaults to a file called Database.s3db in folder c:/Users/<my_user_name>/.CasparCG/Client/. You can modify the location or name using a command line switch and the new location and file name.
It is possible to use various OSC structures for the control message, but the ideal message has a single integer parameter with value 1, but sending a boolean type ‘true’ works, as do the float and double parameters provided they evaluate as non-zero.
You can use the client to send messages to itself, thus removing any possible issues with the message sent by the Ross.
Perhaps its an issue with parameter types or counts being wrong and the client not validating data correctly?
Either way, it would be good to know what was being sent so that it can be investigated and hopefully fixed.
I don’t think I’ve ever done osc with the client before, so don’t know what to start with testing
@Julusian - Julian, that is a very thought provoking post. I have only ever tested the OSC services in the client through well-formed messages. Generally either messages from a CaspaCG client on computer 2 client emitting OSC to a client on computer 1, or using the generic OSC output in Companion. I have never tested thus far using badly formed messages…
I think line 83 of src/Osc/OscControlListener.cpp testing that the message begins with ‘/control’ will filter off many potentially bad messages before final checkings and control event dispatch.
@Birkir - can you please have a check your client log file (in c:/Users/<my_user_name>/.Casparcg/Client/Logs) and tell us if the client logs the recepit of an OSC control message before any crash. The log entry is of the form Received OSC control message over UDP from 127.0.0.1:3250: /control/vid2/play (3250 for clients 2.2 or later, 6250 for client 2.0.8).
If you have Wireshark available on the computers in use it would also be helpful to see a screen grab pf the actual OSC message so we can check that the three fields within the message have lengths that are multiples of 32 bits.
Andy
Oha, why is that?
sorry cliked the wrong button
again
Yes we used the latest client with osc very aggressivly on a recent job
in combination with companion.
and it had no problems at all.
What you could try is to put
in between it’s been a good trouble shooter in the past for me.
I’m no osc expert but maybe it has to do with sending bundles or the opposite.
while the client expect one or the other… sorry bit vague
grt
Maurice
It is about the philosophy of message validation in client-server operations. It is appropriate for the server to try to defend itself from invalid requests, but how extensive can that test be?
In a handshaking control protocol, such as AMCP, the server signals the client with staus responses, but with a unidirectional flow such as OSC what onus do we place on the client to form a vaid message?
Thanks for the pointer to that tool. As well as the message testing, it will be useful for a colleague who wants to do some scene recalls on an ETC Congo desk using the CasparCG client controller on his MacBook Pro.
Your question about bundles prompted me to test the CasparCG client (2.0.9 branch) with a single control message both direct and wrapped in a bundle. Pleased to say that both methods worked.
I also checked if wildcard addresses worked in CasparCG client. Some OSC servers support widcards in the address field. If the control field contains similar names, for example headline1 and headline2 then an Osc message /namefield/headline?/play would trigger actions in both headline1 and headline 2 sections. CasparCG client does NOT support such wildcards. Sticking with groups in the client and Osc controlling the group is easier to understand and debug!.
Andy
I tried some things again and used Wireshark and it seems that I am unable to send the control int 1 so I am not sure what to do next. I tried looking at what Companion is sending with wireshark and its the same message just with the 1 for the control.
And the OSC router it captures the message and sends forward, just the control int 1 missing so it’s not triggering caspar, but caspar is not crashing.
Pleased to hear that the crashes are no longer happening.
I’m not sure how much detail you know of the structure of an osc message, so I’ll just insert a short expanation here with apologies if this is already known to you. OSC messages may be single commands, or multiple single commands can be wrapped as a bundle to deliver several messages in a single network packet. CasparCG OSC triggers are normally single messages.
The simple OSC message has a minimum of two elements, and usually a third element as well.
Element 1
This is the target OSC address, for example /control/tr1/play for CasparCG client osc trigger. The string is converted to a C language string with a terminating null character. Now for the fun bit - if the message length including the null character is not a multiple of 4 bytes more nulls must be added to the end to force a multiple of 4 bytes. The example message is 17 characters long with the terminating null making 18 characters. Therefore two extra null bytes must be appended to make element 1 20 characters long.
Element 2
Lists the types of parameters in the message. Element 2 starts with an ASCII comma, then there are designated characters that identify the parameter types and order that follow. If there is just an integer to send element 2 is the string ,i followed by 2 null characters (that multiple of 4 bytes again). If there is just one boolean value the second element starts ,T for true or ,F for false again followed by two null characters.
Element 3
This is the list of values identified by the sequence of letters in Element 2. It is omitted if the message only has boolean values. Where there are two integer parameters (element two = ,ii) there will be two blocks of 4 bytes containing the integer values encoded as big endian two’s complement value. Thus an integer with value 1 is the 4 bytes 0x00 0x00 0x00 0x01.
As best I can tell, DashBoard does not have direct support for OSC messages, but it does have support for UDP transmission.
There is a question in the Ross communities boards about sending a big endian integer. Post number 9 in the thread includes the code needed to create an OSC structed set of bytes to send using thee built in UDP mechanism. The post can be seen here.
It is also important when building the messages to ensure the osc address does not use any of the reserved characters which are ' ' (space character) # * , / ? [ ] { }.
A second way to get DashBoard to send an OSC command to CasparCG is to use middleware to convert message formats. The most obvious middleware is Bitfocus Companion. You can set a button on a page to emit an OSC message, and press that button using an asynchronous HTTP GET message supported natively in DashBoard.
Andy
I used the open source Packet Sender (Available from Github) to fire correctly formatted OSC messages at the CasparCG standard client.
I then adjusted the message to introduce a format error, such as incorrect number of null characters after the target OSC address element. Any format error in the structure of the OSC message crashes the client.
Client versions 2.0.9, 2.2, and 2.3 all crash when they receive a badly formed OSC message.