Tested for a bit on a 4GB Pi 4B. More to test, but for now, some results. Removing cma=384 from cmdline and adding gpu_mem=256 to config.txt actually destabilized the system. Re-adding cma=384 and retaining gpu_mem=256 destabilized even faster. This surprised me with a 4GB Pi. Perhaps only the 1st GB is utilized. Had constant game freezes and ES crashes after launching and exiting 3-5 beefy games (MAME 0.209 & flycast). Not catching anything in logs that would shed light on what led to freezing or crashing. Even the screensaver (set for random video) was freezing in between videos without warning. So I commented-out the gpu increase and re-added the cma line... Rebooted. Stable again. In parallel, I increased the ES VRAM Limit to 200Mb (guessed value). This improved the overall ES navigation experience. I'm no longer seeing jumpy emulator system images when scrolling left/right. Change did not yield perceivable negative side effects. Summarizing that Pi4B 4GB seems VERY stable with: No memory split in boot/config.txt No change to default GPU in boot/config.txt Add cma=384M to boot/cmdline.txt ES VRAM increased to 200Mb to support art-intensive theme (system may be even MORE stable with this ES change) Wholly running in HD (4K forced off in boot/config.txt) To force HD, and prevent/ rule-out 4K memory drain, I added these lines: hdmi_group=1 hdmi_mode=16 [hdmi:0] hdmi_max_pixel_freq=200000000 [hdmi:1] hdmi_max_pixel_freq=200000000 Now, I'm on hour 3 of launching/exiting games and letting the video screensaver run in between... Launched Kodi and watched a few videos in HD. Stable. Other than a few expected moments of framerate hiccups during intro sequences (eg. Skies of Arcadia), stable. All of this is anecdotal, of course, so will try to learn more. A few hours of testing isn't enough. But this has been been bugging me for weeks and thrilled I can finally run stable. I'm not technical enough to understand why the cma change (allocating a large contiguous block of memory for GPU) is working, but it seems key here. Next, I'll try to repro the "OP" description issue and try to learn what is making the gpu starve.

it worked! thx guys!

I know this topic is pretty old but I just had this happen to me. It happened because of a conflict in RetroPie auto start. I had manually entered a command line to auto start and then later chose the auto start option in RetroPie setup. Seems the two didn’t work well together. I resolved it by getting back to RetroPie setup in command line and deleted the auto start line. I’m definitely a noob so I apologize if my terminology is wrong. But I’m learning. Hope this helps someone else.

@garradam not safely shutting down can potentially cause corruption of your sd card. If your pi freezes you should remotely access your pi through ssh and safely shutdown that way. Often times it's only emulation station that isnt responding. There are a number of easy to use ssh apps for smartphones that are very convenient to use.

Thank you very much, your suggestion was right. Without the nespi case everything works fine. Thank you so much. Now I have to solve another problem that I don't have in my cabinet. Don't know why the controllers swap themselves after some reboot. I don't touch anything, simply turn off, turn on and magically pad 1 becomes 2 and 2 becomes 1..... howhever, don't wanna go out of post, I'll post it in another one. Thank you again.

@collcroc123 That's normal. Once you start the system, the 2nd partition will be expanded to fill up the free space (that shows up as Unallocated). The 1st partition is the boot partition, only holding the necessary files to start the system and then the actual OS and its files will be on the 2nd partition.

Ok I did that command and I got used 5.4GB(10%) with 51GB available. So I guess I just misread the File Manager. What prompted me to misread the File Manager I suppose would be when I was scraping games and got a disk full or something else(forget what now) error message. However, I SSH'd into the Pi during the Scrape operation and perhaps that caused that error message and made me paranoid.

Thanks so much EctoOne, that was some sharp eyes :D I tried to simplify the structure previously by using variables to populate filenames but this ended up causing issues. Changing back to the file structure and hardcoding the names of each graphic seem to fix that. I thought I was done with messing in them sub-theme files and didn't think to check in there. I was hoping to find that these problems where linked with the memory issues but alas, these problem with random missing images still prevails. Not to worry. Thanks for helping me solve this problem. Github updated Cheers Dal1980

@dal1980 While you're developing your theme, it's good to start ES with the --debug flag and look in the log file to spot any errors coming from the .xml files parsing. The log file is in /home/pi/.emulationstation/es_log.txt.

Check here for more details on N64 emulators: https://retropie.org.uk/docs/Nintendo-64

@devin_205 Do you have an USB stick you can use for the transfer? Then use the USB method described in the link @isrnick gave you. It should be the easiest way if you have problems transferring roms over the network. it says cant upload a psx rom Please describe exactly what you did and give us the exact error message(s).

@kaz69 No, only one OS boots at a time. Nothing additional is running in the background from the other installations. Not sure if PINN asks or allows you to set the partition sizes but obviously it would be handy to have larger partitions for those OSes that need it.

@paulo75 I think we're talking past each other :) The file will not be inside the zip. It will be in ~/RetroPie/megadrive (or Genesis).

@TMNTturtlguy I've replied on the ticket. Exit es if building from source. Swap shouldn't fail if being used heavily. Sounds like sd card problems, but could be os. I don't want to add more swap as it would mean large swap file being created when not needed in many cases (with the current calculated swap size code).

So I am having this same issue, trying to move ROMS from my computer to the ROM folder in Raspberry Pi. I followed the instructions above to expand the file system within raspi-config, rebooted a few times, but it still says I do not have enough room, despite having about 10GB of free space on the card. Any suggestions? Please be explicit as my knowledge of the Pi system is not too great.

I dont know much about diagnostics or what is technically considered "free" I suppose people define it differently. It seems there is no shortage of raspberry pi dashboard projects: Eg: https://github.com/matematik7/rpi-dashboard/blob/master/screenshots/memory.png

@markyh444 Thanks a bunch! I read through it and it does look very tricky. I'm thinking it may just be easier to do a fresh install to be on the safe side. Thanks again!

@doctorstork This is correct. When you put the SD card in the Pi for the first time the root file system is automatically expanded to use the full size of the card. This is free space and can now be used for storage. Go into the terminal / command line and enter df -h this will show you how the card is being utilised.