Beiträge von HarryH

  • SMB Zugriff in Kodi total lahm!

    Das „Ignorieren“ war der Grunde weshalb ich überhaupt erst im GitHub und danach in der GUI gesucht habe (Thema: selektive Wahrnehmung ;)). Ich wollte wie gehabt die Settings in der advancedsettings.xml vornehmen und war dann über die oben erwähnte Meldung im kodi.log gestolpert:

    „replacement of cache in advancedsettings.xml“, gefolgt von den Default Einstellungen die er der Meinung war anzuwenden.

    Zitat

    What is the effect on users?

    No functional changes but users with personalized advancedsettings should re-configure File Cache in GUI (only a few clicks). The old settings in advancedsettings.xml will no longer have any effect.

    Zitat
    • Added a new Log message as not lose the possibility of see the cache settings from the debug logs and also to avoid confusions due to the change and old values still in advancedsettings.xml


    Ja, die Einstellungen sind in den normalen KODI Settings gepflegt und sind nicht für händische Eingriffe gedacht, weshalb auch die Diskussion bzgl. PM4K entbrannt war (siehe GitHub Link).

    Code: guisettings.xml
        <setting id="filecache.buffermode">1</setting>                                                                                     
    <setting id="filecache.memorysize">128</setting>                                                                                   
    <setting id="filecache.readfactor">2000</setting>                                                                                  
    <setting id="filecache.chunksize" default="true">131072</setting>

  • SMB Zugriff in Kodi total lahm!

    Die advancedsettings.xml ist dadurch nicht überflüssig geworden. Andere Settings werden immer noch darin abgewickelt. Nur die neu ins GUI gewanderten Einstellungen dürften davon betroffen sein. Eine entsprechende Meldung findet man auch im kodi.log:

    hier aus dem Link im GitHub gegriffen:

    Code
    2023-11-02 17:11:10.659 T:9524     info <general>: New Cache GUI Settings (replacement of cache in advancedsettings.xml) are:
                                                    - Buffer Mode: 4
                                                    - Memory Size: 20 MB
                                                    - Read Factor: 4.00 x
                                                    - Chunk Size : 131072 bytes

  • SMB Zugriff in Kodi total lahm!

    Ob die Einstellungen für den Cache sofort greifen oder ein Neustart fällig ist, kann ich Dir nicht sagen. Ich war auch erst am Wochenende darüber gestolpert und habe das nicht auf Herz und Nieren geprüft.
    Selbst wenn die Einstellungen eigentlich gleich wirksam werden, könnte es sein, dass der noch laufenden Prozess nicht davon profitiert.

    Ich nutze es selbst nicht in dieser Konstellation, aber bei mehreren Clienten könnte sich auf Dauer auch das Einrichten einer zentralen DB (MariaDB) lohnen. Dann könntest Du den vermeintlich schnellsten KODI-Clienten (PC ??) zum Scrapen verwenden und die anderen Clienten profitieren davon.

  • SMB Zugriff in Kodi total lahm!

    Die Hinweise von buers sind auch deshalb wichtig, da die Einstellungen für den Cache mittlerweile unter Einstellungen -> Dienste -> Caching zu finden sind, zumindest in Omega. Deine bisherigen Einstellungen dafür in advancedsettings.xml werden ignoriert.
    Mit Mode 1 wurden vorher alle Zugriffe gechached. Bitte stelle das im Menü analog dazu ein

    • „Alle Dateisysteme puffern, inklusive lokale Dateien“
    • „Speichergröße 256MB“ o. „Speichergröße 384MB“
    • „Lesefaktor 15“

    und schau mal ob sich was ändert.

  • In LibreELEC 12 funktioniert das Script für RemotePI (von MSL Digital Solutions) nicht mehr

    Hallo Robert,

    Danke für die Rückmeldung, da bin ich schon mal beruhigt. :)

    Zitat

    Das wäre dann eine zukunftssichere Version oder?

    Bei der Angelegenheit habe ich derzeit noch Zweifel. Auf der einen Seite habe ich in den verlinkten Quellen gelesen, dass sysfs-gpio als veraltet gilt (deprecated). Ehrlich gesagt, sieht es mir fast so aus, dass pinctrl die selbe Schnittstelle verwendet. Bin mir da aber nicht sicher. Auf der anderen Seite ist pinctrl als Debug-Werkzeug vorgesehen. Wenn sie das absägen und keine sinnvolle Alternative anbieten, wäre das schon eine starke Nummer.

    Hintergrund wird sein, der Kernel soll als Einziger die Oberhand haben. Die verschiedenen Anwendungen, Treiber usw. sollen sich nicht mehr in die Quere kommen und sich gegenseitig die Pins umkonfigurieren/stehlen können. Dafür wurden Bibliotheken als Abstraktionsschicht(en) geschaffen um das zu koordinieren, wovon in LibreELEC 12 aber nur ein spezielle Auswahl vorhanden ist. Um diese Bibliotheken sinnvoll anzusprechen, wäre abseits von pinctrl das Umsetzen in python3 oder eventuell als binary in C notwendig.

    Die jetzige Skript-Variante könnte u.U. also nur eine Zwischenlösung darstellen, wer weiß das schon genau? Allerdings hat die Version mit pinctrl den Vorteil, sowohl in alten als auch aktuellen LibreELEC Version zu funktionieren - zumindest glaube ich dort auch schon pintctrl gesehen zu haben. Als Bonus ist die Option für den RPi5 mit rausgesprungen, ohne die neuen Pin-Nummer vorher herausfinden zu müssen.

  • In LibreELEC 12 funktioniert das Script für RemotePI (von MSL Digital Solutions) nicht mehr

    RobertMV,

    wenn Du mal Langeweile haben solltest, kannst Du bitte die auf pinctrl umgestellte Version auf Funktion prüfen? Die sollte dann auch auf einem RPi5 funktionieren. Außer ich habe noch einen Bug versenkt. ;)

  • Kurz Ton weg, wenn TV aus-/angeschaltet wird

    Ja, es kann passieren, dass CEC komisches Verhalten hervorruft. Allerdings ist dabei nicht immer die Komponente die vermeintlich herumzickt auch der Auslöser ! Die Geräte kommunizieren untereinander, ein Art "Netzwerk". Das Bildausgabegerät Fernseher bildet da die Spitze der Hierachie. Die Daten dafür werden auf den HDMI-Kabeln mit übertragen. Ist z.B. die Software im Fernseher fehlerhaft, kann es zu Problemen kommen, genauso wenn sehr hohe Auflösungen (4K) gefahren werden und die HDMI-Kabel nur minderwertig sind. Ab und zu "verschluckt" sich das Konstrukt auch mal. Wenn gar nichts anderes mehr zu helfen scheint, alle beteiligten Geräte mal komplett vom Strom nehmen.

    Wie sieht denn Deine Verkabelung derzeit aus?

    • RPi4 (HDMI) -> AVR (HDMI) -> TV (HDMI)
    • RPi4 (HDMI) -> TV (HDMI)
    • RPI4 (HDMI) -> TV (HDMI) -> AVR (HDMI)

  • Kurz Ton weg, wenn TV aus-/angeschaltet wird

    Zitat

    deine letzte Codierung hat es gebracht: ich konnte endlich die Hifiberry in den Audio-settings auswählen und die Musik läuft jetzt wie gewollt analog an den AVR.

    Damit auch andere ggf. den gleichen Lösungsweg benutzen. Du hast die 2 Zeilen an den Anfang der config.txt eingefügt?

    Kannst Du bitte etwas genauer angeben welche +/- Tasten Du genau meinst? Auf einer angeschlossenen Tastatur, an einem Gehäuse oder einer Fernbedienung? Wenn es die vom TV war/ist, könnte z.B. CEC vorher aktiv gewesen sein, denn da kann man festlegen die Lautstärke des AVR zu steuern. Gibt aber auch noch genügend andere Varianten.

  • Kurz Ton weg, wenn TV aus-/angeschaltet wird

    Hi,

    ein paar Sachen die beim Probieren mit den Hifiberry-Treibern zu beachten sind. Ich habe zwar selbst keinen solchen HAT, aber aus anderen Gründen die letzten Tage quergelesen.

    Die Overlays hifiberry-dacplus-pro und hifiberry-dacplus-std, hängen vom verwendete HAT ab
    Configuring Linux 4.x or higher | HiFiBerry
    und sind noch nicht im LibreELEC 11 vorhanden. Diese Overlays wurden primär zur besseren Unterstützung des Pi5 geschaffen und bedingen einen brandneuen Kernel.
    Ab LibreELEC 12 beta 2 scheinen die neuen Overlays dabei. Welche Overlays vorhanden sind, kann recht einfach mit ls /flash/overlays/hifi* geprüft werden.

    Vermutlich muss die Zeile bei Dir deshalb immernoch so lauten:

    dtoverlay=hifiberry-dacplus

    Die Zeile force_eeprom_read=0 soll verhindern, dass von dem angeschlossenen HAT (Dein Hifiberry Modul) aus dessen EEPROM das Overlay geladen wird (ja, sowas geht). Es könnte sein, diese Zeile muss unbedingt vor dem „dtoverlay=hifiberry…“ Aufruf gesetzt sein -> Reihenfolge beachten!

    Code
    force_eeprom_read=0
