Beiträge von RobertMV

Hi,

das geht meiner Meinung nach am besten mit einer advancedsettings.xml Datei und der sogenannten pathsubstitution.

Genaueres dazu hier: https://kodi.wiki/view/Advancedsettings.xml#pathsubstitution

Es könnte zum Beispiel so aussehen:

<advancedsettings>
	<pathsubstitution>
		<substitute>
			<from>special://profile/playlists/</from>
			<to>nfs://DEINSERVER/volume1/public/Kodi/v21/userdata_shared/playlists/</to>
		</substitute>
	</pathsubstitution>	
</advancedsettings>

Dann hättest du auf deiner Synology NAS einen Ordner /public/Kodi/v21/userdata_shared/playlists und darin wären dann sozusagen die Playlists, die abgelegt werden, von überall abrufbar. Natürlich kann dein Ordner auf deinem NAS auch einen anderen Pfad haben. Aber so sieht es bei mir zum Beispiel aus. Ich habe relativ viel auf diese Art "ausgelagert", um es mit den verschiedenen Kodi-Installationen systemübergreifend synchron zu halten. Das wichtigste sind wohl die Favoriten.

Du musst auch gucken, ob du NFS- oder SMB-Dateifreigaben nutzt. Aber wenn man ein wenig damit probiert, kann man sich super einen zentralen Ablageort ausgewählter Dateien und auch ganzer Plugin-Einstellungen schaffen, die dann alle synchron sind. Lies mal unter dem Link oben.

Hallo Harry,

ich habe soeben deine überarbeiteten Skripte mit "PINCTRL" in einem frischen LibreELEC 12 (11.95.2) geprüft. Das Verhalten ist identisch zu dem anderen erfolgreichen Versuch. Also es funktioniert alles bestens und auch wieder in beide Richtungen. (Wie gewohnt.)

Das wäre dann eine zukunftssichere Version oder?

Zu der anderen Frage (aus deiner privaten Nachricht) bezüglich der eventuellen Strombegrenzung über das RemotePi Board an einen Raspberry Pi 5 hilft dir hoffentlich die Support-Seite vom Hersteller aus dem ZIP oben weiter. Offiziell wurde es ja für die Modelle Pi 4, Pi 3, Pi 2 and B+ konstruiert.

Noch einmal vielen Dank für deine Mühen. Bei Fragen gerne wieder melden. (Einen Pi 5 habe ich allerdings nicht zur Hand.)

HarryH, genau diese von dir berechneten Änderungen der GPIO pin Nummern funktionieren!

Und zwar genau wie früher - in beide Richtungen. Also Ausschalten per Oberfläche fährt herunter und direkt im Anschluss schaltet sich die Platine ab. Und wenn ich per Platine das Signal gebe, fährt LibreELEC ordnungsgemäß herunter und auch dann schaltet sich die Platine im Anschluss ab und wartet auf ein Wiedereinschalten.

Einfach genial, wie ihr mir (und wahrscheinlich anderen) hier geholfen habt. Sowohl mit eurem Wissen als auch durch die hilfsbereite und freundliche Art.

Ich sage vielen Dank für eure Zeit und Mühen. Eine Freude, dass es wieder funktioniert.

Bash: irswitch.sh

#!/bin/bash
    # this is the GPIO pin receiving the shut-down signal
    GPIOpin1=526

Bash: shutdown.sh

#!/bin/bash
    if [ "$1" != "reboot" ]; then
      GPIOpin=527
      GPIOpin1=526

Ich habe die gesamte Anleitung für die Zukunft aktualisiert. "usleep" wurde durch "sleep" ersetzt und die GPIO-Pin-Nummern wurden dem neuen Zählsystem angepasst - alles auf deutsch übersetzt.

Als .htm Datei (im .zip gepackt), damit man mit Zeilenumbrüchen daraus mitkopieren kann.

"RemotePi (v2015) Shutdown-Skripte für LibreELEC 12.0 und OpenELEC – MSL Digital Solutions" nun hier im Anhang.

Hallo HarryH,

das klingt vielversprechend und deine Begründung klingt auch logisch. Danke, dass du auch deine Gedanken zur Herleitung geschildert hast, sodass es zukünftige Leser hier nachvollziehen können. Ich kann heute Abend gegen 20 Uhr eine Rückmeldung geben.

