Memory leak with video previews?

[jell]

Re: Video Preview in EmulationStation

I've just set up video previews and all seems to be running well. However, I noticed much less free memory available when using this feature. To test, I've run 'top' and watched the memory. The free memory decreased with each video I watched, bottoming out around 80kb. Even when leaving the pi idle overnight, the memory did not free up. It only freed up when rebooting the pi. Emulator performance does not seem to be affected. Has anyone else noticed this?

I have a RPi3, running everything updated to latest binary.

Thanks!

[pjft]

@jell hi and welcome! Thanks for reporting this. I read your post in the other thread.

That is certainly a possibility, and one I cannot disprove for sure. While I have tested it quite a bit on my own with top and running for days, and several have been using this extensively since earlier in the year, that's hardly scientific evidence so I'm always keen on learning more and exploring.

Can you give me a few more details, namely:

• video player
• screensaver type
• videos you're using (resolution)
• anything else that may be relevant
• a final snapshot of top when memory has bottomed out (or, I suppose alternatively, a snapshot of memory sufficiently spread apart to show the memory decrease)

One thing to know, which you may or may not be aware of (I certainly wasn't until I dug into this) is that "top" is not the most effective way to troubleshoot memory leaks. You should use "free -m" for that.

This answer might help:

https://serverfault.com/questions/377617/how-to-interpret-output-from-linux-top-command

As well as

http://www.linuxnix.com/find-ram-size-in-linuxunix/

And

http://www.linuxatemyram.com/

So if you can effectively run "free -m" at the beginning and then after a prolonged session and check the actual free memory difference, that'd be ideal for this process, as it may be just normal OS behavior.

But let me know :) I'm always keen on having more people taking a better look at how things work!

Thank you for the interest and time here.

[jell]

@pjft Thanks for the reply and helpful links! I've learned a lot. Indeed, more memory is free than appears based on use of 'top'. My use of free -m returns the following:

pi@retropie:~ $ free -m
total used free shared buffers cached
Mem: 747 703 44 5 43 471
-/+ buffers/cache: 188 559
Swap: 99 0 99

Which, if I'm understanding correctly, really means that 559 is free, as opposed to 44. This explains why performance didn't seem to be affected at all.

Thanks again, and pardon my ignorance :) Now back to optimizing input lag lol!

[akafox]

As for the input lag..is your TV in "game" mode? check to see. Unless you are using wireless controllers (which might be a cause) this is the main problem. New TVs these days do A LOT more then just display a picture..so in by making the TV work hard to display a picture now it has to put up with your "fidgeting" and can not keep up..thus input lag.

Game mode turns off all the extra processing features and allows it to just display an image so it can keep up with your controller inputs.

[jell]

@akafox
Thanks for the tip. Yeah, beyond the Game Mode step. Now tinkering with dispmanx drivers, threaded video, audio sync, swapchain images, etc. It's a process though. Some games work well with some settings, others have flickering screens/stuttering gameplay with the same settings. It's fun tinkering though, and exploring "new" old games :)

[pjft]

@jell not a bother, we're all learning here:)

If you're using Bluetooth controllers, there's a very nice recent post on that that may help.

https://retropie.org.uk/forum/topic/7712

[jell]

@pjft Thanks! I am using 8bitdo FC30s, and in all my searching, somehow never came across that thread. Will look into it! My benchmark was being able to play Mike Tyson's Punchout, although in reality I could never beat that game even when I was a kid :)