@mitu This worked! I was surprised, because after formatting the flash drive it looked like the drive had a single partition taking up the whole volume. I wasn't able to create partitions on Windows 10, so I used the Disk Utility on macOS to create two exFAT partitions (screenshots of the volume in Disk Management before and after below). After that I was able to follow the instructions to create the proper directories and transfer the ROMs!

Thanks!

Screenshot 2023-12-14 212355.png

Screenshot 2023-12-14 212425.png

Screenshot 2023-12-14 214455.png

@mitu I made another test replacing the SSD ( Kingston SSD KC3000, 2048 GB, M.2 2280, NVMe PCIe Gen 4.0, Read: 7000MB/s, Write: 7000MB/s, SKC3000D/2048G) for a SSD "Adata Legend 740 NVMe, 250GB, PCI Express 3.0, M.2"

ALEG-740-250GCS-6.jpg

And this SSD disk works!! (now I can see several folders inside "retropie-mount" folder, "BIOS", "roms", etc)... but is a very tiny SSD compared with the Kingston one, maybe it worked because this is a PCIE 3.0 and the Kingston is PCIE4.0? maybe raspberry pi 4 doesn't support PCIe 4.0 because that technology needs more power? I used the same enclosure for both SSDs (ORICO M.2 NVMe SSD Enclosure to USB-C PCIe Adapter 10Gbps USB 3.2 Gen2 for NVMe M-Key/M+B Key SSD 2230/2242/2260/2280)

@mitu It seems to work fine now, but if it starts to mess up again I'll let you know, thank you.

@mitu
Pi Model or other hardware: Raspberry Pi 4
Power Supply used: Canakit bundle power supply
RetroPie Version Used (eg 3.6, 3.8.1, 4.1 - do not write latest): 4.7(?)
Built From: raspberry Pi imager on 32GB SD card
USB Devices connected: 128GB USB and USB keyboard
Controller used: n/a
Error messages received: n/a
Verbose log (if relevant): ???
Guide used: ETA Prime's video
File: /home/pi/RetroPie (im guessing)
Emulator: n/a
Attachment of config files: not available to me atm
How to replicate the problem: not sure

Ive followed the steps of automatic mount, but still not working, ill try manual mount soon, and if it works ill let you know.

@Folly said in Moving art/video-snaps/gamelists/and-other-settings to USB Drive ALONG with ROMs?:

you also have to copy the media and change the locations in the gamelist.xml otherwise your media isn't found.
You can simply do that with find and replace in a text editor.

Thank you for that information, but TBH the entire point of me making this post is basically to NOT have to manually edit .XML files (and like 30+ of them for all the systems I run). Just trying to see how in RetroPie you can turn on the feature to have the gamelist.xml's and the media folder w/ artwork switched over to the individual rom folders. Skyscraper seems to do this, but that process can take days or WEEKS even (when it's acting up and timing out 99.99% of the time) – so it is possible, just don't know how...

@cdaters said in Moving art/video-snaps/gamelists/and-other-settings to USB Drive ALONG with ROMs?:

What you are proposing is very cool, you are looking for a portable RetroPie set-up much in the same vein as a Portable Apps USB flashdrive. I don't know if this is realistic in the sense that your emulators on each Pi that you run that USB drive on would have to be configured the same way. This includes your controller configs, etc.

Right now I'll be happy if I can get my first step figured out: how to get my games + scraped art onto the USB drive, and have a fresh system read from the USB for those two things (nobody yet has been able to tell me a good way to point RetroPie to the USB drive for those things...).

My premise to do this is simple: scraping is STILL a nightmare, ~SIX years later (since my 1st build). Granted these last two spats have been the best ever, but with a six year history of it timing out forever (even with extra threads on Screenscraper.fr), and taking me literally, no joke, days to even WEEKS to scrape my 30+ systems properly, I have very high doubts it'll continue to be good.

So, when I can get an entire Pi setup, ALL my customizations, all roms working, everything – in a couple hours, minus artwork... but then it can STILL take anywhere from like 6-12ish hours (best case scenario), to DAYS to WEEKS to scrape the art for 30+ systems. This is why I want a USB drive with all games, then in each individual rom directory have the gamelist.xml + 'media' folder with all the art/videos so I never, ever, have to deal with a scraping nightmare ever again.

...I'll deal with the settings later (which BTW, the gamelists have NOTHING to do with any of my other tweaks - they literally just say the game name + where to find the art/videos-snaps... so they work on ANY emulator on ANY model of Pi!).

Booted up on sd-card only and found a huge pile of cache files from skyscraper. Purged it and that fixed the issue.

@stumcbill
The only two things I can think of are

Drive is full File permissions issue

#1 is easy enough to check, #2 shouldn't be an issue as long as your USB drive is using the FAT32 file system.

When you say you manually save, if you mean through the game's normal save feature, you could try using a save state as an alternative. If a save state worked then it likely would mean that none of the above applies and it is something else.

Did you also enable the service after installing it ?

You need to copy the /home/pi/RetroPie/retropiemenu folder.

Cool, then I can go back to fiddling around a bit more :)

@SgtJimmyRustles said in Usbromservice changed all the rom folders to root permissions:

Errors when I try a sudo chown -R pi:pi /home/pi

chown: changing ownership of '/home/pi/RetroPie': Operation not permitted

Just a little explanation for this: FAT32 (vfat in Linux) is a Windows file system that doesn't support Linux file permissions and ownerships. Those are determined by the mount options (here: uid=1000,gid=1000,fmask=0022,dmask=0022) and are immutable by commands like chmod or chown. Thus, the above error message ist normal behaviour for a vfat mount.

@freddyja script.zip is not avalaible, I can't use this guide.

@mitu Just did final test. It all worked out perfectly. Cache has been moved to the external drive using the path to retropie-mount. The only thing that was weird was after nano-ing into the config.ini, I got the same error message, even after the MicroSD was cleared of the cache. It was just a black screen with the error message at the bottom. However, after hitting ctrl + r to give a command to read a file, I just typed in config.ini into the prompt, and then the file decided to open and let me edit it. Aside from small bump, everything worked out perfectly.

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

@IceChes1 said in USB ROM Service isn't working:

If you don't want to help me you don't have to.

You've been helped more than once on this forum and I personally answered to some of your topics - there's no reason to take it personally, it's not. Diagnosing 3rd party badly/mis-configured image is not something we do here and there's good reasons to do so.

The Pi is a learning and educational device - if you don't want to put up the time and effort to learn some of its intricacies that's up to you, but don't expect everything to be plug-and-play. Given the popularity of the device, there's tons of information and documentation on how to configure/create things with the Pi and you can take advantage of that.

@windg usbmount is included in the image, but not in the manual installation. if you install via a manual installation, as it appears you have done, you will have to manually install it after the fact via the packages menu.

Ok so I'm ra I forgot to mention it was a nespi+ case. And I opened it up to see if it was a problem with the case and come to find the usb connector not plugged in. Must have came undone while removing the m.2 board I had in it. I guess the usb ports still gets power from another source too thus why the light came on. All is working now. It works like it should. Disregard my issue as user error.

It is Pi 3 b+ and RetroPie 4.5.3 (according to RetroPie Setup Script).