Beiträge von HarryH

Ich habe das jetzt nur auf RPi und PC probiert. Benutzt Du eventuell eine andere Plattform o. eine spezielle Distri ? Ich finde das interessant und würde es gerne mal sehen - vor allem was da bei mir dort an Infos noch so "vorenthalten" wird. Sowas hilft ja beim debuggen.
Kannst Du bitte einen Bildausschnitt davon anhängen?

@HY,

hast Du bei Dir zusätzliche Settings in der advancedsettings.xml aktiv, dass Du bei Aufruf der Player Debug Info (STRG + Umschalt/Shift (Pfeil oben) + O) zusätzlich File Cache Internals zu Gesicht bekommst? Bei mir zeigt er nur Durchsatzinformationen wie Kb/s für Audio, Mb/s für Video usw. an. Auch die Debug Log Anzeige (Strg + Umschalt (Pfeil oben) + D) bringt nur gesamten Speicherverbrauch zu Tage, was keine Rückschlüsse auf den Maximalverbrauch des File Caches zulässt.

@HY,

Zitat

In der GUI ist es übrigens bereits der komplette Verbrauch berechnet.

wie kommst Du zu dieser Annahme? Der Default war und ist 20MiB und wird auch so in der GUI angezeigt. Da durch den Umzug in die GUI das Verhalten selbst nicht verändert wurde, ist der Faktor 3 immer noch anzunehmen.

Bei mir wird in der GUI 20MiB angezeigt, analog zu den Bildern in dem GitHub Link. Wird bei Dir stattdessen 60MiB angezeigt?

Laut Deinem Post mit Deiner advancedsettings.xml hattest Du bisher 300MiB eingestellt. Auf der von mir verlinkten KODI-Wiki-Seite wird erklärt: man muss diesen Wert mal 3 nehmen und erhält damit den ungefähren zusätzlichen RAM-Verbrauch für das Caching.

314572800 Byte / 1024 / 1024 = 300MiB * 3 -> 900MiB !

Da KODI auch auf recht kleinen Systemen zum Einsatz kommt, ist der Default bei 20MiB. Mit 3 multlpliziert ergibt das also 60MiB und sollte keine Probleme verursachen.

Deine bisherige Einstellung 300MiB verursacht ein deutlich größeren Fußabdruck von 900MiB. Auf einem System mit nur 1GiB RAM würde ich das tunlichst lassen. Auf einem System mit 4GiB oder mehr, sollte das den Betrieb von KODI nicht unbedingt stören. Sofern diese Menge überhaupt notwendig ist. Wieviel RAM hat denn ohne Caching die Shield frei?

Im Beispiel 4 auf der Wiki-Seite wird pauschal angenommen, mit folgenden Einstellungen auch die schlimmsten Konstellationen abzudecken ohne zu viel RAM für den Cache zu verbrauchen:

• 128MiB ( entspricht 384MiB Verbrauch)
• Lesefaktor 20
• Alle Dateisystem zwischenspeichern, inklusive lokaler Dateien

Nur der Vollständigkeit halber. Auch wenn die Doku leider nicht den aktuellen Umzug in die GUI widerspiegelt, ist hier dennoch der grundlegende Umgang mit den Cache-Parametern erklärt, inklusive der Beispiele 1 - 4 am Ende:

advancedsettings.xml - Official Kodi Wiki
HOW-TO:Modify the video cache - Official Kodi Wiki

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).

    <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>

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:

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

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.

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.

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.

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.

#!/bin/bash
# Created on: 2024-04-15 20:00
# Changed on: 2024-04-17 13:30
# Version: 1.2.0
#
# Changelog:
# 1.2.0 2024-04-17
# - version information added
# - migrated from deprecated usleep to sleep command
# 1.1.0 2024-04-16
# - restricted the pinctrl usage to the 40-pin header
# - use a more specific pin naming to prevent usage of the wrong pin
# 1.0.1 2024-04-15
# - pull-up/down setting added
# 1.0.0 2024-04-15
# - migrated to pinctrl
# - code comments added

PINCTRL_BIN="/usr/bin/pinctrl -p"
# this is the GPIO pin receiving the shut-down signal
GPIOpin1=GPIO14
# set GPIO14 to input
$PINCTRL_BIN set $GPIOpin1 ip pd
while true; do
    sleep 1
    # check if GPIO14 is going to high
    power=$($PINCTRL_BIN get $GPIOpin1 | awk '{ print $5 }')
    if [ "$power" = "hi" ]; then
        # change GPIO14 to output and set it to high level
        $PINCTRL_BIN set $GPIOpin1 op dh pn
        sleep 3
        poweroff
    fi
done

#!/bin/bash
# Created on: 2024-04-15 20:00
# Changed on: 2024-04-17 13:30
# Version: 1.2.0
#
# Changelog:
# 1.2.0 2024-04-17
# - version information added
# - migrated from deprecated usleep to sleep command
# 1.1.0 2024-04-16
# - restricted the pinctrl usage to the 40-pin header
# - use a more specific pin naming to prevent usage of the wrong pin
# 1.0.1 2024-04-15
# - pull-up/down setting added
# 1.0.0 2024-04-15
# - migrated to pinctrl
# - code comments added

PINCTRL_BIN="/usr/bin/pinctrl -p"

if [ "$1" != "reboot" ]; then
    GPIOpin=GPIO15
    GPIOpin1=GPIO14
    # execute shutdown sequence on pin
    # set GPIO15 to output and high level for 125ms
    $PINCTRL_BIN set $GPIOpin op dh pn
    sleep 0.125
    # change the output to low level for 200ms
    $PINCTRL_BIN set $GPIOpin dl
    sleep 0.2
    # change the output to high level for 400ms
    $PINCTRL_BIN set $GPIOpin dh
    sleep 0.4
    # change the output to low level
    $PINCTRL_BIN set $GPIOpin dl
    # set GPIO 14 high to feedback shutdown to RemotePi Board
    # because the irswitch.sh has already been terminated
    $PINCTRL_BIN set $GPIOpin1 op dh pn
    sleep 4
fi

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)

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.

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!

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.

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.

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.

Zitat von maranzon

CEC hab ich jetzt aus, war an. Vielen Dank. Beim Fernseher muss ich mal suchen ob ich dort was finde. Probiere jetzt erstmal neues Libreelec. Dachte eigentlich, das ließe sich einfach so updaten.

Kannst Du auch, die Image Datei in den .update Ordner kopieren und LibreELEC neu starten. Nur der Weg zurück ist Dir dann verbaut bzw. schwieriger.

https://wiki.libreelec.tv/support/update

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).

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.

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

Gern geschehen. Da hat sich mein Abstecher hier ins Forum doch gelohnt ...