Re: CasparCG Client - from Repository

#2
I've never used this before myself, so I'm going to quote Jesper on this:
Jesper Stærkær wrote:It is an undocumented but REALLY cool and clever socket
You do an http to an enpoint
The endpoint is the "repo"
Giving back a list of "rundowns"
Which basically just is an id
Opening from that window opens a socket
With that id
And you can feed items to the rundown and remotely manipulate it in realtime
I'm also going to quote Peter Karlsson, but I don't know how valid this is currently:
Peter Karlsson wrote:
22 Dec 2014, 09:58
We have developed a iNews backend for the client. The backend generate rundowns (or changes) from iNews. It's a very flexible solution based on templates and profiles on the backside. From the client perspective it's just read-only repository.

We can hopefully release it as open source, but we are not there yet.
CasparCG enthusiast and broadcast geek

Re: CasparCG Client - from Repository

#6
I am still investigating. What I found out, of expanation from Armin of SVT and studing the code https://github.com/CasparCG/Client/tree ... Repository, is this:
  • If you request the URL without parameter, it seems that you get a list of avaliable rundowns. (Code inside "OpenRundownFromUrlDialog.cpp") In some format, probaly XML or just strings separated by CR/LF, I don't know yet.
  • Then you can send a SUBSCRIBE to the server with a rundown-name and a profile as argument. What the profile is or does? I don't know.
  • The server will then send you ADD or REMOVE messages back, on every change (an update is a REMOVE followed by an ADD). There comes a "StoryID" on every such event. This id can also be found on every entry in a XML file stored with the client (usually empty). This can be any string like a number or GUID. The rest of the message is a XML similar to an entry in that same XML file somehow.
Based on these ADD and REMOVE events the client will update it's list of events. So there are a few questions open still but it starts to make some sense. Anybody knowing more is kindly invited to share his or her knowledge here.
Didi Kunz
CasparCG Client-Programmer, Template Maker & Live CG-Operator
Media Support, CH-5722 Gränichen, Switzerland http://mediasupport.ch/
Problems? Guide to posting Bug reports & Feature requests

Re: CasparCG Client - from Repository

#7
One more step:

Parse incoming ADD and REMOVE command, e.g:

ADD\r\n
StoryId\r\n
<xml><data></data></xml>\r\n\r\n

The XML format is standard XML client data and must include a valid story ID.


REMOVE\r\n
StoryId\r\n\r\n

Story ID is a unique ID of some sort.

So the ADD command is a string with 3 lines of text separated by CR/LF (\r\n in c++) Where the first is the ADD literal, the second ist that StorryId used to indentfy the event and the last is the XML string in the same format that the client uses to store it to disk. The <storyid> field inside this XML needs to contain the same StoryID. The whole command ends with a double CR/LF.

The REMOVE comand is simpler it only contains two lines, The word REMOVE on line 1 and the StoryId on line two. Also two CR7LF to terminate.
Didi Kunz
CasparCG Client-Programmer, Template Maker & Live CG-Operator
Media Support, CH-5722 Gränichen, Switzerland http://mediasupport.ch/
Problems? Guide to posting Bug reports & Feature requests
cron