Picade installation on Pi3 using weekly Buster image - testing

movisman

Hi,

I decided to reinstall my old Picade instance which has an original Pi 3 sat in it (the install was a bit out of date as i've not used it for a while, but it is fully functional). Anyway, I decided as I had a second SD card knocking about, I could try the weekly buster image to see how it goes without messing with the contents of the original SD card. Basically, I didn't want to update using a Stretch image only to have to update again when Retropie is updated with Buster - so figured i'd have a play around.

Initial impressions are excellent, everything is up and running with no major issues. I have been able to replicate my previous setup and haven't come across anything broken yet. Likely i'll use this ongoing and just update, unless there is a specific reason to reinstall after it is officially released.

To clarify, the image I installed was retropie-buster-4.5.8-rpi2_rpi3.img.gz dated 05/01/20.

I wanted to ask, while I have this Picade on a weekly build that uses Buster, is there anything you would specifically like me to test out?

I noticed a couple of really minor QOL things, which i'll list below. Not necessarily Buster related though. They are all very, very low priority and one is RA anyway so probably cannot do much about that.

General typo
Retropie setup script under configuration / tools > autostart:
"Manually edit /opt/retropie/configs/autostart.sh" should be "Manually edit /opt/retropie/configs/all/autostart.sh"

Redundant packages
After a full install of the weekly image, followed by a full update including the underlying OS packages, the following packages remained on the system but are unused:

libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1

A quick 'sudo apt autoremove' gets rid of them with no ill-effects. Maybe these packages can be removed for future builds, if this is even applicable? Thought i'd mention it anyway.

Retroarch flashes up a brief warning when launching on its own
When launching Retroarch on its own (via RetroPie options > Retroarch) "No sg devices found and sg kernel module is not loaded after update" flashes up on launch momentarily. Might be a build thing or fixed in a later release. Doesn't seem to have any negative effects on usage though. I don't notice this on my desktop build.

Thanks a lot

mitu

Thanks for the testing and the round-up.

typo - we'll git it fixed eventually.
redundant packages - I think a recent vlc update made those packages redundant, maybe a new version of the image wouldn't pull those dependencies again if the image is generated.
the warning No sg devices found and sg kernel module is not loaded after update doesn't have any impact. It's because of the support for reading real CD units in RetroArch that was added in - see https://www.libretro.com/index.php/retroarch-disc-project-run-real-games-off-cd-rom-with-retroarch-starting-with-sega-cd-and-playstation1-coming-very-soon/.
On the PC, if you have a real CD unit then it probably detects it and that's why you don't get the warning, or the codepath is totally different (the message is very linux specific).

movisman

@mitu

Hey there,

Cheers for replying. Indeed, all of those things I spotted are so minor, but I figured it was worth tracking anything strange as I go and letting you know.

Regarding the redundant packages, I wonder if this VLC update is what also broke a few of my video previews (you get sound but no video). They work on the desktop fine, but not on the Pi. I searched the forum and found a very helpful post by yourself suggesting that "Progetto Snaps recorded with MAME" previews use an unsupported colour space and need to be converted. So I fixed that using ffmpeg. But I think a VLC update broke support support for yuv444p, as the videos were ok on my old build which used the built in player. I wasn't using OMX player on that.

Regarding the warning on launching Retroarch, that makes sense so thanks for clarifying. On my PC, I don't have a CD drive but do not get the same error. However I do get this when launching Retroarch on its own:

error: XDG_RUNTIME_DIR not set in the environment
[CDROM] Could not open /dev/sg0, please check permissions.

I guess the second line means the same thing as the 'sg devices' error pretty much?

I know this is slightly off-topic, but wanted to ask if poss, do you know what the first line is about and how I can get rid of it? This never used to appear on my Ubuntu 18.04 instance, and i'm not entirely sure when this started. Reading up on what XDG_RUNTIME_DIR is, it seems to be an environment variable for the user, but it is not preserved by sudo. Looking at retropiemenu.sh (line 140), with my (very) limited knowledge, it looks like it is calling retroarch as the pi user anyway, but with root access? Perhaps this is the cause? Or perhaps I simply don't understand it. The XDG_RUNTIME_DIR for the 'pi' user exists and is set to the default 'run/user/1000'. Seems to be set the same as the Pi instance but it doesn't happen there.

I will keep digging as it's good to learn but do you have any ideas or insight on why this would appear?

Also, let me know if there is anything specific to test on this Buster installation, otherwise I will just report as and when I find anything. I know it is not as useful as if I had a Pi 4, but for now the Pi 3 is doing a good job so no need to swap it out. So far everything is working though so that's great.

Thanks

movisman

https://askubuntu.com/questions/872792/what-is-xdg-runtime-dir

May provide a solution to what i'm seeing with Retroarch on the Ubuntu machine, will try later when I get home. It doesn't affect the usage, probably a waste of time trying to silence them as they only pop up for a sec. But curiousity got the better of me.

mitu

Regarding the redundant packages, I wonder if this VLC update is what also broke a few of my video previews (you get sound but no video). They work on the desktop fine, but not on the Pi. I searched the forum and found a very helpful post by yourself suggesting that "Progetto Snaps recorded with MAME" previews use an unsupported colour space and need to be converted. So I fixed that using ffmpeg. But I think a VLC update broke support support for yuv444p, as the videos were ok on my old build which used the built in player. I wasn't using OMX player on that.

Is that on the new Buster image that you tested ?

Regarding the warning on launching Retroarch, that makes sense so thanks for clarifying. On my PC, I don't have a CD drive but do not get the same error. However I do get this when launching Retroarch on its own:
error: XDG_RUNTIME_DIR not set in the environment

I don't know why that error occurs, I don't think RetroArch uses directly this env var - may be a Wayland/screensaver warning.

movisman

@mitu

Is that on the new Buster image that you tested ?

Yep it is, it was the image dated 05/01/20, so quite recent. It uses standard player by default, and I noticed when I brought my scrapes across from the desktop that some of the FBA/MAME videos were not playing correctly, but they were fine on Ubuntu. So I turned on OMX player not knowing at the time what was occurring, and it was the same. So I searched the forum and found lots of posts about it and your helpful solution. Re-encoding worked straight away. Means if I ever rescrape my arcade roms i'll have to be aware and restore the converted videos, unless this is fixed somehow.

But yep, it was on the Buster image.

I don't know why that error occurs, I don't think RetroArch uses directly this env var - may be a Wayland/screensaver warning.

Hmm no probs, thanks for the input. I wonder how this started occurring, the only changes i've made to the install are generic OS updates and keeping Retropie and it's packages up to date, but I suppose that is as good a reason as any for this stuff to start happening I suppose. It's only a pop up message and nothing appears broken.

I will keep digging when I have a sec, see what I can find.

Thanks!

movisman

@mitu

I don't know why that error occurs, I don't think RetroArch uses directly this env var - may be a Wayland/screensaver warning.

So I fixed that error regarding XDG_RUNTIME_DIR, maybe RetroArch does use it after all. I was mistaken when I said it flashed up when launching, it actually flashes up when exiting! Same for the CD-ROM warning.

To solve it, I did the following:

run:

sudo sudo -V

scrolled up a bit to see which environment variables are preserved. XDG_RUNTIME_DIR is not one of them.

I then had to edit the sudoers file (sudo visudo) and add the following in:

Defaults        env_keep += "XDG_RUNTIME_DIR"

Save and exit, you can then run 'sudo sudo -V' again and you'll see XDG_RUNTIME_DIR is in the list of environment variables to preserve. Reboot the system and the error should go away when quitting Retroarch.

For whatever reason, sudo does not preserve this environment variable, and i'm guessing because Retroarch launches from the Retropie menu with root privileges, it cannot see or have access to this environment variable. Adding the above in preserves it, suppressing the error (after a reboot).

The CD error still pops up though, but not much that can be done about that at this time it seems.

FYI, this error only pops up when you quit Retroarch after launching it on its own from the Retropie menu - it doesn't come up when quitting out of a game. I guess this is because games are launched as the 'pi' user, rather than with root privileges.

My question would be, is there a reason Retroarch needs to be launched with root privileges from the Retropie menu? Maybe I am misunderstanding how it launches, but that is what it looks like to me.

Cheers!