Retropie - Tutorial - Teil 7 - Fehlerbehebung



Montag 26 August 2019 von Trixter C64, Emulation, Tutorial RaspberryPi keine Kommentare

Willkommen! Nach längerer Zeit erfolgt heute mal wieder ein neues Tutorial zu RetroPie auf dem RaspberryPi. Heute geht es um Fehlerbehebungen:

- PS3 Bluetooth Controller Kontaktverlust, automatische Abschaltung

- Autosave PSX-Memorykarte

...und einige Dinge mehr!

Seit ich euch das letzte Mal in Ausgabe 101 (2017) der Digital Talk zurückließ, hatte ich nur sehr sporadisch an meinem Pi-Projekt gearbeitet (ja, die knappe Zeit) und mich mehr dem Aufbau der Inhalte (Screenshots und Informationstexten) gewidmet als ich zum eigentlichen Spielen kam. Diesen Umstand habe ich nach der Digital Talk 105 nun umgestellt, habe meinen 1er Pi aus dem Wohnzimmer genommen und ihn durch den 3er Pi ersetzt - ich wollte einfach mal die kurze freie Zeit zwischen den DT-Ausgaben mit dem Zocken beginnen, da ich darauf richtig Lust hatte. Und was meint ihr - ist es mir gelungen? Natürlich nicht und davon soll dieses Tutorial handeln, in dem ich auf alle gefundenen Fehler näher eingehe und diese auch abstelle.

