As a beginner with Caspar CG, I want to integrate it into an amateur audiovisual production system to broadcast recorded media from a TV newscast and the graphic design. In the future, I would like to have a server PC with a Decklink card to output 2 to 4 streams, and a client Mac to control it, all over a local network.
Currently in the testing phase, I’m encountering numerous problems, particularly with control from an external client.
Even though I follow the tutorials, as soon as I open the client (on the same network), it closes almost immediately. Note that both the client and the server work perfectly well from the Windows Server. I have both image and sound… But it’s impossible to control it via a different client.
Here’s my setup:
CLIENT: MacBook Pro M3 - OS X 15.2
SERVER: HP Pavilion Gaming Laptop 15 - Windows 11
I’m very used to Mac OS, but I’m a bit lost on Windows… and I have no coding knowledge…
Unfortunately as a primarily linux user, it running fine on my m1 mac mini, and noone really looking after the client these days, I dont know how to go about fixing this.
All I can suggest is run the client on a non-macos machine, or perhaps try a different client? New CasparCG client: SuperConductor released is one that people I work with recommend (because they made it)
Having see the post about the client crash I tried client 2.3 on MacOS 15.3.2 and I see the same issue of a crash. The OS reports the culprit is the OSC thread.
I tried client 2.2 which is available on the github client repository, and this works fine with server 2.4.x. This will let you try the standard client, and then you can compare the standard client operations with the Superconductor client. If client 2.2 does not start, delete the configuration database which is in a hidden folder:
Macintosh HD/Users/<username>/.casparcg/client/database.s3db
then start the client and edit the configuration.
I will need a few days to run more tests to try and find if the issue is the client or the MacOS version(s). Some time ago I loaded client 2.3 onto an Intel Mac, and it controlled my server instance correctly. I have subsequently upgraded the OS from 14 to 15.3.2 which stopped the client connecting to the server, but it did not crash the client.
I have run the OS update tonight on the Intel processor machine bringing it to OS 15.4, and now client 2.3 is working again with no other changes. So I need to see what happens if I try the OS upgrade and also to see if the Intel versions of the Mac client has the same behaviour when run under Rosetta 2. I will report the outcomes of the tests.
I’m familiar with Superconductor, having used it at work for a major TV channel (Bein Sport). But it’s not suitable for my needs. The Caspar CG client seems perfect for my use in associations.
For version 2.2, it won’t even open, even after deleting the database folder.
The problem occurs on the 2.3 client.
My final use should be on an Intel Mac Mini. So I’ll try the device directly from an Intel Mac Mini, and I’ll let you know.
However, if by then you’ve found a solution on the client for an ARM Mac, I’d love to hear it!
I’ve managed some testing today, but it will take time for me to make a coherent statement about the findings. I have managed to get a version 2.3 client to run on an Intel processor running MacOS 15.4 (an iMac), on a M3 Pro laptop running MacOS 15.3.2 and MacOS 15.4.
The ARM version of the client crashes on the M3 Pro laptop on both 15.3.2 and 15.4. However I ran the V2.3 client build for Intel (x86) processors on the M3 Pro machine - and that ran on both versions of the operating system.[EDIT: Issue identified and solved by Julian in post 7. I have found 1 small oddity so far - when the 2.3 Intel client runs on the M3 Powerbook the F3 keys issues a LOADBG instruction to the CasparCG server instead of the expected LOAD.
The same client on an Intel processor with OS 15.4 issued a LOAD command as expected.]
So hopefully the Intel 2.3 build could work on both your Mac Mini and your ARM laptop.
I know this is April Fools Day - but this is not a joke!!
Andy
That sounds like a config issue, by default the client uses LOADBG, which can be changed per item in the rundown (freeze on load checkbox), with the default of that changable in the settings.
Any chance of a screenshot or more details here? It runs for me on 15.2 M1, but as I have been building the client on here in the past maybe there is some remnant of that which is making it work?
Julian,
Good spot on the load flag - usually I set the default to freeze on load as my first config edit, but I was trying to prove I could multitask (and I failed!!).
Relevant segment of Server log during client start-up and close:
[2025-04-01 18:15:54.537] [info] async_event_server[:5250] Accepted connection from 192.168.xxx.25 (1 connections).
[2025-04-01 18:15:54.562] [info] Received message from 192.168.xxx.25: VERSION SERVER\r\n
[2025-04-01 18:15:54.563] [info] Sent message to 192.168.xxx.25:201 VERSION OK\r\n2.4.3 fd9168c Stable\r\n
[2025-04-01 18:15:54.571] [info] Received message from 192.168.xxx.25: INFO\r\n
[2025-04-01 18:15:54.571] [info] Received message from 192.168.xxx.25: CLS\r\n
[2025-04-01 18:15:54.571] [info] Sent message to 192.168.xxx.25:200 INFO OK\r\n1 1080i5000 PLAYING\r\n2 1080i5000 PLAYING\r\n\r\n
[2025-04-01 18:15:54.571] [info] Received message from 192.168.xxx.25: TLS\r\n
[2025-04-01 18:15:54.572] [info] Received message from 192.168.xxx.25: DATA LIST\r\n
[2025-04-01 18:15:54.572] [info] Received message from 192.168.xxx.25: THUMBNAIL LIST\r\n
[2025-04-01 18:15:54.573] [info] async_event_server[:5250] Client 192.168.xxx.25 disconnected (0 connections).
[2025-04-01 18:15:54.617] [info] Sent more than 512 bytes to [destroyed-connection]
[2025-04-01 18:15:54.633] [info] Sent more than 512 bytes to [destroyed-connection]
[2025-04-01 18:15:54.637] [info] Sent more than 512 bytes to [destroyed-connection]
[2025-04-01 18:15:54.671] [info] Sent more than 512 bytes to [destroyed-connection]
Section of the Apple Crash Report (Full report too big to upload in this forum). If ou require the full version I’ll need to dropbox it to you.
Julian,
I have run several ARM client tests this morning - all point at issues in the ARM client OSC support.
When I turn off the Listen for OSC status and Listen for OSC control on the client OSC configure tab, then start the client with a server 2.4.3 instance on the network the client starts and runs and is able to select and play media files (The Intel client had loaded the Client 2.3 database with names and thumbnails).
I shut down the server instance and enabled the OSC listen in the ARM client. I sent OSC messages from another CasparCG client directed at the ARM V2.3 client instance. In all instances the ARM client crashed as soon as it received an OSC message.
I used the ARM V2.3 Client to send an OSC message at another CasparCG client - the ARM client crashed, this time the Apple crash report said the main thread had crashed.
I was unable to test OSC over WebSocket sent at the ARM client because a previously working demo of a web page operating as a shotbox and remote keyboard (/control/play /control/up etc) has stopped working, complaining the websocket could not open. It will take some time to discover what has caused this - I suspect increased security elements in one or both Windows 11 used for my testbed Caspar server and MacOS 15.
[EDIT - Ammend]
Using a different computer as the HTML page host I tested the ARM client control using websocket messages. As one might expect from the different code block in the client this remote control over websockets worked without causing any crashes.
Thanks, that made it easily reproducible. I can point the client to its own OSC port and when sending a message it crashes.
Now I just need to find time to dig into the cause