Hi all!
A question for those who develop applications for managing graphics (html templates).
It would be very interesting to know how you get the current playout state. The current implementation of the INFO command only tells you the name of the template and the layer on which it is running. But what if you have many uses of the same template with different text in your playlist?
How do you understand which of these templates is currently active in the playout?
Personally, I save the state of the running templates in my application:
But new tasks require more detailed information.
Ideally, when I run the html template, I could get a unique request id that would be visible as a result of the INFO command. This way you can find out exactly who is the initiator of the active template.
Interesting idea. But I do not understand, why you would want to know that at the first place. What application would anything like that have? Could you explain your usage scenario?
I will try to explain.
For example, you have a playlist (rundown) in which there are many templates and they can be repeated with different text content, since, for example, in a news release there may be many topics that use the same graphics.
There can be many such playlists for different programs at different times.
at the moment all you can get from the casparcg server is that the template “xxx.html” is running on layer “n”. Having added the functionality that I described earlier, with remembering the sent content, we now know that on layer “n” “xxx.html” is running with the text “hello wolrd”.
Knowing this, we can highlight a specific template in the playlist - it is active now (on air).
However, what if you use templates without text? in your playlist, all templates of this type will be labeled “on air” - this is a bit messy.
If we could set a unique id for each template that runs, we could better manage the state of the application. We will know who/when launched this template and what text is currently in playout with 100% accuracy if we remember the returned id and save it with the payload that was sent when the template was launched.
Specifically for me now this is important because in addition to playlists I am developing functionality and on my server at the same time there will be:
graphics that are launched via API from a third-party playout system (age restrictions, advertising, etc.);
graphics launched manually by the director during the broadcast;
graphics that work according to a schedule with repetitions and timeouts.
Moreover, the same template can be in the news rundown and also in the playlist that runs automatically according to a schedule - in this case, I definitely need to know - “xxx.html” layer “n” is launched according to a schedule or it is launched by the director or it is launched by api.
I did understand this, but I still not got the point.
All activity on a Caspar server is done by sending commands to it, so nothing happens “out of the blue” and sneak into it, without the system knows about it.
So the easiest way would be to build a software “around” CasparCG server, that redirects the standard out (console) of the server. You then get every information on who (IP-address) sent what command with what argument on what channel and layer. You can easy look at a log-file to get an idea, what informations you get. I think with a bit of programming you can get everything you want and more this way.
For “normal” users it’s not of interest to get all these informations, so I would not make sense to build something, like what you suggested, into CasparCG server. Even these INFO commands are not used in many situations. Most people only play and stop stuff and look at the output to see, what their doing
Thanks for the answer.
Your words make a lot of sense, this is probably the most direct solution for reading the state.
Previously I thought about this but did not resort to it, trying to dance around to be less invasive for the CasparCG servers since there are many of them and they are located in different locations.
This is not so invasive, as it does not touch the servers source code. It’s only a simple trick using a simple functionality that Windows offer to all console apps.
A few years ago, when we where starting the development of Sofie (https://www.sofieautomation.com/) I was working on these questions as well. I thought about various ways to send commands and how to implement state syncing and the solution we ended up with was our timeline-based library TSR (GitHub - nrkno/sofie-timeline-state-resolver: Sofie Timeline State Resolver: A Part of the Sofie TV Studio Automation System), which actually only syncs the state at startup, then it assumes that no one else touches the things we control and that the state TSR keeps track of internally is the “truth”.
If you don’t make that assumption and actually want to know and use the “real” state of the device, you would have to reach out to Caspar to re-check the state every time before you send a command to it. Unfortunately, this proved to be unviable for us, as it introduced latency and reliability issues.
So, my recommendation when implementing a controlling application is to assume that you have full control and keep your state internally in-memory and base your gui and commands based on of that.
If I recall correctly, there was some feature from a fork (NRK?) that allowed for tagging a clip or a template.
This is a totally valid request that would simplify client develompent for playlist based applications.
I was hoping for a way to do this since day one.
Two way communication between templates and clients and clip ID when playing out in a common layer would be a game changer.
Today some of those requirements are solved by using websockets within the templates, but still playing videos in a layer are not easily identifiable from the client side.
Is there any possibility to actually tag the producer when loading or playing so it would show up in OSC status messages?
Like: PLAY 1-10 {hash} PATH/TO/MEDIA
That way, as long as that individual producer is running on that layer, OSC messages would carry that hash string.
Is that somewhat viable with the current command architecture or is it a far fetched request? I’m just ranting.
Thank you for your answer.
You are right, since I already use my state to store the text content of templates, why don’t I expand it with data about who launched the template from which rundown, from which broadcast, and so on.
Now I store it in memory, but I’m thinking of going further and moving it to redis, which will allow me to share it in the future with other services if necessary.