dtoverlay=hifiberry-dacplus

    Außerdem ist diese Vorgehensweise deprecated und es wird empfohlen stattdessen diese beiden Zeilen ganz an den Anfang der config.txt zu rücken.

    Code
    dtoverlay=
dtoverlay=hifiberry-dacplus

    Wobei diesmal die leere Zeile das Nachladen aus dem EEPROM verhindern soll.


    Was das Aussetzen des Tons betrifft, würde ich auch mal getedid create in Betracht ziehen, da KODI/LibreELEC in den neuen Ausprägungen die Information aus den EDID Daten verwendet um die Audiokanäle zu bestimmen. In dem Moment wo Du den Fernseher Aus/Ein schaltest könnte zusätzlich zu CEC auch dort Bewegung drauf sein.

  • merkwürdiger 5.1 Ton

    Zitat

    Interessant ist, das jetzt der 5.1 Ton tatsächlich auch über den digital out vom TV kommt.

    Wenn Du das vorher ausschließlich mit LE 11 probiert hast, ist das für mich nachvollziehbar. Wie schon erwähnt, hatte sich da ein hässlicher Bug eingeschlichen. Der Bestand darin, dass die Kanäle vertauscht wurden. Der Datenstrom mit AC3 5.1 sollte ja auf den Kanälen unterwegs sein, die sonst für PCM 2.0 Links/Rechts zuständig sind. Wenn diese allerdings mit Hinten o. dem Center/SubWoofer vertauscht waren, kam da nichts Brauchbares am TV an, um es am Digital Out auszugeben.

  • merkwürdiger 5.1 Ton

    Wenn Dein Panasonic sowohl die eingehenden Kanäle als auch die auszugebenden Kanäle getrennt anzeigt, ist das für die Diagnose sehr hilfreich. Wenn Du da bisher schon penibel darauf geachtet hast, ist ja alles gut.
    Älteren oder einfacher gestalteten Geräten fehlt oft die Anzeige für das eingehende Signal. An dieser Stelle wird die Unterscheidung zwischen einem PCM 2.0 / AC3 2.0 Signal zu AC3 5.1 Signal schwierig. Der AVR gibt alle 3 Varianten als 5.1 auf die Lautsprecher aus, sofern er nicht explizit auf Stereo steht. Letzteres (AC3 5.1) möglichst ohne weitere akustische Eingriffe, da das Signal ja schon getrennt nach einzelnen Kanäle vorliegt.

    Mit diesem Satz irritierst Du mich etwas:

    Zitat

    der stellt auch automatisch auf Dolby ProLogic II um, wenn er das passende Signal bekommt. Bekommt er aber vom Raspi nicht.

    Die AVRs die ich bisher vor der Nase hatte, stehen per Standard auf Dolby ProLogic II oder DTS Neo:6 (beide entsprechen einem Stereo Upmix) und schalten erst davon weg wenn ein Tonformat > 2.0 am Signaleingang anliegt z.B. AC3 5.1 oder DTS (bei HDMI natürlich noch mehr).

    Die einzige technische Erklärung für mich wäre noch, der AVR fällt ganz auf den analogen Eingang zurück und verwendet dort separate Einstellungen für die Surround Programme. Wenn dort noch Stereo eingestellt ist, kann das natürlich sein. Im Umkehrschluss sollte bei Filmwiedergabe mit AC3 5.1 per Toslink bzw. S/PDIF allerdings Dolby Digital 5.1 oder was ähnliches im Display stehen, zumindest nicht mehr Dolby ProLogic II (PCM 2.0 / AC3 2.0).

  • merkwürdiger 5.1 Ton

    Die CEC-Einstellungen verstecken sich im Menü: Einstellungen -> System -> Eingabe -> Peripheriegeräte (Edit: Karsten war schneller. Ein Bild sagt manchmal mehr als tausend Worte ;))

    Für CEC benötigst Du rein von der Verkabelung her nur HDMI. Nix weiter. Natürlich sollte das Kabel auch nicht unbedingt vom Wühltisch stammen und der TV als auch das beteiligte Gerät sollten es unterstützen. Der verwendete Softwarestand spielt da unter Umständen auch mit rein.

    Die eine Buchse (sofern Digital) würde vollkommen reichen. Allerdings gibt es verschiedene Fernseherhersteller die selbst bei aktuellen Geräten dort noch Bugs versenkt haben oder absichtlich nur 2.0 Ton ausgeben - obwohl wenigstens 5.1 möglich wäre. Siehe oben Punkt Nr. 2.
    Wenn der Fernseher es doch kann (was es sehr wohl gibt), muss man es meist in Untiefen des Fernseher aktivieren. Manche TV-Nutzer wissen nix davon, weil es so gut versteckt oder nicht dokumentiert ist und geben deshalb auf.

  • merkwürdiger 5.1 Ton

    @maranzon ,

    ich glaube bei Deinem Ziel hilft nur ganz ruhiges und koordiniertes Vorgehen. Die verschiedenen Vorschläge die ich hier gelesen habe sind alle gut gemeint und haben auch schon paar mehr Details hervorgebracht. Manche Zielen aber in unterschiedliche Richtungen, wenn Du diese zur selben Zeit ausprobierst wird das nicht zum Ziel führen.

    Bestandsaufnahme:
    Raspberry Pi5 mit LE 11.0.6
    AV-Receiver Panasonic SA-XR55 hat kein HDMI nur 2x Toslink u. 2x S/PDIF coaxial
    Fernseher: Philips 37PFL7605h

    Punkt Nr. 1: Die Unterstützung des RPi5 ist in LE 11 nur rudimentär. Außerdem gab es nach 11.0.1 einen Bug bzgl. Bitstream und HDMI. Auf beides bist Du angewiesen. Ich empfehle Dir daher LE 12 beta oder ein aktuelles nightly zu verwenden. Wenn Du eine freie SD-Karte haben solltest, musst Du dafür die bisherige Konfiguration nicht zwingend opfern.

    Punkt Nr. 2: Toslink bzw. S/PDIF coaxial begrenzen die Optionen an Tonformaten die Du darüber leiten kannst. Dolby Digital (AC3), DTS (nur 5.1) als Bitstream, Stereo bzw. PCM 2.0 (PCM Multichannel ist was anderes -> dafür brauchst Du HDMI oder ein anderes proprietäres Interface) sollten möglich sein. Sonderformate True HD, DTS-HD und wie sie alle heißen sind im Regelfall tabu. Manchmal gibt es aber auch schon bei DTS Probleme. Von dieser Kombination ist abhängig, wie Du die Schalter für Passthrough im KODI als auch an Deinem Splitter setzen musst.

    Punkt Nr. 3: den Upmix von Stereo-Signalen empfehle ich Dir an allen externen Zuspielern in Deiner Verkabelung auszulassen. Wenn wirklich nötig, lass dies lieber Deinen Panasonic (Verstärker/AVR) übernehmen. Der sollte das beherrschen sobald Du Dolby ProLogic II eingestellt hast. Das stellt gleichzeitig auch sicher, dass die Dialoge weiterhin primär vom Center-Lautsprecher kommen. Für reine Musik-Wiedergabe ist es Deinem persönlichen Geschmack geschuldet, ob Du dafür temporär am AVR auf Stereo stellst oder nicht.

    Punkt Nr. 4: Der Einwand von Karsten (Bobbi2021) ist nicht verkehrt, sollte in Deinem Fall aber hoffentlich nur den Fernseher betreffen. Für CEC wird eine reine HDMI-Verbindung benötigt. Sprich nur die Strecke RPi5 -> Splitter -> TV. Toslink bzw. S/PDIF gibt sowas nicht weiter.
    Was man solchen Zusatzgeräten (Splitter usw.) leider nie ausschließen kann, dass diese den Standard verletzen und Störungen bzgl. CEC verursachen oder selbst damit nicht klarkommen. Ich habe noch nicht recherchiert, theoretisch bräuchtest Du den Splitter gar nicht, wenn der Philips auch einen digitalen Tonausgang hat. Sollte der Fernseher allerdings Fehler in der Software/Hardware haben, ist der Splitter natürlich die bessere Alternative, ohne ein ordentliches Audiointerface am RPi5 nachzurüsten. Mal abgesehen von der möglichen exotischen Kombination HDMI0 zum Fernseher, HDMI1 am Splitter zum AVR....

    Punkt Nr. 5:
    Was versuchst Du denn aktuell am RPi5 für Daten wiederzugeben? Wenn es z.B. MKV sind, ist die Wahrscheinlichkeit hoch, dort Tonformate wie DTS-HD oder True HD vorzufinden. (siehe Einschränkungen Punkt Nr. 2). An dieser Stelle macht es Sinn die Passthrough Schalter nur bei AC3 auf "An" zu setzen, die anderen "Aus".

    Punkt Nr. 6:
    Die Einstellung Audiokanäle 2.0 dürfte in Deinem konkreten Fall sogar genau richtig sein, damit KODI weiß wie groß/breit der Bitsream maximal werden darf (siehe Punkt Nr. 2) den es am HDMI ausleitet. Es kann sein, Dein Splitter kann das in Grenzen auch und macht das wenn dieser auf 5.1 steht. Da kenn ich aber die Doku noch nicht.

    Dass bei Anschluss Deines Sat Receiver, der Splitter per Toslink ein Signal ausgibt ist ein gutes Zeichen für die grundlegende Funktion des Splitters. Was damit leider noch nicht belegt ist, ob dabei ein AC3 5.1 Signal übertragen wurde oder nicht. Ich habe da leider schon die "wildesten" Konfigurationen am Sat-Receiver erlebt.

  • In LibreELEC 12 funktioniert das Script für RemotePI (von MSL Digital Solutions) nicht mehr

    Ja, ich habe es lokal bei mir mit LE12 ausprobiert, per echo die GPIO Pins umzustellen. Mit den richtigen Ziffern, kam keine Fehlermeldung mehr zurück und das GPIO Pin wurde exportiert. Es war allerdings nur eine Trockenübung, da ich diese Platine selbst nicht einsetze.

    Auch hatte ich bedenken bei den Infos die ich gefunden habe, ob ich mich ggf. um 1 verzählt habe. Wenn man die Ausgabe von gpioinfo (System-Tools Addon muss installiert sein) benutzt zum Vergleich, passt aber alles zusammen: 58 Pins + Nummerierung ab 0, wobei GPIO14 = 14 ist.

    Edit:
    erfolgreicher Probelauf auf GPIO24:
    Zustand vorher:

    GPIO24 zu Ausgang umkonfigurieren:

    Code: console
    echo "536" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio536/direction

    GPIO24 ist jetzt auf Ausgang umkonfiguriert:

    GPIO24 Pin zurück auf Input stellen und wieder freigeben:

    Code: console
    echo "in" > /sys/class/gpio/gpio536/direction