Hey DaVu, vielen Dank. Das Angebot mit dem Video-Call und geteiltem Bildschirm würde ich gerne annehmen und probieren. Was benötige ich zur Vorbereitung? AnyDesk könnte ich installieren auf meinem Windows-PC. Mikrofon (Headset) ist vorhanden. Brauche ich auch eine Webcam? Die könnte ich bei Bedarf anschließen. FileZilla ist auch vorhanden, womit man mit grafischer Oberfläche auf die Ordnerstruktur vom Raspberry Pi 4 mit LibreELEC Zugriff bekommt. putty für den Zugriff per Eingabeaufforderung ist ebenfalls vorhanden und als Editor ist Notepad++ installiert.

Ich kann ja mal zwei eventuell relevante der gespeicherten Webseiten vom Hersteller hier als ZIP-Archiv anhängen. (Erledigt.) Das eine ist die Anleitung vom Hersteller und das andere ist eine "Support-Seite" mit Pin-Belegung usw. Dann siehst du auch mal den Aufbau der kleinen Platine.

In der Woche könnte ich immer ab 19 Uhr. Nur heute wird es leider nichts bei mir. Oder sonst am Wochenende, da bin ich auch flexibler. Wenn du einen oder zwei Terminvorschläge hättest, würde ich es bei mir zeitlich einrichten. Wenn es bei dir nur früher am Tag geht, dann nehme ich mir mal Home-Office. Aber es ist sicher schwer vorab abzuschätzen, wie viel Zeit beansprucht wird.

Ich finde das sehr nett mit deinem Angebot. Hab vielen Dank. Das Wiki von ubuntuusers.de habe ich auch mal als Lesezeichen gesetzt. Ein paar Sachen kommen mir sogar bekannt vor von früheren "Experimenten" mit einer gerooteten Android-TV-Box und auch beim Synology-NAS.

Ok, das abändern des dritten Scripts, wie oben, hat leider keine Änderung bewirkt. Ich habe sogar eine frische SD-Karte mit LibreELEC 12 neu installiert und das alles von vorne mit der abgeänderten dritten "shutdown.sh" probiert. Schade, aber es war einen Versuch wert und ich danke dir für deine Zeit und Mühe. (Falls es am Ende eine Lösung gibt, kann das bestimmt auch anderen Leuten helfen, die das Board gekauft haben mit IR-Empfänger. Es war mal ziemlich beliebt damals.)

Gibt es vielleicht noch andere Ideen oder Ansätze?

Zitat von DaVu

Ich schaue mir die Scripte gleich noch genauer an. Grundlegend habe ich auch verstanden, was da passieren soll.

Was ich gern noch wissen würde...du sagst, es passiert nichts dergleichen. Was genau passiert denn nicht? Fährt Kodi nicht runter oder schaltet sich der Pi nicht ab?

Man könnte noch anfangen ein paar Debug-Infos einzubauen. oder sich schon mal im Vorfeld ein paar Dinge rausziehen bevor das irswitch einsetzt.

Mich würde zumindest interessieren, was der Inhalt dieser Variablen ist:

power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)

Denn irgendwann muss ja in die if-Bedingung gewechselt werden. Nämlich dann, wenn "$power" nicht "0" ist. Also wahrscheinlich ist es "1". Wenn ich es richtig verstehe ist der Pin14 immer auf "0" außer, wenn er ein Shutdown-Signal bekommt... Hast du das geprüft, dass er das Signal bekommt oder vielleicht ist es auch ein anderer Pin.

In diese Richtung müsste man prüfen, denke ich.

Ich habe die Scripte mal durch Shellcheck laufen lassen. Grundlegend sieht es erstmal gut aus. In den Scripten sind erstmal technisch keine Fehler. Der Hase wird also fachlich irgendwo im Pfeffer liegen.

Ich habe noch kein LE12 installiert. Mein Linux-System (Fedora) sagt mir aber, dass das Kommando "usleep" deprecated ist und in Zukunft nicht mehr supported wird. Anstelle von

usleep 125000

soll man

sleep 0.125

nehmen. Wenn das bei LE12 schon der Fall ist, dass es deprecated ist, dann könnte es sein, dass die Variablen zu schnell geschrieben werden sollen und es da zu Fehlern kommt. Ich würde ggf. das Kommando auf "sleep" ändern und die Werte alle durch 100000 teilen um auf den gleichen Wert zu kommen.