Ich habe mich für die Playstation entschieden, legte dort Metal Gear Solid ein und kam bis zur ersten längeren Zwischensequenz (es hätte auch keine Rolle gespielt, wenn man mal flott zum Lokus gegangen wäre - nach ca. 10 Minuten hätte man das selbe Ergebnis bemerken können: der Playstation 3 Controller verliert seine Verbindung über Bluetooth! Wenn es sich dabei um einen originalen von Sony handelt, sogar unbemerkt, da die LED dort weiterleuchtet, als sei man verbunden. Nur wer aufmerksam im Emulator den Screen beobachtet, wird dort nach einiger Zeit eine gelbe Schrift bemerken, die von der Trennung verkündet.

Eigentlich sollte so eine Trennung kein Problem sein - dann verbindet man sich eben wieder neu, richtig? Nun, hier war das ein wenig anders - ein originaler Controller ließ sich für eine Neuverbindung erst gar nicht mehr über die PS-Taste ausschalten und Klone, die scheinbar ausgeschaltet waren, fanden bei dem Kontaktversuch eben keinen Kontakt mehr. Mehr noch - der Pi war "halbseitig" eingefroren. Er reagiert zwar noch auf Eingaben, läßt sich aber nicht mehr Herunterfahren oder Neustarten. Geht man in diesem Zustand in die Bash, wird man feststellen, daß der obere rote Infobereich, der sonst immer kommt, verschwunden ist - es erscheint nur die Zeile für die Kommandoeingabe. Sehr ungewöhnlich. Natürlich kommt man aus diesem Zustand nicht mehr heraus, sodaß Steckerziehen auf dem Plan steht - verbunden mit dem Risiko, sich seine Karte zu schrotten.

Bevor ich mich tiefer auf die Fehlersuche machte, testete ich alle mir zur Verfügung stehenden Controller durch - ich wollte ja Zocken und nicht Fehler suchen. Dabei kann ich euch an dieser Stelle schon mal eine grobe Übersicht von Controllern und deren Verhalten geben:

- PS3 Controller Sony - trennt sich mit leuchtender LED über Bluetooth, keine Reaktivierung möglich, System friert ein. Bei Verwendung über USB-Kabel fehlt die Rumblefunktion

- PS3 Controller (Klon Shanwan) - trennt sich über Bluetooth (LED aus), keine Reaktivierung möglich, System friert ein. Bei Verwendung über USB-Kabel rumbelt das Teil ohne Unterlass

- PS2 Controller über Adapter (Kabel) - kein Rumble

Da mir aber Rumble essentiell wichtig ist (bei Spielen, die dies unterstützen) ist diese Funktion scheinbar out of the box nur über PS3-Controller via Bluetooth möglich. Man könnte dem PS2 Adapter diese wohl nachträglich hinzufügen, indem man den Treiber mit aktivierter Funktion neu kompiliert - aber hey, das ist mir viel zu aufwendig, das muss direkt laufen. Man stelle sich nur vor, es gibt später mal ein Update für den Adapter - dann darf man das Spiel ständig wiederholen - nicht mein Ding!

Wie es sich mit XBOX-Controllern (Funk/USB) verhält, kann ich nicht sagen, da ich keinen besitze - evtl. kann Birdy1 da näheres zu sagen. Ich war zwar kurz davor, mir genau so einen zu kaufen - samt USB-Bluetooth-Dongle, da das interne Bluetooth des Pi3 dazu wohl nicht kompatibel ist, aber auf der Suche nach einem passenden USB-Dongle, stieß ich dann auf Hilfesuchende, die exakt das selbe Verhalten mit ihrem externen Dongle berichteten. Ab dem Punkt war mir klar - es ist kein Hardware, sondern ein Softwareproblem - und ich mußte mich wohl doch wieder tiefer mit der Materie befassen um dem Treiben auf die Spur zu kommen.

Daher updatete ich erst mal den Bluetooth-Treiber - schrittweise bis zur aktuellsten Version. Ihr wißt ja, bei mir lief nur die 0.1.0er Version richtig, dh. nur mit dieser war eine Verbindung zwischen Controller und Pi möglich. Ich war erstaunt, daß dieser Umstand trotz etlicher neuer Versionen immer noch gilt - mit keiner der neueren Versionen war ein Pairen möglich. Daher kann ich euch an dieser Stelle sagen - wer Probleme mit dem Pairen von PS3-Controllern hat, der sollte auf die alte Version 0.1.0 umsteigen und es erneut versuchen. Infos hierzu findet ihr in einem meiner älteren Tutorials oder meinem Video auf meinem YouTube-Kanal. Hieran konnte es also nicht liegen - der selbe Treiber wie zuvor wird auch jetzt wieder, bzw. weiter verwendet.

Google spuckte leider auch nichts brauchbares aus - es waren immer nur Threads von Leuten, die die Zeit der Trennung selber bestimmen wollten. Dh. der PS3-Controller hat von Sony eine Vorgabe erhalten, ab welcher Zeit er sich bei Inaktivität trennen soll. Dies ist laut Vorgabe 10 Minuten. An dieser Zeit kann man rein gar nichts ändern und würde man es können, würde der Controller dies eigenständig wieder abändern, sobald er sich mit einer Playstation 3 verbindet. Das ist schon mal gut zu wissen, da die Abschaltzeit am Pi tatsächlich bei 10 Minuten Inaktivität liegt.

Als ich später eine Ursache ermittelt habe, fand ich sogar einen offiziellen Thread auf den RetroPie-Seiten, die von dem Problem des Kontaktverlustes berichteten und auch eine Lösung in Petto hatten, aber dazu später mehr.

Es ist wohl so. Der Pi fragt beim Start einmalig alle Bluetoothgerätschaften ab, welche in der Regel Mäuse und Tastaturen sind. Diese trennen sich normalerweise nicht. Dh. der Pi scannt nicht nach neuen Geräten und bekommt die automatische Trennung der PS3-Controller gar nicht erst mit - für ihn ist das Gerät nach wie vor verbunden. Fährt man den Pi nun runter, versucht er die schon getrennten Geräte zu trennen und fragt alle Geräte ab, für die er Infos im System vorfindet - Bluetooth Mäuse, Tastaturen, sogar Modems. Allerdings gelingt ihm das nicht und er hängt sich in einer Endlosschleife fest. Das erklärt den "teilweise eingefroren sein"-Zustand.

Diese Funktion des Aktivbleibens und Scannen der Geräte - die standardmäßig wohl nicht aktiv ist - kann man selber durch Befehle beeinflussen und scharf schalten. Aber darauf muss man erst mal kommen. Und jetzt trennen sich meine ermittelten Werte und Befehle von den offiziellen, die auf der RetroPie-Seite zu finden sind. Interessanterweise rate ich dazu, BEIDE Methoden gleichzeitig aktiv zu schalten. Warum? Weil beim Start von RetroPie ein Script durchlaufen wird. Was dieses genau bewirkt, weiß ich nicht, aber es hat verschiedene Enden. Dh. wenn dieser oder jener Zustand vorliegt - dann mach dies oder das. Wie ich feststellen mußte, kann es sein, daß ein "anderes" Ende durchlaufen wird - eines, wo der Befehl gar nicht erst vorkommt und berücksichtigt wird. Das endet dann darin, daß "es" mal funktioniert und manchmal eben nicht - auch das mußte ich schmerzlichst feststellen. Ich dachte, das Problem sei Geschichte - aber am nächsten Tag war es wieder da. Super! Beendet also Emulationstation und geht in die Bash. Dort gebt ihr folgendes ein:

sudo nano /etc/rc.local

In dieser Datei sollte sich neben dem ausgeklammerten Infotext ein "exit 0" Befehl am Ende befinden. Genau vor dem "exit 0" gehören folgende Zeilen eingetragen:

sudo hciconfig hci0 up

sudo hciconfig hci0 pscan

Die erste Zeile stellt sicher, daß Bluetooth nach dem Systemstart aktiviert ist (ist eigentlich doppelt gemoppelt, da es das ja schon ist, aber schaden kann es ja nicht) und in Zeile 2 wird das regelmäßige Scannen nach neuen Bluetoothgeräten aktiviert. Diese rc.local-Datei wird - wie wir gleich noch sehen - beim Systemstart eingebunden, wenn irgendwelche Bedingungen erfüllt sind. Da ich diese nicht kenne (abhängig von einem Script) mußte ich zudem noch den offiziellen Fix von der Retropie-Webseite eintragen. Ebenfalls in der Bash tippen wir ein:

sudo nano /etc/init.d/rc.local

Dies ist besagte Scriptdatei und ihr werdet feststellen, daß sich dort eine Menge von Code befindet. Ua. auch verschiedene "Exits". Unser Exit von weiter oben steht meine ich ziemlich am Anfang mit "exit 3". Sucht in dieser Datei ebenfalls "exit 0" - diese Stelle wird mitten im Code sein. Macht davor eine Leerzeile und tragt folgendes ein:

sudo hciconfig hci0 up piscan

Im Grunde ist dies nichts anderes als in der anderen Datei - nur eben nicht als 2 Zeilen, sondern in einer zusammengefaßt. Wundert euch nicht über "pscan" und "piscan" - diese sind wohl beide gültig. Der eine stammt von Raspbian, der andere von Debian/Ubuntu.

Nach dem Speichern das System neu starten. Nun werden wir feststellen: in der GUI von Emulationstation oder der Bash, wird sich der Controller bei seiner automatischen Abschaltung (oder beim Drücken der PS-Taste am Controller) richtig abschalten. Dh. der Controller vibriert einmal kurz, dann laufen alle LED´s einmal durch und er ist Aus. Auch das Reaktivieren klappt problemlos. Anhand meiner Beschreibung habt ihr es sicher schon bemerkt - dieses Verhalten macht er nur außerhalb der Emulation - innerhalb eines Emulators, oder sagen wir besser - unter RetroArch, welches zwischen Emulationstation und Emu steckt, verhält es sich immer noch so wie am Anfang. Das Problem ist eindeutig bei RetroArch zu suchen - da mir der Fehler aber noch nicht aufgefallen ist, müssen wir anders vorgehen. Die Lösung ist - der Controller darf sich nicht von selber trennen! Er muss laufen bis der Akku leer ist. Sollte man dennoch mal den Controller ausschalten wollen um Strom zu sparen, kann man jederzeit (am besten vorher das Spiel speichern oder ein Savestate anlegen) in die GUI zurückkehren und ihn dort mit der PS-Taste abschalten. Später aktiviert man ihn wieder, startet das Spiel, lädt den Speicherstand oder den Savestate und zockt weiter. Natürlich kann man auch einfach für die Zeit der Pause in der Emulation das USB-Kabel einstecken (anderes Ende in den Pi, bzw. Hub) - der Controller bleibt dann zwar eingeschaltet, verliert aber keinen Strom - er wird sogar geladen (allerdings erhält man keine Rückmeldung über den Ladestand). Eine tausendmal bessere Lösung als der Murks vorher.

Um den Stromsparmodus des PS3 Controller zu deaktivieren - dh. in dem Fall, die internen Sonyvorgaben außer Kraft zu setzen - geht in die Bash und gebt dort ein:

sudo nano /var/lib/sixad/profiles/default

Sucht in der Datei nach der Stelle:

enable_timeout 1

Ändert die "1" in eine "0".

Möchte man (warum auch immer), an der automatischen Ausschaltzeit etwas ändern, kann man folgenden Code unter die Zeile kopieren:

timeout_mins XX

(XX steht hierbei für die Minuten, also trägt man hier eine 20 ein, geht das Ding nach 20 Minuten aus)

Diese "globale" Deaktivierung gilt für alle Bereiche von RetroPie. Dem Raspbian (Bash), Emulationstation, RetroArch under Emulation. Achtet nur darauf, daß ihr unter der Emulation nicht aus Versehen den Controller über die PS-Taste abschaltet!

Ein weiterer Mißstand in diesem Zusammenhang ist die Tatsache, daß obwohl aus dem Spiel heraus, das Speichern auf Memorykarte problemlos klappte, dieser Speicherstand nach einem Crash (oder Notfallsteckerziehen) verschwunden war. Das hat damit zu tun, daß RetroArch erst dann die virtuelle Speicherkarte auf die echte SD-Karte schreibt, wenn dieses ordnungsgemäß beendet wurde. Stürzt die Emulation ab, sind alle Memorykartendaten futsch. Diesen Umstand kann man aber abstellen, indem man die Autosavefunktion aktiviert. Diese befindet sich unter "Settings/Save/SaveRAM autosave interval". Stellt ihr dort zB. den Wert 300 ein, wird die Memorykarte alle 5 Minuten auf die SD-Karte gesichert. 5 -10 Minuten sind nach meinem Empfinden ein guter Wert, da man ja nicht jede Minute einen Spielstand aus einem Spiel speichert - nur zu schnelle Intervalle sollte man vermeiden. Beendet man nämlich die Emulation bei einem Speichervorgang, könnte das Beenden selbiger ebenfalls einen Datenverlust bedeuten - da RetroArch ja wiederum im selben Moment abspeichert - und zweimal gleichzeitig kommt eben nicht so gut für die Daten. Am Besten ist es eh, eine Kombination aus beiden Speicherarten zu verwenden - das reguläre Speichern über Memorykarte für alle Fälle (falls der Emu mal absemmeln sollte) und via Savestates zum direkten Einstieg jederzeit ins Spiel. Der "Zerstörfall" ist bei mir noch nie eingetreten - wäre auch Zufall, diesen Moment genau zu treffen. Je höher der  Speicherintervall, desto unwahrscheinlicher wird es.

Kommen wir noch auf zwei Punkte zu sprechen. Wenn euer PS3-Klon-Controller dauerhaft beim USB-Kabelanschluss vibriert, dann solltet ihr euer System updaten!

Gebt in der Bash ein:

sudo apt-get update && sudo apt-get dist-upgrade

Meist schon installiert, aber zur Sicherheit gegenchecken:

sudo apt-get install raspberrypi-sys-mods

Nach dem Update sollte das Dauerrumblen weg sein - allerdings müssen einige Einstellungen der Vorgängertutorials (etwa das Einbinden der Festplatte) neu eingestellt werden, da nun einige Daten überschrieben sind. Auch bemerkte ich, daß der PSP-Emu nicht mehr laufen wollte. Wer das RetroPie-Script updatet, wird evtl. eine neue Kontaktverbindung via Bluetooth "Sixaxis" bemerkt haben - diese kann nachinstalliert werden. Das Schöne hierbei ist - man kann Geräte nun über den Emulationstationmenüpunkt pairen und sogar die Timeoutzeit einstellen - allerdings gibt es kein Rumble!

Auch kann man immer nur die gleichen PS3-Controllertypen gleichzeitig nutzen - eine Mischung zwischen Original und Klon ist nicht möglich, da die Treiber sich gegenseitig überschreiben.

Jetzt noch ein Tip am Rande. Wie bei der Playstation 3 muss der Pi die ganze Zeit laufen, damit der Controller geladen wird. Dieser Zustand ist schlecht von Sony gelöst, schlecht durchdacht und kontraproduktiv. Leider benötigen die Controller neben der Stromversorgung "aktive" Datenleitungen, um den eigenen Ladezustand der Konsole mitzuteilen. Ist diese aus, wird nicht geladen. Daher kann man die Controller nur mit einem laufenden System - das kann auch ein PC oder Laptop, Pi oder Mac, usw. sein - laden. Dem mußte ich einfach entgegensteuern. Neben diversen Ladestationen, von denen die Meisten ein Witz sind, da sie ebenfalls über das USB von der PS3 angeschlossen werden, gibt es aber auch Systeme mit eigenem Netzteil. Sehr interessant fand ich, daß eines der günstigen (mittlerweile, früher war das 3x so teuer) Lademöglichkeiten von Sony selbst stammt. Es nennt sich "Netzanschluss Sony USB AC Adapter" und bietet die Möglichkeit, 2 Controller oder andere Sony Gerätschaften wie Move, Tastatur oder Headset laden zu können - an einer regulären Steckdose. Neben dem Lader kommt auch gleich ein passendes USB-Kabel zum Anschluss der Geräte mit. Der Preis liegt bei 9,99 Euro komplett - also inkl. Versand. Da kann man nichts verkehrt machen, schließlich ist der Lader von Sony selbst und für deren Controller ausgelegt. So kann man beruhigt Nachts schlafen, seine Konsole, bzw. den Pi ausgeschaltet lassen und dennoch seine Geräte für den nächsten Einsatz aufladen. Sucht nach der Bezeichnung bei Ebay - der Verkäufer ist übrigens gameworld.de.

Zum Schluss noch die Info, daß dies alles auf meine Begebenheiten und Erfahrungen basiert, welche ich an meinem Pi3 erlebt habe. Mein RetroPie basiert nach wie vor auf dem 2017er System Jessie - mittlerweile ist ja Stretch als Unterbau vorhanden. Da ich bislang noch keinen Sinn zu Updaten sehe, bleibt es auch so - bis ich einen sinnvollen Updateweg mit all meinen mühsam eingepflegten Daten gefunden habe - sowie dem Umstand, daß am Ende auch alles wieder läuft. Mal sehen, aber im Moment steht Zocken bei mir an erster Stelle - die Emus kann man ja per Hand updaten. Sollte es mal soweit sein, werdet  ihr es als erste erfahren und weitere Tutorials werden folgen.

Diese meine Erfahrung muss also nicht bei jedem so sein - aber falls ihr die selben Probleme haben solltet, könnt ihr euch mit diesen Hinweisen ein sehr passables Workaround schaffen, was diese wirklich nervigen und untragbaren Klippen umschifft.

Viel Spaß weiterhin bei eurer Spielemaschine und mögen sich weitere Probleme gar nicht erst formieren.

close

Dieser Artikel wurde vor 1 Jahr(en) , 2 Monat(en) und 7 Tag(en) veröffentlicht, es ist also möglich, dass der Inhalt inzwischen nicht mehr aktuell ist.

Schlagworte : RaspberryPi, Tutorial, C-64, Emulation, Digital Talk

Trixter
Administration Nemesiz v4 Projekt
Aufgaben im Nemesiz: Administrator, Autor & Moderator, Übersetzung & Bugfixing
Freier Redakteur bei Special Interest Magazinen & Online-Blogs
Retro & Emulation, Alternative Computersysteme, Schwerpunkt: Spiele

  • Schreibe einen Kommentar


    Dein Name (Pflichtfeld):



    Deine Webseite (optional - http://www.):



    Deine E-Mail (wird nicht veröffentlicht):



    Dein Kommentar:

     Soll unser Blog deine Daten für weitere Kommentare merken? (setzt Cookie)
      1x aktiviert ist die Funktion gültig bis Cookielöschung. (Haken rein = Ja)

    Was ist der letzte Buchstabe des Wortes burzc ?
Evtl. Statusmeldungen erscheinen nach dem Absenden in roter Schrift direkt unter
dem Artikel - bitte Herunterscrollen, falls dein Browser wieder zum Anfang der Seite
gesprungen ist. Beachte: Neue Kommentare erscheinen erst nach Freigabe durch
einen Administrator!
Danach wird dein Name mitsamt Email auf unsere Whitelist
gesetzt und deine Kommentare bei uns erscheinen dann immer direkt. (Spamschutz)
↓