I’m facing a huge problem with a playout client. It’s a very simple playlist-based client and so far I didn’t have any issues in production environments.
I recently implemented a feature called “Schedule” (I think it explains itself), so any item in the playlist can have a start date and time and it fires up immediately or after the current item is finished.
The problem I have is that after some time that the system is idle it seems that the objects in the playlist (or the MediaInfo object associated to it) get garbage collected and fire up a NullReferenceException when the Timer class attempts to play it. It never crashes after short periods of time (eg. an hour) but it does after 10 hours or so.
Have you faced this problem? How can I prevent the GC from getting rid of the instances? They seem to be still referenced in the objects but when they’re called they are gone.
That is quite weird. There must be something else going wrong, as I never heard nor experianced some objects, that still are referenced beeing garbage collected.
As I investigated (quickly, not thoroughly), there are methods to prevent an object from being garbage collected using GC.KeepAlive.
The most probable cause of garbage collection is that objects are not referenced or are empty at a given moment, so probably a strategy to keep the object from being collected is to keep it non empty with a dummy element or something.
I’m having this problem in a client too, so I might try to get a shot to this situation.
Well I feel a little better now that I’m not alone with this issue.
I indeed use CG.KeepAlive() for some objects that would not change over the app’s life. But that solution seems to lock it down and you actually have to manage all those instances manually to force garbage collection on them.
If I keep alive all MediaInfo instances in the CasparDevice class and then call RefreshMediaFiles(), those instances would remain in memory and would have a bigger problem.
The way I have set up the client is this (only for people with lots of patience):
A PlaylistHandler class contains a collection of PlaylistItem which contains a string with the path to the file in the server, not the actual MediaInfo reference.
When a PlaylistItem object is called, a Media property calls a GetMedia() function in CasparConnection (that looks for the file in CasparDevice and returns the reference, if no file is found it returns null which is handled in all the playlist management functions but not in the playout functions as it checks for null media on MediaUpdated and marks it as offline.
In theory, if the media library is not updated, that object should never change or get garbage collected. But it does.
As I said above, I had never such a issue and I do .NET programming for quite a while now. Do you use any database to object mapping tools (like EntityFramework) to load your playlist? I mostly use these kind of stuff and never had any issues with grbage collection. Also loading from XML gives me objects, that stays in memory.
OSC data updates the PlaylistHandler timecode data (after some filtering). When the timecode is updated it calls a CheckForEvents method that change the PlaylistItem status (Idle, Playing, Paused, Ending, Outro, Ended) according to some thresholds.
Outro and Ended status fire up a OnMediaEnded event that calls a LoadNextItem if the list is in Playlist mode.
Not at all. I do all of that manually
I load an XML and instantiate all the objects parsing that. The playlist actually stays only in memory unless the user decides to save it to an xml.
I have an application for the parliament in Liechtenstein, were I use the same thing, loading an object tree from a XML-File. These objects stay in memory for the whole day, whit out any issue. Sometimes they got saved, sometimes not. That’s why I don’t understand why you have that issue.
I think it might be related to the system being idle for so much time (overnight) without any mouse input. That problem only shows up on weekends when all the programming is prerecorded. And the only playing item is a channel id card.
Just to confirm that this never happened with my C# clients, and had some of them idling for 24h before being used once a day, and going like that for months.
I believe this has nothing to do with SVT C# Caspar library, very likely something in the current version of the .NET Framework you are using.
I’m also workin on playlist controler and it’s not a easy task. I’m faced to a lot of problem also, according to the number of item that you can load to control caspar.
I think you can manage your playlist resource better, in term of performance. I don’t think it’s a good choice to load all the playlist elements.
For your problem of Garbagge collection, it’s mean that your object is not referenced in the memory and the gc collect him.
I think you need to separate the playlist view (that the client see), and the playlist that control the server.
In the playlist that control the server, you can load 10 or 50 elements and when an element is played, get the next element in the playlist datasource (like a FIFO). The controler can trigger event to playlist view to update the state for the client.
