@lackyluuk You could see this page for more details, in french only for the moment but if you translate, it could help you to understand this "amazing" feature (with lot of potential evolutions : https://recalbox.gitbook.io/documentation/v/francais/utilisateur-avance/configurations/scripts-sur-evenements-demulationstation

Apparement, on configure différemment dans recalbox la partie "dtoverlay", c'est la manière qui est différente et pas forcement le résultat. Pour tester, c'est juste idée pour investiguer, on peut jouer avec /boot/config.txt, et de rajouter la ligne suivante à la fin du fichier :

dtoverlay=gpio-poweroff,gpiopin=4,active_low=1,input=1

Et ainsi on verra si cela améliore ou pas le comportement du ventilateur.
Bien sur avant de modifier ce fichier, il faudra faire en ssh, la commande suvante:

# mount -o remount,rw /boot

@bozothegeek said in ROM atomiswave:

@barbudreadmon en fait, je soupçonne que cela peut venir d'un prob hardware avec la sd, le hdd ou ssd, il y a des probs connu avec le boiter NESPI 4 Case aussi qui à un usb4/sata perturbale, il faudrait donc savoir quel matériel est utilisé en fait.

oups je voulais dire usb 3

@barbudreadmon en fait, je soupçonne que cela peut venir d'un prob hardware avec la sd, le hdd ou ssd, il y a des probs connu avec le boiter NESPI 4 Case aussi qui à un usb4/sata perturbale, il faudrait donc savoir quel matériel est utilisé en fait.

@Zeke Pareil que pour d'autre... t'as vérifié si t'as pas les partitions en read-only ? sinon, lance la commande "mount", et si tu as "tmpfs on /overlay..."... cela peut être le prob certaines conf peut être sur d'autres partitions et fonctionner mais pas la partie pour la gestion du NesPi 4 case...

@danielr J'ai un bonne nouvelle: pas de prob sur la microSD.... donc je confirme, c'est dur de comprendre pourquoi... pas de doute sur le cabalge pour toi ? désolé j'essai de trouver des idées

@Garden-Dwarf Je suis sur le discord de recalbox aussi si besoin même pseudo !

@danielr pour ton cas, lance la commande "mount" pour voir l'état de tes partitions, si tu as un blem sur la microsd, tu peux avoir le problème, j'ai eu le cas :-(... envoi moi le résultat et je te dirais.

@Garden-Dwarf Désolé, j'arrive après la guerre est ce que tu as essayé avec libretro mame2003plus. Est ce que tu veux un romset en particulier ? t'as essayé avec quel jeu par exemple ? Est ce que le Aimtrack que tu as est vu comme une souris ou autre chose ? désolé je connais pas ce lightgun mais je travail à ce jour sur le sujet donc ton cas m'intéresse !

@dJ0 Donc t'as réussi à modifier le fichier dans /boot sans faire la commande "mount -o remount,rw /boot" ? Normalement, t'as besoin de faire cela pour débloquer ta partition. Mais peut être que ta partition se monte en "rw" automatiquelment à chaque fois pour toi, je sais que cela peut arriver qu'une partition ne se monte pas comme prévu, tu risque d'avoir d'autres problèmes par la suite... pour le savoir, à l'occas, lance la commande "mount" tout simplement, et envoi le résultat, je pourrais vérifier si c'est bien monté comme prévu sur ton Pi4...

Apparement, on configure différemment dans recalbox la partie "dtoverlay", c'est la manière qui est différente et pas forcement le résultat. Pour tester, c'est juste idée pour investiguer, on peut jouer avec /boot/config.txt, et de rajouter la ligne suivante à la fin du fichier :

dtoverlay=gpio-poweroff,gpiopin=4,active_low=1,input=1

Et ainsi on verra si cela améliore ou pas le comportement du ventilateur.
Bien sur avant de modifier ce fichier, il faudra faire en ssh, la commande suvante:

# mount -o remount,rw /boot

Bon j'ai regardé....
la seule différence est le fait que le script de retroflag essai de tuer ES avant en appelant un script.sh supplémentaire :

Dans le .py de retroflag:

os.chdir(scriptDir)
output = int(subprocess.check_output(['./recalbox_SafeShutdown.sh', '--espid']))
if output:
   os.system(scriptDir + "/recalbox_SafeShutdown.sh --shutdown")
else:

Dans le .sh de retroflag:

ES_PID=$(check_esrun)
if [[ "$1" == "--shutdown" && -n $ES_PID ]]; then
   [[ -z $RC_PID ]] || smart_wait 1 $RC_PID && sleep 3
   kill $ES_PID         
   smart_wait 0 $ES_PID
   shutdown -h now
fi

Mais en terme de GPIO, c'est les mêmes utilisant les mêmes commandes De plus, pour ma part, je n'arrive pas à reproduire ce problème même si j'éteins à partir d'un emulateur ou partir du menu ES.... Donc la différence de script, je me l'explique pas encore... peut être un paramètre sur les GPIOs... mis lors de l'installation des scripts... je vais voir....