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.

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

Einstellungen am Cache über die GUI greifen sofort.

HarryH hast Du das mit dem "ignorieren" ausprobiert ? Ich hatte das so gelesen, als ob die Einstellugen in Caching genau die GUI fuer diese advancedsettings.xml sind. Wenn nicht, dann muessen die GUI settings ja irgendwo an anderer Stelle auf XML config abgebildet werden.

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>

Ok. Danke. Solange fuer die neuen GUI settings auch dokumentiert ist, zu welchen xml settings sie mappen ist alles fein. Mal abgesehen davon das das ganze ausprobieren, wie man diese Nerd Knobs optimieren muss und wieviel die dann tatsaaechlich helfen halt viel arbeit sein kann.

Solange man kein "Netflix 4k" streaming oder andere Apps will bietet sich halt eh CoreElec als Loesung an und dann halt im schlimmsten Fall den share im OS mounten. Hatten wir mal in einem Fred erfolgreich als Loesung bei einem LE User empfohlen.

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

Zuviel ist auch nicht gut.

Hab bei mir in der GUI 128MB eingestellt, das reicht hier.

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

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

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

Wie ich zu diese Annahme komme?

Weil man das in der Debug GUI (STRG + Pfeil oben + O) sehen kann das der Cache durch 3 geteilt wird und somit knapp 47MB ergibt.

juro1971, ich empfehle, die Cache-Größe erst mal nicht zu verändern. In deinem as.xml ist eine enorme Größe (die ja unter Nexus auch noch wirkt). Hast du dadurch wirklich Vorteil? Ist aber normale Empfehlung typischer "kodi-super-tricks.net" Sites.

Wir hatten schon sehr viele Diskussionen dazu hier. Ich kann mich nicht an einen Nachweis erinnern, dass Vergrößerung half. Selbst habe ich da auch schon sorgfältig getestet und gemessen, eher das Gegenteil war der all. Es ist meines Erachtens auch nicht plausibel, dass das hilft - Default ist schon so riesig.

Hier sind dennoch viele Leute davon überzeugt, dass viel viel hilft. Messdaten geben das nicht her. Bisweilen subjektive Wahrnehmung "scheint weniger zu ruckeln". Ich denke, das ist eher typische self fullfilling prophecy. Könnte man sonst ja schon quantifizieren (z.B. durch Übertragungsrate im Dateimanager, durch gezählte Anzahl der Nachpufferungen oder durch gestoppte Laufzeit eines Videos - sagen wir Netto-Spielzeit 10 Minuten, mit großem Cache x mal nachgepuffert, nach y Minuten abgespielt).

Dev Fritsch im Kodi-Forum: "I think it [cache code] needs complete replacing at a point as the internal knowledge was lost and we see tons of issues especially in non gbit setups." https://forum.kodi.tv/showthread.php…6668#pid3166668. Vielleicht ist allerdings auch da die Erwartungshaltung zu sehr Richtung "mehr muss doch mehr helfen".

Es wurde hier 128 kB SMB chunksize erwähnt. Hier beschleunigte (gerade getestet) allerdings 1 MB signifikant. (Z.B. am anderen Ende unserer Wohnung vom Router mit Windows Notebook unter Kodi Dateimanager mit WLAN: 3,4 MB/s bei 128 kB vs. 6,4 MB/s bei 1 MB)

Die Diskussion zu Kodi-Cache erinnert mich bisschen an professionelle Messungen zu Jumbo-Frames. (Klar, das ist auf anderer Ebenen des OSI Modells). Da kann man vielleicht 10% erwarten beim Übergang von normalen Frames (ca. 1,5 kB) auf Jumbo Frames (9 kB). Man betrachte die geringen Größe, im Vergleich zu dem, was wir hier diskutieren.

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

Nein, da ist nix mehr in der as.xml bzgl. Cache aktiv