@Finntendo

You should read the Docs.
Here you can find many answers to your questions.

I will try to answer your question.

RetroPie is a collection of bash scripts running on top of a lite linux OS.
Lite means it has no Desktop (windows) environment it only has the terminal.
You can even install RetroPie separately on your own compatible debian based linux OS, even if it has a Desktop environment, even if it's not a Raspberry Pi.

Just see a binary as an EXE files from windows, it is also a binary, you download it and it runs.
But to create EXE files you need to compile it first from source so the computer can understand it.
Compiling is converting the programming language into understandable code for the CPU this can take a long time depending on what computer you use.

The RetroPie guys made it easier by supporting binary installs for the Raspberry Pi and perhaps for some other arm boards.
They compiled it for you and many people can use them.

Source installs can be more up to date if the source code is maintained regularly and the binary files are behind but it takes much more time to install.
Though the binaries from RetroPie are updated quite regularly so if it's possible to update from binary than that is in most cases a better choice as it is much faster.

You say you have updated everything now from source.
This means that all installs are very up to date.
So when everything works I would wait some time to update from binary.
Because it could mean that you downgrade the emulators.

The OS underlying files are updated in a quite normal way.
This does not depend on the source / binary installs.
So you won't downgrade your OS.

@mitu said in [solved] Emulators won't start ubuntu 20.04 RPi4b:

@doctordruidphd, how did you compile and install in Ubuntu Server? I am trying the same in Ubuntu Server 22.04 but got lots of compile/install errors. Did you change any defaults in the /boot/firmware/config.txt?

@mitu, do you know if once installed I need gnome or can I run from terminal directly?

Thanks!

Sources are downloaded and unpacked in $HOME/RetroPie-Setup/tmp/build.

@dankcushions Thanks, but I was curious what people are choosing for different packages and why. Like, I update lr-mesen from source, because of X.

@dankcushions I wasn't sure if it'd be worth the hassle of having to reset to head to be able to update again is all. if that's fairly trivial then I'll follow your instructions.

Thanks again for doing this!

Looks like the binary has been created already @mitu. Installed and working like a charm.
Thank you!

Okay, thanks - it could be possible, that I did a setting in RPi setup script by mistake. I played around with that - and maybe did not put it back later. This is a real good advice for my performance issue - thanks

gpu_mem will be fixed, too. Thanks

Edit: Oh holy man! This was the point. I thought it's only a booster for my slow graphics - but it fixed the installation issue! After that modification, I also got the possibility to install RetroArch by binaries (which was not shown before). Now the installation works. Thanks a lot.

Ah, so that was it, thanks! I tried to update it without removing the older version first.

@mitu - thanks for the reply.

To answer your questions:

Are you sure ? Do you have the latest RetroPie-Setup version installed ?

Yep, absolutely. I downloaded the standard image from the site, deployed it, checked and it says 'installed from source'. I then updated the setup script and it stays the same.

Manual installation will not install the package - it's installed explicitely on the Pi images.
But, about the installation from source - are you looking at the same platform (Pi) when comparing the available options ?

Yep, same platform (my Picade), Rpi 3. The buster image I used on this was from back in Jan and was from the weekly builds, so it was an image (not manual). I have two SD cards - one which is 'production' (which has been subsequently updated) originally deployed back in Jan with a buster weekly image - and another SD with a brand new image which I put on there yesterday to test. So am using exactly the same hardware and setup. In theory, the buster image back from Jan should have installed usbromservice as it wasn't a manual install. It also had the source files in the tmp/build folder, but the script was suggesting it wasn't installed. Perhaps I removed it but I don't think so. This isn't an issue though, as we are only really fussed with how the 'current' image behaves.

To replicate the source install thing, all I need to do is deploy a fresh image (current is April 28, 2020, Pi 2/3 variant) and that's it (updating script post install doesn't change anything). You can then see in the package manager that usbromservice appears to be 'installed from source'. You can also click 'update from source' and it'll update. However, as I mentioned above, if you remove it, the install from source option goes away, and you can then only install via pre-compiled binary, which I assume is what it should be displaying in the first place.

