The player uses all the RAM

It seemed that the problem was solved by installing Debian 9 nonfree.
But with the playback of each next video, the player eats up a little more RAM … and in the end it still crashes …
on ubuntu 18 and debian 10 the video for some reason sometimes slows down, as if it starts to play at 10-15 fps…

What more information should I give?

player - --edge - 49 version

Hi,

I am not clear why you have so many player processes open - this implies that they are restarting without stopping the old ones.

Can you kill them all off please, and then start the player using the cli instead? It will then output some logs which should give us more information as to what is happening.

Thanks!

My player starts from the terminal with the following line /snap/bin/xibo-player
but xibo-player in cli - writes note found

What mistakes did you mean? Like these? Are there any other logs somewhere?

Thanks - i’ll pass those logs to the team.

The team have asked what you are doing in start.sh - snap does some bootstrapping that you might be bypassing by starting the binary directly.

Can you start the player using xibo-player instead and see if the problem persists?

in script start.sh -
#!/bin/bash
/snap/bin /xibo-player

in the desktop lxde - command xibo-player is not found
so I run the command /snap/bin /xibo-player

in the desktop gnome or mate - command xibo-player is working, but the error in the console is the same

I can give access if necessary before the test installation. for instance ssh and VNC

I’ll clarify. I do not have this problem on installing virtualbocks.
PC only https://ark.intel.com/content/www/ru/ru/ark/products/87740/intel-nuc-kit-nuc5ppyh.html

Just now they brought me another installation for the test, I will check it.
It - HP T620 Flexible Thin Client

Also on your forum there are restrictions on sending messages in 3 pieces, I don’t know if I can answer further here …

Update.
I checked with a new PC, it has an AMD video card - the same thing, all the snap channels behave the same
revision 37 - leak is the slowest
revision --beta and --edge - behave the same

I got time, I did some research.
The results are as follows.

Suppose, when playing the first video file in the list, my RAM is loaded at 1000mb
Then, with each NEW video file, the amount of memory increases by 50-100mb.
Suppose I have 3 video files in my playlist, then the memory consumption is as follows.
1.mp4 > 1000mb >
2.mp4 > 1100mb >
3.mp4 > 1200mb > loop playlist… >
1.mp4 > 1000mb…
It turns out that previously played files remain in the cache, and memory is already being increased again …

Apparently that’s why we saw the problem only when we put the installation in production.
Now we have a playlist of 5-8 hours of video files, lasting 1-3 minutes. Naturally, the player takes all the memory in 30-60 minutes.
Apparently, previous files are not unloaded from memory.

I checked this option on 3 modules.
“Local video”
“Video”
“Embedded”

Video examples are available here.

Thanks for your detailed analysis - i’ve passed this on to the team.

Its really frustrating as most users have reported the opposite (rev37 having a memory leak and the latest not.

Issue:

thank you, I will follow the changes

1 Like

Hello. I would like to report that we are experiencing a similar issue, with xibo-linux 1.8-R4 and Ubuntu 18.04 … 19.04.

Basically our problem is a severe memory leak / open file descriptor leak. When playing a layout with MP4 video files (1920x1080, h264) and WebPage widget content, we are experiencing two things:

  1. Immediately after reboot the player process memory usage increases, to the tune of several megabytes per second. After running for 16 hours one of our test players is reporting 51.5% of 4GB RAM in use (also note the large amount of virtual memory addressed):

**Tasks: 118 total, 2 running, 116 sleeping, 0 stopped, 0 zombie
%Cpu(s): 46.3 us, 1.0 sy, 0.0 ni, 52.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3860.8 total, 229.6 free, 2473.1 used, 1158.1 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 1015.6 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13893 display 20 0 84.5g 2.4g 147704 R 53.2 63.0 21:10.71 player

  1. Related or not, this memory increase occurs in tandem with an apparent file descriptor leak. Ubuntu has a stock ulimit of 1024 open file handles PER USER, so we are getting log errors about various things failing because there are too many open files.

With lsof, I can see the “display” process having this kind of output:


player 17952 display 70u unix 0xffff9152ce361800 0t0 301407 type=STREAM
player 17952 display 71u unix 0xffff9151b53c3000 0t0 300814 type=STREAM
player 17952 display 72u unix 0xffff9151b53c0400 0t0 300815 type=STREAM
player 17952 display 73u unix 0xffff9151b53c1000 0t0 300820 type=STREAM
player 17952 display 74u unix 0xffff9151b53c0000 0t0 300821 type=STREAM
player 17952 display 75u unix 0xffff9151b53c1400 0t0 300838 type=STREAM
player 17952 display 76u unix 0xffff9151b53c2800 0t0 300839 type=STREAM
player 17952 display 77u unix 0xffff9152ce361400 0t0 301135 type=STREAM
player 17952 display 78u unix 0xffff9152ce363800 0t0 301136 type=STREAM
player 17952 display 79u unix 0xffff9152c645f000 0t0 300955 type=STREAM
player 17952 display 80u unix 0xffff9152c645e000 0t0 300956 type=STREAM
player 17952 display 81u unix 0xffff9152ce363c00 0t0 301408 type=STREAM
player 17952 display 82u unix 0xffff9152ce362c00 0t0 301409 type=STREAM
player 17952 display 83u unix 0xffff9152ce360000 0t0 301410 type=STREAM
player 17952 display 84u unix 0xffff9152ce361c00 0t0 301411 type=STREAM
player 17952 display 85u unix 0xffff9152ce360c00 0t0 301412 type=STREAM
player 17952 display 86u unix 0xffff9152ce360800 0t0 301413 type=STREAM
player 17952 display 87u unix 0xffff9152ce363400 0t0 301414 type=STREAM
player 17952 display 88u unix 0xffff9152ce362800 0t0 301415 type=STREAM
player 17952 display 89u unix 0xffff9152ce361000 0t0 301416 type=STREAM
player 17952 display 90u unix 0xffff9152c645d800 0t0 301417 type=STREAM
player 17952 display 91u unix 0xffff9152c645fc00 0t0 301418 type=STREAM
player 17952 display 92u unix 0xffff9151ca22ec00 0t0 301419 type=STREAM
player 17952 display 93u unix 0xffff9151ca22f400 0t0 301420 type=STREAM
player 17952 display 94u unix 0xffff9151ca22dc00 0t0 301421 type=STREAM
player 17952 display 95u unix 0xffff9151ca22cc00 0t0 301422 type=STREAM
player 17952 display 96u unix 0xffff9151ca22d800 0t0 301423 type=STREAM
player 17952 display 97u unix 0xffff9151ca22fc00 0t0 301424 type=STREAM
player 17952 display 98u unix 0xffff9151ca22c400 0t0 301425 type=STREAM
player 17952 display 99u unix 0xffff9151ca22e400 0t0 301426 type=STREAM

These STREAM type file descriptors will keep increasing until there is no memory left, or the kernel refuses to open any more.

Currently I’m in the process of trying the latest beta (46?) in a test environment, but this is a HUGE issue in our current production environment.

Did I understand correctly that the problem is in the WebPag widget?

Can I help you? For example, to provide a test PC with a connection to the VNC ??

Thanks for the reply! I installed R5 (50) on a few production machines it appeared to fix these problems.

Good day. And it is possible to get a deb package from you so that I can check it. Maybe the problem is that the installation is in progress through snap?

Thank you for the offer of help - we would be delighted to have any help you can provide. You can build the code from source, instructions here: https://github.com/xibosignage/xibo-linux#build

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.

The Xibo Community site uses cookies. What are cookies?