echo "536" > /sys/class/gpio/unexport

    Bitte beachten:
    Es ist vermutlich nur eine Frage der Zeit wann diese Möglichkeit die Pins zu konfigurieren aus dem Kernel endgültig rausgeschmissen wird. In Zukunft könnte die Umstellung auf "pinctrl" notwendig sein oder eine Migration zu Python3 die einzig verbleibende Variante für LE12 werden. Aktuell ist nur noch lgpio und gpiozero in den RPi-Tools enthalten. gpiozero setzt auf lgpio auf und macht es unter Umständen einfacher, aber auch langsamer. Zu allem Überfluss ist lgpio auch mit ein paar fiesen Bugs gespickt...

    PS: Von einem Nutzer im LibreELEC Forum kam gerade die Rückmeldung, dass es bei ihm nach den von mir vorgeschlagenen Änderungen wieder funktioniert.

    Quellen:

    wiringPi broken since kernel 6.5.7 · Issue #5668 · raspberrypi/linux
    Describe the bug Starting with kernel 6.5.7 applications which uses gpios are broken. Steps to reproduce the behaviour e.g. the start of an application which…
    github.com
    Trying to write to /sys/class/gpio/export – write error: Invalid argument
    I have an Intel aaeon upboard and I want to use its GPIO pins. To do that I'm trying the below code: echo 17 &gt; /sys/class/gpio/export But when I run it,…
    superuser.com

    Controlling GPIO from Linux User Space
    The Pins They Are A-Changin’

  • In LibreELEC 12 funktioniert das Script für RemotePI (von MSL Digital Solutions) nicht mehr

    RobertMV,

    besteht das Problem noch?

    Wenn ja, probiere mal die Zeilen 3/4 passend zu ändern.
    GPIOpin=527
    GPIOpin1=526

    Hintergrund: Die verwendete Schnittstelle sysfs-gpio gilt schon lange als veraltet und wurde im Kernel größer 6.5 geändert. Bisher wurde ein gpiochip0 instanziert. Wobei die 0 den Index im Speicher angibt. Bei neueren Kerneln werden diese GPIOchips dynamisch erzeugt. Vermutlich ist dies auch zwingend notwendig um z.B. den RP1 des Pi5 adressieren zu können. Hier ein Beispiel von meinem RPi4 mit LE12 beta 1.

    Code: console
    # ls -la /sys/class/gpio/
