@psyke83 Thx for the fix, now ps4 pad works.

@mitu Okay, I know that now. It seems like it would tell you something different than ask for user if the repository was missing or deleted.

@granderjoree We don't support 3rd party images - https://retropie.org.uk/forum/topic/3/read-this-first.

Well i'm dumb. Had the controller on directinput instead of xinput. Update had nothing to do with anything. Sorry about that.

user@host$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.3 GB disk0 1: EFI EFI 209.7 MB disk0s1 https://freeaccountsonline.com/ 2: Apple_CoreStorage Mac HD 499.4 GB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3 /dev/disk1 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_HFS Mac HD +499.0 GB disk1 Logical Volume on disk0s2 3BAC0F9E-19F8-4AAB-8752-6514B573B497 Unencrypted /dev/disk2 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *15.9 GB disk2 1: Windows_FAT_16 boot 59.8 MB disk2s1 2: Linux 15.9 GB disk2s2 user@host$

@CapNinja I suggest it can be the timer that leads to such behaviour. After 3s of waiting if the PID is active then a kill term 9 is send to process. That leads to a process abort. You can try to extend the time by changing the sleep command or by changing the number counter. I get some obscure errors if a process was terminated with siglevel 9. No I don't think it has something to do with the script. Sounds like problem with data access from KODI. Suddenly is a kind of magic, too. You wrote you use a pendrive, which can lead to problem 2 - writing cache for KODI. KODI responds sometimes slow on pendrives esp. with ntfs format Unrelated to script. All in all I think you might get some problems with the powering and the pendrive. To be sure I would extent the sleep timer from 0.1 to 0.25 be aware that a not closing process needs now 30x0.25s time ~ 8s to be forced closed now. Maybe you can give feedback to this later ;) @Efriim retropie-setup dialogs can't be closed. As long as the call was initiated by runcommand shell script then every script or binary can be closed. If the runcommand call is missing then there is no pathway for the close switch.

The PR was merged, so it's safe to go back to the master branch if you were testing. Don't forget to updateruncommandafter returning to the master branch (which is done automatically when you use the Update RetroPie-Setup script option of the script itself). Thanks to @mitu and everybody else who helped with troubleshooting & testing.

Following up - I did a reinstall of the Xpad driver (removed and then installed) and it fixed my triggers, too.

This topic has a lot of good info about migrating to 4.4 on a new image.

@hermit That's not how it works. If the ROM in question worked with an older version of the snes9x Libretro core, but the same ROM has an error now, we should report this to the upstream project - so it gets fixed in the future. You already have a topic opened on the Snes9x board - you can report this regression there, mentioning the ROM name (and checksum) and the versions implied - the one working and the non-working one.

@Lumbeechief081 So, if you don't do it already, now that you've learned how quickly you can lose all the work you did is the perfect time to start making backups. 😉

@mitu Thank you! I can't believe I didn't stumble upon those in my search.

@sl89 the repo moved a few years ago so maybe you installed before that.

@rbaker sorry for the very later reply! I didn't even noticed your post until now. Just apologized to Cyde earlier today for being late haha. That makes a lot sense RBaker and thanks for the link to your thread and time. Just i tested the controller on my other Pi and it worked good. Some reason when i uninstalled the PPSSPP and Reicast emulators my problem was solved.

Oh, sorry, no Im not. Didnt realise, sorry

@mitu I used the handy update all packages command which defaults to binary when available. So, I'm assuming that it updated lr-mGBA from binary as usual. The current lr-mGBA version I am using is listed as 0.6.1

thanks :D

@niculinux said in Proper retropie update to achieve version progress: It's s pity it's not automated like in Ubuntu, but that's debian philosopy. Raspbian is not Debian, it's just a derivative. Debian supports rolling upgrades, Raspbian does not.

@mitu Ahh I see, thanks for this mate.