Screens go dark overnight


I have Xibo-player setup on Ubuntu 18.04.3 and overnight the screens go dark and the computers lock. I have set the computers to never sleep and disabled the lock screen in Ubuntu as well as have the “Prevent Sleep” option checked in the Display Settings for the Linux profile. I’m not sure what I’m missing here that is causing these machines to go to sleep every night.

Has anyone else had this issue and what did you do to resolve it. I have no problem changing distros if that will solve the issue.


I am having the same problem. It either goes dark overnight and I have to reboot the next day, or in some cases the player just freezes completely, leaving the current media item in a “frozen” state.

I’m currently troubleshooting this. I suspect it’s a memory leak. This evening when I went to check after a “freeze”, the player process had consumed 2GB of memory.

If I come up with any insights I’ll post them here. I’d also like to know what the Xibo folks have to say. And as always, I’ll do what I can to help with diagnosis (log gathering, etc.)

Quick update: I also now see 128% CPU time for the player process in top

1 Like

Another update – This ticket looks similar - you might want to monitor it:

Have you had the opportunity to try the edge version (rev 40) ? Xibo for Linux 1.8 R5 release candidate (rev 40)

Working on that today, in fact. Thanks Dan! Will keep you posted via this thread.

1 Like

@dan We found that the system went “dark” again today after moving to Rev 40. We then restarted the player and watched resources using top.

Over the course of 2 hours Virt memory grew from 2,201,056 initially to 6,203,144. We started watching Res memory about 45 minutes in to the test and found it grew from 1.7GB to 3.24GB.

After 2 hours the system showed a “black” screen in the frame (region) where the main content plays (we have 2 regions). It then went to a blank “Ubuntu purple” screen with nothing on it. The players then resumed with content running, but MUCH more slowly (and memory is still very high). I would expect if we leave it on, it will eventually crash.

If you’d like us to do anything for problem determination on our side to find the memory leak (or anything else) please let me know. Happy to help!

Update: At about 2hrs 35 mins after the start of the test, the system went to the Ubuntu login screen, indicating the player finally crashed.

Thanks for this.

What mix of content are you showing? I’m guessing Video if your memory usage is rising that high/quickly?

We have a r41 released to edge to try when you get some time please - we’re exploring whether the issue is in the build process and have made changes to that

We think we might have a fix for these memory leaks - there is a r42 in edge to try out please.

@dan Sorry to be the bearer of bad news, but it appears the leak still exists with r42. We started it just under an hour ago and it’s already gone from 2223500 Virt/315264 Res to 2841080 Virt/977GB Res.

To answer your previous question: the test Region consists of 3 items: 2 are static graphics (PNG/JPG) and one is a video (MP4).

We’ll keep it running to see how long it takes to max out. Please let me know if I can do anything further.

No problem - thanks for the feedback all the same. We will continue to chip away at it!

Just to keep you in the loop here, we’ve been experimenting with Gsreamer 1.16 (Ubuntu 18:04 has 1.14) and it seems better for memory leaks.

Gstreamer as a project are fixing leaks all the time, so taking the newest version is a good idea.

Unfortunately there isn’t a package for it and we’d need to build it from source - we’re working on that.

Fantastic! Happy to test as soon as you’re ready.

1 Like

Hi guys,
i have/had the same issue with my test-system.
i’m running opensuse leap 15.1 kde (default setup, no special modifications).
but since i added the leap 15.2 repository and changed the kernel-default from 4.x to version 5.3.18-lp152.1.4 and gstreamer to version 1.12.5-lp152.3.4 the system runs stable, ram and swap don’t run into 100%
snapd 2.43.2-lp151.1.1
xibo-player 1.8-R4 Rev37

maybe you want to try this on an ubunutu system

Thanks for your feedback - we’ve also had some success with building a newer gstreamer than what we were using already.

Hopefully an update on that soon :crossed_fingers:

Hi, guys!
I’m try running Ubuntu 19.10 with gstreamer 1.16.1-1, Ubuntu 18.04.3 with gstreamer, Ubuntu 16.04 with gstreamer 1.8.3-1. I’m tried xibo: 1.8-R4 37, 1.8-R4 40, 1.8-R4 42.
A memory leak is everywhere. It’s so sad. What is the temporary solution to the problem? Maybe use version 1.8-R3?

Only the version of Xibo matters as it is a snap and brings its own dependencies - unfortuately we don’t have a solution yet, but we are working on it.

Best thing is to sit tight and keep an eye on this topic for an update.

Are there any changes?
Now i have to do a restart from crontab, to free memory, it is very inconvenient.

We don’t have anything to release yet - it is a really hard problem to solve. I’ll update all of these topics when I have news. Thanks.

The Xibo Community site uses cookies. What are cookies?