total 0
drwxr-xr-x    2 root     root             0 Feb 27 18:26 .
drwxr-xr-x   50 root     root             0 Jan  1  1970 ..
--w-------    1 root     root          4096 Apr  9 18:16 export
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip512 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip512
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip570 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip570
--w-------    1 root     root          4096 Apr  9 18:17 unexport


    Der gpiochip512 ist der mit den 58 adressierbaren GPIO Pins und entspricht dem bisherigen gpiochip0. Damit man keinen "I/O error" oder "Invalid argument" bekommt, muss man diese Zählweise verwenden: Chipnummer + GPIO Nummer

    Alt: 0 + GPIO14 = 14
    Neu: 512 + GPIO14 = 526

    Da ich nicht sicher bin, ob bei Raspberry Pis kleiner als dem RPi5 immer gpiochip512 angelegt wird, sollte man sicherheitshalber mit ls -la /sys/class/gpio/ nachschauen und ggf. neu berechnen.
    Mit cat /sys/class/gpio/gpiochip512/ngpio (Rückgabewert: 58)

    Code: console
    :~ # cat /sys/class/gpio/gpiochip512/ngpio 
58

    bzw. cat /sys/class/gpio/gpiochip512/label (Rückgabewert: pinctrl-bcm2711) lässt sich prüfen ob man den Richtigen versucht zu benutzen.

    Code: console
    :~ # cat /sys/class/gpio/gpiochip512/label 
pinctrl-bcm2711

    Auf der Basis dieser Infos könnte man die Bash Skripte vermutlich auch automatisiert suchen lassen.

    Wenn bei Dir auch der gpiochip512 angelegt wurde, sollten Deine beiden Skripte so angepasst wieder funktionieren:

    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