Du kannst aber ja schon mal anfangen zu prüfen, welchen Wert die entsprechenden Variablen haben oder ob der Pin14 wirklich noch der ist, der das Shutdown-Signal bekommt

Alles anzeigen

Hallo DaVu,

vielen Dank, dass du dich der Sache angenommen hast. Zuerst möchte ich deine Frage beantworten. Die kleine Hardware-Platine mit dem Infrarotempfänger hat eine Leucht-Diode. Wenn alles richtig programmiert ist, dann drücke ich auf der Fernbedienung die Taste zum Ausschalten und dann fängt die Diode (langsam) an zu pulsieren und nach ca. drei Sekunden sieht man, wie LibreELEC beginnt ordnungsgemäß herunterzufahren. Ca. vier Sekunden nach dem Herunterfahren erlischt die Diode und der IR-Empfänger ist im Standby und wartet auf ein Signal zum Einschalten. Dann würde die Diode wieder angehen und der Raspberry Pi hochfahren.

Oder das andere Szenario: Wenn alles ordnungsgemäß programmiert ist und ich in Kodi über die Grafikoberfläche "Ausschalten" wähle, dann fährt Kodi sauber herunter (In diesem Fall geht durch die Einstellungen in Kodi auch der TV mit aus.), die Diode pulsiert wieder langsam, bis das Herunterfahren abgeschlossen ist und erlischt dann.

Das jetzige (nicht korrekte) Szenario ist, als ob das Script nicht eingefügt wurde, wie folgt: Gebe ich dem IR-Empfänger das Signal zum herunterfahren, dann pulsiert die Diode (schnell!) und Kodi macht nichts. Nach 4 Minuten gibt es dann einen Cut zum Strom und der Raspberry wird vom Strom unterbrochen, womit Kodi nicht sauber heruntergefahren ist, sondern "plötzlich der Strom weg ist".

Oder wenn ich Kodi im jetzigen (falschen) Szenario über die Grafikoberfläche in Kodi mit "Ausschalten" herunterfahre, fährt Kodi sauber herunter, aber die Diode und die Hardware-Platine (RemotePi) bleiben an. Also der Strom wird nicht unterbrochen, womit ich es nicht per Fernbedienung wieder anschalten kann.

Da vorher alles funktioniert hat, erhoffe ich mir am ehesten einen Erfolg mit dem von dir erwähnten Ändern der "usleep" Befehle.

Es würde dann ja nur die letzte Datei betreffen, die "shutdown.sh". Denn nur sie enthält "usleep" Befehle.

Soll ich sie dann ändern in:

#!/bin/bash
if [ "$1" != "reboot" ]; then
  GPIOpin=15
  GPIOpin1=14
  echo "$GPIOpin" > /sys/class/gpio/export
  # execute shutdown sequence on pin
  echo "out" > /sys/class/gpio/gpio$GPIOpin/direction
  echo "1" > /sys/class/gpio/gpio$GPIOpin/value
  sleep 0.125
  echo "0" > /sys/class/gpio/gpio$GPIOpin/value
  sleep 0.2
  echo "1" > /sys/class/gpio/gpio$GPIOpin/value
  sleep 0.4
  echo "0" > /sys/class/gpio/gpio$GPIOpin/value
  # set GPIO 14 high to feedback shutdown to RemotePi Board
  # because the irswitch.sh has already been terminated
  echo "$GPIOpin1" > /sys/class/gpio/export
  echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
  echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
  sleep 4
fi

Die vorletzte Zeile müsste dann ja "4" ergeben. (Wahrscheinlich ist "sleep 4" korrekt und man muss alle kürzen, was geht, denn in einer der oberen Datein steht auch schon ein Befehl mit "sleep 3")

Und muss ich danach nochmal den Befehl "chmod +x shutdown.sh" eingeben, um die Änderungen ausführbar zu machen?

Mit dem oberen geänderten Code hat es leider nicht funktioniert.

Deine Frage nach der Variablen

power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)

kann ich leider nicht beantworten. Ich weiß nur, dass die Anleitung ganz oben vom Hersteller unter LibreELEC 11 und tiefer immer sauber funktioniert hat. Darum sollte das alles schon gut programmiert worden sein.

