info-beamer

Auto restart of info-beamer with background image

#1

Just a suggestion…
since our setup is quite complex, we load a lot of images and we are very cautious, in order to be on the safe side we were thinking about restarting info-beamer (standalone) periodically so as to avoid memory leakages due to our node.lua and out of memory errors due to poor resource management on our part.
I know it’s not good programming practice but given the situation (imminent exhibition, first public display of our node.lua setup… it has a reason to be. It’s just a safety net.
Moreover the same solution can be used just when loading images gives an error (for example) or other well known and documented situations.

We are of course talking about info-beamer standalone.

The problem is, between shutting down and restarting info beamer there’s a black screen for around 1 second (due to resource loading mostly)… not terrible but we were thinking around it.

We came up with this solution:
0) display the background image menu.png to raspberry framebuffer via fbv menu.png

  1. start info beamer service with the variable export INFOBEAMER_TRANSPARENT=1
  2. on certaing given transitions of the UI, issue a sys command (still to be investigated) that will do service -d /service/info-beamer; service -u /service/info-beamer
  3. the service will go down and up, and while loading the node, it will be transparent and display the menu.png file. If the first image displayed by our node is the same, the trick is done and it’s almost impossible to notice.

We have dona proof of concept and it works.

Still open:
2) issue a sys command from LUA
0) with fbv the image does not go in overscan so it’s kinda shrinked and doesn’t reach the border of our monitor

reference at https://info-beamer.com/doc/info-beamer#hidingthebackground

#2

Just to be clear: info-beamer doesn’t leak memory :slight_smile:

Unless you accidentally keep references to image/video object alive (by putting them in some table for example), the Lua garbage collector will eventually clean up everything and no system memory is leaked ever. Of course avoiding such resource leaks might be tricky and normally you have to manually :dispose() object to have more control over when such resources are actually free’d. Otherwise free’ing might be deferred until the garbage collector decides to dispose them.

(You can see currently loaded object by sending a SIGUSR2 signal to info-beamer. Just run pkill -usr2 info-beamer)

There is a way to force the Lua GC to collect garbage after every frame. This means that if you have code like:

image = nil

the GC will immediately :dispose() that image once the current frame rendering is done (by default the then unreachable image object is still kept around for a bit until the GC kicks in). As this is more CPU intensive, it’s disabled by default. You can enable that with node.set_flag("slow_gc", false) (see https://info-beamer.com/blog/understanding-garbage-collection).

You can’t run system commands from info-beamer. There is no os.execute. The code is sandboxed by design.

If you have little other arm userland stuff running, increasing the gpu_mem to 512 or even more might also be possible to avoid errors in situations when too many images are required to be loaded at once.

#3

Sorry Florian, I’ve corrected my post. Of course info-beamer does not leak. It’s our code that could maintain reference to unused images for a long time because of sloppy/naive programming on our part.

We prefer to handle disposing by hand and not run the CPU intensive garbage collector every frame.

Thanks for pointing out that our LUA code is sandboxed. It’s a nice thing.
As per the gpu_mem what is the upper limit of this memory? Is it a shared memory with the CPU i suppose? We don’t have anything else running a part from the python service daemon that reads user inputs and relays them to the LUA node.

#4

Exactly. If you don’t have a lot otherwise going on. 256MB might well be more than enough. Of course that then also reduces the filesystem cache which might speed up loading images if they have been loaded before, but that’s probably not really noticeable

It’s not too bad actually. You might give it a try and see if the CPU goes up. I suspect you might not really see a difference.

#5

Ok… pretty clear

running top gives me roughly:

KiB Mem :   766744 total,    61052 free,    68180 used,   637512 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   640280 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                            
 4821 root      20   0  254524  29680  15256 S   9.9  3.9   0:36.67 info-beamer                                                                        
 4826 root      20   0   25920  13472   6000 S   1.3  1.8   0:02.04 python                                                                             
 4881 root      20   0    8208   3344   2812 R   1.3  0.4   0:03.37 top                                                                                
 1683 pi        20   0   11660   1740    976 S   1.0  0.2   1:31.62 sshd                                                                               
   59 root       1 -19       0      0      0 S   0.3  0.0   7:18.36 vchiq-slot/0                                                                       
    1 root      20   0    9520   3988   2968 S   0.0  0.5   0:21.75 systemd                                                                            
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.11 kthreadd                             

I’ve never relly understood top. Used + avail memory gives me more than the 1Giga present :slight_smile: Now I have 256 MB allocated to GPU. Do you think moving up to 384 for example could be a problem? … the %MEM percentages are risible. Indeed your engine is perfect!
Right now we have preloaded in cache 6 o 7 full HD or so images…

#6

The output is buff + used + free == total. I guess used is memory that’s not memory mapped from somewhere but actually used. buff is probably mostly file system cache. The more that’s is the better as IO doesn’t have to touch the SD card.

384 MB for GPU won’t make any problems.

#7

Ok… but should’nt a Raspberry Pi3 (+ or not plus) have 1GB of Ram? So total makes sense per se… but not regarding overall memory :slight_smile:
anyway now that we have cleaned up our code I will ramp up GPU mem and test it for the w.e. Thanks!

#8

It has, but that’s split between GPU and ARM memory. That’s what the firmware gpu_mem parameter sets up before Linux even starts. So Linux only sees 1GB - gpu_mem. In theory there was an option to make that split dynamic (keyword is cma), but IIRC that didn’t work too well in the tests I’ve done a few years ago.

#9

Lovely explanation. Thanks.
I’ve also a ram disk to consider, but it’s not very big I think. I’ll leave the gpu ram to 256 or 384 at max. Thanks