Yes, that's an oversight, should be fixed.

Great, no worries!

There are other modules that are binary only, but they're not packaged since there's no point in doing so (i.e. ports that install through .deb files or 3rd party emulatorts which supply binaries). It's normal.

I see. Currently my picade is only running the main/core packages, nothing 3rd party nor any ports. I only mention because none of the other binary packages installed on the system display like this, they all say 'you are running the latest binary'. This one is the only exception in terms of showing the message 'Binary update may be available (Unable to check for this package)'. So I wanted to ask, just in case that was another bug of sorts.

@retropi19 in game there should be resolution settings. May have to set it to windowed mode or something too. I can't remember off the top of my head what the ideal settings are. When I have a chance I can boot up the game and see what settings I was using.

The way RetroPie manages this is by running an additional script after the input configuration phase - see here. The script then reads the es_temporaryinput.cfg file and generates auto-configuration for various emulators - see the script here.
You can probably create a similar utility (in Delphi/Pascal) that parses the es_temporaryinput.cfg file and generates configurations for the emulators you need.

Sorry for the extreme late reply! In reference to my original issues, I got the controller issue fixed (Yay!) but my other problem remains in that I cant get Beavis and Butthead to load from the start. From my last post, I discovered that the game does in fact run properly IF I load a save file from it, however, I get booted back to the main EmulationStation screen if I try to start a game from the beginning. Here are the contents of my runcommand file:

Parameters:
Executing: bash /home/pi/RetroPie/roms/scummvm/+Start\ ScummVM.sh "bbvs-win"
Using joystick: SWITCH CO.,LTD. USB Gamepad
Virtual keyboard pack 'vkeybd_default' loaded successfully
WARNING: No hardware input were defined, using defaults!
User picked target 'bbvs-win' (gameid 'bbvs')...
Looking for a plugin supporting this gameid... MTV's Beavis and Butt-head in Virtual Stupidity
Starting 'Beavis and Butt-head in Virtual Stupidity'
Using joystick: SWITCH CO.,LTD. USB Gamepad
/home/pi/RetroPie/roms/scummvm/+Start ScummVM.sh: line 4: 1506 Aborted /opt/retropie/emulators/scummvm/bin/scummvm --fullscreen --joystick=0 --extrapath="/opt/retropie/emulators/scummvm/extra" $game

When I try and start a new game and get booted back to the main screen, this line of text briefly shows up...

*** Error in `/opt/retropie/emulators/scummvm/bin/scummvm': double free or corruption (out): 0x7ee9b2d0 ***

Any ideas, thoughts or help would be greatly appreciated!

Such option doesn't exist right now, but you can use the auto-update just for the sections which always have binaries - i.e. excluding experimental. The experimental section recently started providing binaries, so that would work for most of them - my guess you have the extra repository enabled and those don't have binaries.
If you open a package from the menu, it will detect if there is a binary update available and you can choose to update or not. Sure, it's just a workaround, but how many experimental packages do you have installed ?

@barbudreadmon
Yeah, it was the principality of it, saving and loading game specific options in a global config. I think I could not get either the macros or cabinet settings to work this way, rendering them beyond completely pointless. I think the actual cabinet settings for the retroarch core are saved in /roms/neogeo/FBA/ along with high score, and I don't know what was up with the macros.

That seems to have worked @mitu , thanks.

However, the script didn't want to update at first, I had to do a "git stash" beforehand as an error was thrown up over lots of updated files

Playing again now though, so happy!

Hi there!

I extract all the roms, configs, images, gamelists, themes, etc... and build a new sd card now with Stretch.

Now, scraper work properly.

You can close the thread. Thank you very much!

PS. BTW, the Debian install links from opensuse.org appear to be broken on the .sh script as there is only a folder for Debian 9.0 now - Debian 8.0 isn't there anymore.