Ich habe daher auch die Änderungen im Kernel in Verdacht, wie auch joeAverage62 geschrieben hat. Diese Spur würde ich gerne als erstes verfolgen. Also schon mal vielen Dank für deine Bemühungen. (Denn dieser Infrarot-Empfänger ist ein wirklich tolles Teil und schafft einfach das bisschen extra Konfort für dieses tolle Mediacenter Kodi auf dem Raspberry. )

Hallo zusammen,

ich bin gerade mit dem Raspberry Pi 4 auf LibreELEC 12 umgestiegen. Ich habe auch das sogenannte Hardware-Modul "RemotePi" von MSL Digital Solutions auf dem Rasberry, womit man mit einer IR-Fernbedienung das Geräte ein- und ausschalten kann. Die Seite des Herstellers ist leider down, weil das Geschäft eingestellt wurde. Jedoch hatte ich mir die Anleitung zum Installieren der nötigen Scripte in LibreELEC gespeichert. Bei LibreELEC 11 klappt alles wunderbar. (Ich habe es sogar extra ausprobiert mit einer 11er-Version.) Nur bei der neuen Version klappt es leider nicht.

Mit der Anleitung geht man in den Ordner ".config". Dort erstellt man dann die drei kleinen Skripte und macht sie mit dem "chmod"-Befehl ausführbar.

Dadurch kann man mit einer IR-Fernbedienung Kodi ein Signal geben, dass es vernünftig herunterfährt und sich die Hardware danach abschaltet. Oder wenn Kodi per Oberfläche heruntergefahren wird, sendet es ein Signal an die Hardware und diese schaltet sich dann im Anschluss ab.

Mit LibreELEC 12 passiert leider nichts dergleichen. Die Scripte sind aber da. Das habe ich mit FileZilla überprüft. Es steht auch alles korrekt drin.

Leider bin ich nicht besonders bewandert in Sachen Linux, aber es hat bisher immer gut funktioniert und ich verstehe auch, was dort gemacht wird.

Am besten, ich poste hier mal die Anleitung. Vielleicht muss ja nur eine Kleinigkeit geändert werden mit der neuen Version. Soweit ich weiß, wurde auf 64 bit umgestellt mit LE 12. Ich bedanke mich jetzt schon für anregende Lösungsvorschläge.

Man stellt eine Verbindung mit LibreELEC über putty her (root als Username + Passwort) und befolgt dann diese Anleitung vom Hersteller (Ich habe alle Eingaben als "Code" formatiert. Also die Zeilennummern, die hier erscheinen, sind in der Anleitung nicht vorhanden.):

The default SSH user name is root, password openelec (password for LibreELEC is libreelec).

The first part of the instructions below adds the main shutdown script for the RemotePi Board to the autostart.sh file, which enables the script to run when the OS starts.

Key in (mind the . in front of config !) :

cd .config

nano autostart.sh

Copy and paste (use shift+ins to paste in nano) the following into the nano editor window. If there is already something in the file, just add the following as the last lines. If the last line is exit 0, then place the following lines before that line.

#!/bin/bash
(/storage/.config/irswitch.sh)&

Press ctrl+x to exit the editor, y to confirm, enter to save the file

Key in

chmod +x autostart.sh

The next part creates the main RemotePi Board shutdown script. This script shuts down the OS safely, when the button on the RemotePi Board or the off button on the remote is pressed :

Key in

nano irswitch.sh

Copy and paste the following text into the editor window

#!/bin/bash
    # this is the GPIO pin receiving the shut-down signal
    GPIOpin1=14
    echo "$GPIOpin1" > /sys/class/gpio/export
    echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction
    while true; do
      sleep 1
      power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
      if [ $power != 0 ]; then
        echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
        echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
        sleep 3
        poweroff
      fi
    done

• Press ctrl+x to exit, y to confirm, enter to save the file

• Key in

  Code

  chmod +x irswitch.sh

The following additional script enables the RemotePi Board to cut off the power, after OpenElec / LibreELEC has been shut down from the on-screen menu.

Key in :

nano shutdown.sh

Copy and paste the following contents

