@m2306 Mame2003plus started to use analog as default for some reason. Change it back to digital in retroarch.

@mitu Indeed you are right! Thanks, solved now.

its a bug ... after each update, you will need to go to the spashscreen settings and make sure to change them to whatever it was already set to and the problem will be solved.

Wow, turns out I managed to use GCC to compile my own build. I tested SDL 2.0 and while it technically works, it's unusuable, because the only visible part at any given time on the screen is the currently drawn area, so every time there is a sprite or an icon or part of the GUI refreshed, that's the only thing you see, all the rest is black. You can move the mouse to refresh a tiny rectangle all over the place, but really it's unusable. I have then tried with SDL 1.2 (-api sdl) and it actually works flawlessly. The surface is enlarged to fit perfectly fine and centered on my TV, everything works fine, I even played Crystal Crazy and it works beautifully in 256 colors :) Turns out compiling Mini vMac is super easy even for a n00b like me, thanks to instructions on this page from Gryphel which made the process dummy proof, just copy/paste the command line and add your own variation options to it and boom it compiles and it works: https://www.gryphel.com/c/minivmac/build.html Here's my final Macintosh II build command for anybody reading this in the future: ./setup_t -t larm -cpu arm -api sdl -m II -hres 800 -vres 600 -depth 3 -speed 1 -mem 8M -sound 1 > setup.sh Here's my final Macintosh Plus build command for anybody reading this in the future: ./setup_t -t larm -cpu arm -api sdl -m Plus -hres 640 -vres 480 -depth 0 -speed 1 -mem 4M -sound 1 > setup.sh /!\ ** TO RETROPIE ADMINS:** You should REALLY update the Mini vMac binary that comes with Retropie, as the one you ship with Retropie 4.5 is bugged and my mouse cursor is always stuck in the top/left corner, but the one I just compiled myself from current source code on Gryphel website (version 36.04) works flawlessly. If you want I can post a link here to download both my Macintosh Plus and Macintosh II binaries here or PM me. You can now download 36.04 binaries for both Mac II and Mac Plus here: https://www.macintoshrepository.org/25178-mini-vmac-for-raspberry-pi-retropie

@MrStruders If by fresh install you mean using a new image, then no, since the new image will write everything from scratch. Can you run another update, also updating the OS and packages when prompted, of the RetroPie-Setup script ?

After downgrading the kernel to 1.20190401-1, I tried to run RetroPie-Setup which upgraded the kernel to 1.20190517-1. Now the overscan settings still apply to both console and ES. I don't know if this is because of the downgrade-upgrade procedure, or because of the changes I made to /boot/config.txt. Anyway I paste here the relevant settings I have in the file: disable_overscan=1 overscan_left=20 overscan_right=20 overscan_top=11 overscan_bottom=11 overscan_scale=1

Great news, will do ASAP!

@mitu said in Hash sum mismatch error: don't have SSH enabled, then I just enabled SSH, and updated the thread info with read-me-first topic. I have installed the 4.4 image from the RetroPie site, and I have internet connection, I made a ping to www.google.com and work. I now with PuTTy connected to the RetroPie. What should do I do? Where is the path to get the log files? E: Failure to obtain http://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb Hash sum mismatch Hashes of expected file: - SHA256:d69087f3500527bd24f0ee8870a41ac9e45eb34f6b73081a7775fd7ef8825208 - SHA1:9156bdc618af94d53ac6a864ef8d93c0f9af0fa7 [weak] - MD5Sum:76f6caff8c43590c18bf7b4d622adc2f [weak] - Filesize:149042 [weak] Hashes of received file: - SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - SHA1:da39a3ee5e6b4b0d3255bfef95601890afd80709 [weak] - MD5Sum:d41d8cd98f00b204e9800998ecf8427e [weak] - Filesize:0 [weak] Last modification reported: Sat, 27 Apr 2019 16:08:06 +0000 Looking into it, the web http://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb isn't working, I copied that URL in my Google Chrome browser and a error file was downloaded. But https://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb Work's just fine, so look's like sudo apt-get upgrade command isn't working because that http isn't https. EDIT: I have changed the /etc/apt/source.list and added deb http://mirrordirector.raspbian.org/raspbian/ stretch main contrib non-free rpi firmware deb http://archive.raspberrypi.org/debian/ stretch main ui it seems it working now, the upgrade is doing downloading files without error. But, is ok to use those repositories? My guess? Is a problem for South American people (I'm from Argentina), that the source list is unupdated or wrong setted, because when I got the url it use http and not https, looks like that's the main reason. I tried to install the retropie-manager (after the update & upgrade) and I got this error Could not install packages(s): python-dev virtualenv. EDIT 2: I have it working, to workaround I just change /etc/apt/source.list.p/retropie.list (or something like that) and added (can't edit because the Akinet detect that is a spam, but add deb before the url) https://espejito.fder.edu.uy/raspbian/raspbian stretch main After saving the file, I use sudo apt-get clean and sudo apt-get update and everything is working just fine (or it seem's like that). The error is that the URL is unupdated, but isn't the best option. Idk if I have to send an email to the RetroPie developers to update the repo url for Argentina.

@AssPunchMan said in PS3 Shanwan Controller lossed on every update: Its possible fix this? update without loss the PS3Controller pairs. The upgrade that broke the PS3 controllers - the Linux kernel - also broke other Bluetooth controllers and it's not under the project's control. It's a badly timed bug, but that's not something that happens regularly. If you wish to not be bitten by such situations, then only upgrade the packages you need (for bugfixes or new features) and skip the OS and driver upgrades.

@George-Spiggott cool ill try when i get home my kids wanted to play avp and couldnt get to work only paired thank you.

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