The issue will be fixed upstream, one way or the other.
As a temporary workaround (until this fix is merged), you can try installing libhidapi-dev manually and then re-run the installation from the RetroPie-Setup script.

With what games do you have this issue ? Can you try with lr-scummvm (experimental packages) to see if the games are working here ? I suggest also to update your system if you haven't done it.

Edit: I just remember something from the day that was using RPi3. Can you change the Graphic mode to OpenGL in the ScummVM gui and try again the games that don't run?

@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.

@roslof thank you so much for providing the binary (once again) and for reporting back re tmnt2! Much much appreciated. I'll keep on testing and reopen the thread should I find anything else.

@mitu said in [Retropie 4 on dietpi binary install // need short help]

So, 90% of the time, it works every time ?

Yes, everytime. :D

You'll have to be more specific - are you talking about the front-end (EmulationStation), emulators in general or certain emulated systems ?

I meant both.

@mitu Ill give that a go. Thank you

i think that i got through. When it ask to update script and update

4f3f5bdf-5c3b-4297-819c-54c559d96c24-image.png

@natesroom So i figured it out, I needed to update the RetroPie Setup Script or whatever that name was in the screen first then run the install option packages.

In the Documentation that should be noted (unless it is and i just missed it)

@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.

Thanks again for doing this!

@sleve_mcdichael actually neverminded, that worked! I did a fresh install of RetroPie on another SD card and added the commit code version number 110020000 to the ppsspp.sh file after master. Then I Installed from source and it installed the right version (v1.10.2). Games that were broken are working again. Really appreciate the help!

EDIT - For others trying to do this, do the following to install PPSSPP v1.10.2:

Make sure the PPSSPP emulator package is not installed (remove it if it is) Open file /home/pi/RetroPie-Setup/scriptmodules/emulators/ppsspp.sh with the editor of your choice Edit the line :
rp_module_repo="git https://github.com/hrydgard/ppsspp.git master"
to be :
rp_module_repo="git https://github.com/hrydgard/ppsspp.git master 110020000" Save your changes to the file Install PPSSPP emulator package from source

@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.

Sorry, i've just noticed entering in each package menu that a few ones can just be downloaded from source and compiled.

Thanks.

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.

Nice, but so where is this advanced speed hacks menu then?

Looking at the menu source at https://github.com/libretro/pcsx_rearmed/blob/40c380a8e8080ecb38159ee5aad1ce149e9889fc/frontend/menu.c , there seem to be a ton of options missing, such as plugin selection, memory card options, advanced speed hacks etc.

It looks like these options were part of a native menu system of the standalone emulator which is disabled/unsupported in Retroarch. I made an issue here: https://github.com/libretro/pcsx_rearmed/issues/176
You can see on this blog how the menu options in the original emulator looked. They appeared on a press of ESC.
https://retroresolution.com/2016/01/01/playstation-emulation-on-the-pi-enhancing-the-experience-with-the-options-menu-part-one-basic-features-and-save-states/

Since the native menu system is based on a menu rendering library not available in Retroarch (libpicofe), the solution is to map all the missing options into the Retroarch Quickmenu. Currently, only some of the options are mapped to the Quickmenu.

@quicksilver Yeah, I did the same. Took those that were already converted, the rest I went for bin/cue formats. Converting myself never went right.

Thanks for the guide! I'll give it a try later. So far I'm only interested in PCE-CD and Sega CD games.

Ok, so I've created separate emulator.cfg for each version of CSBwin I'm using and that works fine.

But now I have troubles with Der Clou again. After a reboot I can't start it from ES anymore, I get:

Executing: /opt/retropie/ports/theclue/theclue ERROR: Module Dsk: Open :./pictures/bubble.fnt

And it seems to be a path issues, because I get the same error when I try to run the binary from the menu in Raspbian.
I can run it when I go to the directory manually at the command promt. So my guess is that the script not goes into the directory and thats why it can't find the datafiles anymore. Weird thing is, that I can run it from ES after I started it once from the command promt.

Also i just noticed that I can't save because of restrictions. D:

Also noticed that I don't have to add lots of games. Simply adding more and more systems to retropie will also chew up ES's RAM until it can't launch anything.

I might try playing around with the memory split to see if this helps at all, and allocating more VRAM to emulation station... but it may not work. Currently I have the memory split at 128.