#!/bin/bash
    if [ "$1" != "reboot" ]; then
      GPIOpin=15
      GPIOpin1=14
      echo "$GPIOpin" > /sys/class/gpio/export
      # execute shutdown sequence on pin
      echo "out" > /sys/class/gpio/gpio$GPIOpin/direction
      echo "1" > /sys/class/gpio/gpio$GPIOpin/value
      usleep 125000
      echo "0" > /sys/class/gpio/gpio$GPIOpin/value
      usleep 200000
      echo "1" > /sys/class/gpio/gpio$GPIOpin/value
      usleep 400000
      echo "0" > /sys/class/gpio/gpio$GPIOpin/value
      # set GPIO 14 high to feedback shutdown to RemotePi Board
      # because the irswitch.sh has already been terminated
      echo "$GPIOpin1" > /sys/class/gpio/export
      echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
      echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
      usleep 4000000
    fi

Press ctrl+x to exit, y to confirm, enter to save the file

Mark the script as executable by keying in

chmod +x shutdown.sh 

Reboot from the OpenElec or LibreELEC OS GUI.

After reboot you can use the RemotePi Board to power cycle OpenElec / LibreELEC

Hallo allerseits,

ich wollte mitteilen, dass für den http://orbsmart%20s84 (Android 7.1) folgender Device Tree verwendet werden kann, um CoreELEC zum Laufen zu bringen:

Es funktioniert alles: WLAN, LAN, Bluetooth, CEC usw.

Nur die "Zurück-Taste" von meiner zusätzlich erworbenen Orbsmart AM-1 Fernbedienung / Airmouse funktioniert nicht. Bei der normalen Android 7.1 Firmware geht die Zurück-Taste der AM-1 ganz normal.
Aber ich steuere das Ganze sowieso meistens mit der TV-Fernbedienung. Über HDMI CEC geht die "Zurück-Taste" der Philips TV Fernbedienung.

Herausgefunden habe ich die Kompatibilität übrigens, weil im XDA-Forum jemand das sogenannte Poison Rom als alternative Firmware (Custom Rom) für S912 Android TV-Boxen entwickelte und dafür ein Sunvell T95Z als Grundlage verwendet hat. (Poison Rom funktioniert beim Orbsmart S84 aber nicht 100%ig. WLAN geht zum Beispiel nicht.)

Schade, dass die Entwickler CoreELEC mit Kodi Matrix nicht für S912 Prozessoren weiterentwickeln bzw. mit Leia die letzte Version portiert haben. CoreELEC und LibreELEC sind einfach klasse.

Hallo,

danke für deinen Link und die Anregung.
Ich selbst habe auch noch drei Ansätze, die ich vorher ausprobieren möchte:

- Ich probiere mal, ob RCB die Roms an die jeweilige Emulator-App durchreichen kann, wenn diese lokal auf der SD-Karte liegen.

- Wenn das klappt, probiere ich in Kodi mal die Roms vom NAS per NFS Freigabe in RCB zu "verlinken", statt per Samba. Denn Samba beötigt ja von jedem Programm bzw. jeder App extra das Passwort und den Usernamen. Vielleicht scheitert es daran... Per nfs könnte ich auf dem NAS der ganzen Android TV Box anhand deren IP Zugang gewähren. Das würde dann die Authentifizierung überflüssig machen.

- Sollte das auch nicht klappen, werde ich versuchen, den ganzen NAS Ordner doch irgendwie in Android einzubinden. Dafür werde ich zwei Anleitungen probieren: https://www.nvidia.com/en-us/geforce/…lesystem-root-/

und alternativ

https://stackoverflow.com/questions/2173…internal-folder

Die Anleitungen sind zwar etwas älter, aber das ist das installierte Android 7.1 ja auch... Root ist eh vorhanden.

Ich werde berichten.

Hallöchen,

ich konnte die Parameter aus der emu_autoconfig.xml in die config.xml im userdata Ordner deines Addons übertragen. Ich musste das Addon allerdings erstmal austricksen, damit er mir eine config.xml überhaupt anlegt, da er ja sofort beim Start einen Pfad zum Emulator unter Android verlangt. Wenn man da nichts einträgt oder ihn zu keiner Datei führt, legt er auch keine config.xml an. (Habe dann einfach erstmal auf ein Spiel verlinkt... das hat er geschluckt.) Das Scrapen mit meinem lokalen Material (Spiele, Boxart, Gampelay-Video) lief wieder einwadfrei vom NAS.

Ich habe es mit SNES9X plus probiert und in der config.xml die Zeilen auf das folgende geändert.

<emulatorCmd>/system/bin/am</emulatorCmd>      
<emulatorParams>start --user 0 -n com.explusalpha.Snes9xPlus/com.imagine.BaseActivity -a android.intent.action.VIEW -eu Uri "file://%rom%"</emulatorParams>

Quasi genau das, was du mir oben ebenfalls geraten hattest. Dies bewirkt nun, dass der Emulator (Die Android App SNES 9x plus) zwar aus Kodi heraus gestartet wird, aber leider lande ich dort dann nur im Hauptmenü. Das Spiel, welches der Rom Collection Browser in Kodi ja vom meinem NAS gescraped hat und welches ich auswähle, startet nicht. Ich kann dann in dem Emulator wieder nur die lokalen Spiele auswählen. In sofern habe ich da leider nichts gewonnen. Auch habe ich etwas "Angst", da die Auflösung von Kodi sich vertsellt, nachdem ich die Android App (SNES9x plus) wieder schließe. Kodi hängt dann verkleinert in der unteren linken Ecke. Zum Glück war das nach einem Neustart von Kodi wieder in Ordnung.

Muss vielleicht der Teil "file://%rom%" an die Rom-Quelle angepasst werden? Oder muss das da so stehen bleiben?

Ich könnte zum Test die Parameter für Mupen (N64 Emulator) probieren und ich habe mir die APK vom Emulator "nes.emu" (Emulator für das NES) angeschafft, die ebenfalls laut der emu_autoconfig.xml unterstützt wird. Ich fürchte aber fast, dass die Roms vom NAS dann ebenfalls nicht "durchgereicht" werden. Falls doch, wäre für das SNES eine Alternative Emulator-App vielleicht eine Überlegung wert.

--

Update:
Wenn ich ein NES-Spiel auswähle, öffnet sich leider ebenfalls der frisch installierte Emulator "nes.emu" (die Android-App) im Hauptmenü, aber ohne das Spiel vom NAS zu starten. Auch hier ist nach dem Beenden Kodi in der "falschen Auflösung" und unten links in die Ecke gequetscht...

<RomCollection id="3" name="NES">
<gameclient />
<emulatorCmd>/system/bin/am</emulatorCmd>
<emulatorParams>start --user 0 -n com.explusalpha.NesEmu/com.imagine.BaseActivity -a android.intent.action.VIEW -eu Uri "file://%rom%"</emulatorParams>

Für N64 funktioniert es leider gar nicht. Ich habe dafür den Mupen64plus free Emulator aus dem Playstore in Android installiert. Es gibt dafür zwei Angaben in der emu_autoconfig.xml: Einmal ohne "root" und einmal mit "root". Beide Varianten haben den Effekt, dass sich beim Auswählen eines Spieles die Auflösung kurz verringert und dann wieder auf FullHD zurückspringt, aber es öffnet sich nicht der Emulator oder das Spiel. (Meine Android TV Box ist von Haus aus gerootet.)

Vielleicht hilft das ja irgendwie weiter. Würde mich freuen.

Hallo und danke fürs Antworten. Ich kann erst wieder ab Freitagabend rumprobieren, bin aber echt dankbar, wenn wir der Sache mal auf den Zahn fühlen könnten. Ich berichte mal, nachdem ich dem Tipp nachgehen konnte. Vielleicht versüßt es mir (und anderen) am Ende ja noch die bevorstehende Zeit des Lockdowns.

Wirklich toll, danke im Voraus.

Hallo FoLeY,

der Grund ist, dass scheinbar nur Kodi auf das NAS zugreifen kann. Retroarch und co. können das in Android leider nicht und anders als zum Beispiel bei der Nvidia Shield kann man leider in Android keinen Netzwerkordner mounten, auf den dann alle Apps zugreifen können. Mit Retroarch zum Beispiel bekomme ich zwar alles unter einen Hut, aber eben nur auf der Box / SD-Karte.

Vielen Dank für deine Hilfeversuche. Wirklich sehr nett.
Das mit der config.xml habe ich probiert, aber leider ohne Erfolg. Vielleicht liegt es dann noch an den fehlenden Start-Parametern. Einen Versuch war es wert und so kann ich tatsächlich die Pfade ändern.

Ich habe mein Anliegen mal hier im deutschsprachigen Thread veröffentlicht. https://www.kodinerds.net/index.php/Thre…tend/?pageNo=29
Vielleicht hilft das in Zukunft ja mal anderen Leuten mit Kodi und Retrogames auf Android.
Der englische Thread von deinem Link wird zwar wahrscheinlich häufiger gelesen, aber für die Problematik ist mein Englisch leider nicht gut genug.

Besten Dank und einen schönen Abend.

Guten Abend,

ich möchte mich nach vielem Ausprobieren hier einmal melden, weil ich bei einer Sache beim besten Willen nicht weiterkomme. Ich habe wirklich viel gelesen und versucht.

Und zwar habe ich eine Android-TV-Box (Orbsmart S85) mit Android 7, die von Werk aus gerootet ist. In Android sind folgende Emulatoren installiert:

• für NES: Nostalgia. NES Pro
• für SNES: snes9x EX+
• für N64: Mupen64 Plus free

Es läuft alleine auch alles gut. Jedoch würde ich zu gern den Rom Collection Browser nutzen in Kodi Leia (18.8), welches ebenfalls auf der Android Box installiert ist. Der wichtigste Vorteil ist, dass ich dann auf die ROMs zugreifen könnte, die auf meinem NAS liegen. In Android ist es leider unmöglich ein Netzlaufwerk einzubinden und die Emulatoren können nicht auf Netzwerkadressen zugreifen. Zudem sieht die Darstellung im Rom Collection Browser mit den Vorschauvideos etc. echt schön aus.

Nun zu meinem Problem. Ich habe in den RCB in der aktuellen Version 2.2.4 + das Service Addon 1.0.1 installiert. Beim Anlegen einer Rom Collection fragt er gleich als erstes nach dem Pfad zu dem entsprechenden Core / Emulator. Aber wie gehe ich hier vor? Es gibt ja leider keine .exe-Datei, wie zum Beispiel bei Windows. Es handelt sich ja im Unterbau um ein reines Android-System. In der veralteten Version aus dem Kodi-Respository hat er die unter Android installierten Emulatoren selbstständig gefunden und somit konnte man sie einfach auswählen und hatte auch gleich die richtigen Parameter eingefügt. Leider kommt nach dem Anlegen mit der alten RCB-Version ein "schwarzer", leerer Bildschirm nach dem Einlesen der Roms und das Plugin bekomme ich nur geschlossen, wenn ich die Collection wieder per Menü lösche oder Kodi in der Android-Ebene kalt beende.

Folgendes habe ich gemacht, was vielleicht bei der Lösungsfindung helfen könnte - oder ich bin komplett auf dem Holzweg...

Da die Android-Box von Werk aus gerooted ist und ich etwas "rumsuchen" konnte, vermute ich, dass die Datein, auf die ich bei dem "Pfad zum Emulator" verweisen soll, wie folgt aussehen und dass sie sich im Root-Verzeichnis befinden:

• NES:
  
  Code

  /data/app/com.nostalgiaemulators.nesfull-1/lib/arm64/libnostalgia.so

• SNES:
  
  Code

  /data/app/com.explusalpha.Snes9xPlus-2/lib/arm64/libmain.so

• N64:
  
  Code

  /data/user/0/paulscode.android.mupen64plus.free/lib/libcore.so

Leider kann ich von Kodi aus nicht zu diesen Ordnern navigieren! Ich komme im Kodi-Dateibrowser nur bis zum Ordner "data" und nicht weiter. (Auch die Option mit den versteckten Dateien ändert daran nichts.)

Warum denke ich, dass das die Cores sind? Weil ich mir testweise die Ordner auf meine SD-Karte kopiert habe und dann konnte ich die *.so-Dateien tatsächlich als Emulatoren auswählen am Anfang des Erstellens einer Rom Collection. Sie scheinen also die richtige Endung zu haben. Nur starten die Spiele so leider nicht und in den Parametern steht auch nur jeweils "%ROM%". Da bezweifele ich auch, dass das reicht...
Aber diese Tests hatten ein Gutes. Das "Scrapen" ist so wenigstens einmal komplett durchgelaufen und mit dem RCB Version 2.2.4 erscheinen am Ende dann auch die Roms mit schönem Artwork. - Nur die Emulatoren starten eben leider nicht, wenn ich ein Spiel spielen möchte - was ja klar sein dürfte, bei den "falschen Locations".

Ein Tipp vom User Gurkensandwich91 war, dass ich mal die config bearbeiten könnte und dort die Verzeichnisse manuell eintrage. Also habe ich mir die config.xml vom RCB mal eben kopiert und die Angaben per Hand angepasst. Ein Beispiel für NES sieht nun wie folgt aus:

<emulatorCmd>/data/app/com.nostalgiaemulators.nesfull-1/lib/arm64/libnostalgia.so</emulatorCmd>

Aber leider startet nach einem Neustart der NES-Emulator immer noch nicht. Wahrscheinlich fehlen hier einfach noch die entrsprechenden Parameter beim Durchreichen des Roms an den Emulator.

Kann mir jemand helfen, die scheinbar sehr spezielle Vorgehensweise im OS Android begreiflich zu machen und helfen, dass die Emulatoren korrekt angesprochen werden? Ich weiß nicht mehr weiter. Echt schade, dass nicht, wie in der alten Version, die Emulatoren automatisch erkannt und auswählbar gemacht werden beim Anlegen der Rom Collection. Genau diese Funtion würde ich brauchen, denke ich.

Unten habe ich noch Bilder mit den vermuteten Ordnern im Root-Verzeichnis angefügt. Auch ein Foto vom fertigen Durchklauf eines Test-Rom-Verzeichnisses. Das sieht gut aus! Aber beim Auswählen eines Spieles passiert dann eben leider nichts. Bitte helft mir.

Ich bedanke mich schon mal Voraus und entschuldige mich für den langen Text. Aber so konnte ich hoffentlich die Situation schon stark eingrenzen und deutlich machen.
Und wenn weiteren Daten und Angaben benötigt werden, bemühe ich mich, diese schnell nachzureichen.

Robert

Hi Gurkensandwich91,

vielen Dank für deine Antwort. Ich habe es erst mit der (veralteten) Version probiert, weil er dort wenigstens die installierten Emulatoren anzeigt, aber dann ist am Ende wirklich alles schwarz.

Wenn ich es mit Version 2.2.4 aus dem github (Ich habe Leia) versuche, dann findet er die Emulatoren nicht automatisch, sondern ich soll dem RCB den Pfad zu den Emulatoren zeigen. Aber wie geht das? Es ist ja leider nicht einfach eine .exe-Datei, wie unter Windows. Und ich glaube, die liegen auch tief im Root-Verzeichnis. Die Android-TV-Box hat zwar von Werk aus vollen Root-Zugriff, nur mit Kodi komme ich nicht in diese Ordner rein.
Ich denke, die Emulatoren unter Android liegen unter Root/data/... Aber ich komme mit Kodi nicht in die Untrerordner vom Verzeichnis "data".

Ich denke aber auch, dass Version 2.2.4 der richtige Weg sein könnte. Denn wenn ich den Pfad zum jeweiligen Emulator weg lasse, werden am Ende der Erstellung einer Rom-Collection wenigstens die Spiele angezeigt mit Artwork usw., wie ich es mir wünsche. Nur startet dann leider kein Spiel, weil dem Addon dann leider der Pfad zum auf Android installierten Core / Emulator fehlt. Hast du eine Idee, wie man dort hin gelangt? Schade, dass er es in der aktuellen Version nicht automatisch erkennt, wie es in der veralteten war.

Vielen Dank schon mal für die Mühen.

Hallo,

die Sache ist zwar schon alt hier, aber auf meiner Android TV Box erlebe ich leider genau das gleiche. Am Ende des Scrapen erscheinen leider nicht die Roms aus der frisch angelegten Rom Collection, sondern ein leerer / schwarzer Bildschirm. Da komme ich auch nur wieder raus, wenn ich über das Menü die Collection lösche.

Es handelt sich um eine Android TV Box (Orbsmart S84).

In den Stand Alone Emulatoren läuft alles bestens auf der Box. Da Kodi bzw. der RCB die Roms aber vom NAS durchreichen könnte, bin ich sehr an einer Lösung interessiert. Ich habe schon alle möglichen Kombinationen versucht, um die Rom Collection anzulegen.

Drei Emulatoren sind im Android Unterbau installiert und werden beim Anlegen der Rom Collection auch gefunden:
NES, Nostalgia. NES Pro
SNES, snes9x EX+
N64, Mupen64 Plus free

Ich bekomme immer den oben geschilderten Effekt des Threadstarters. Vielleicht hat sich ja mittlerweile was getan und es gibt eine Lösung?
Ich bin für jede Hilfe oder Idee dankbar.

Robert