Hast du in den Entwickler Optionen das USB Debugging aktiviert?
Sorry, da hatte ich irgendwie Mist gelesen und nur Entwickler Optionen und nicht USB Debugging wahrgenommen. Damit machte mein voriger Kommentar dazu nur noch wenig Sinn ... Da hattest du sicherlich Recht, dass das Probleme macht mit dem Adapter.
Vielleicht einfach einen ähnlichen Stick kaufen, der keine Treiber braucht ... Kannst du ihn noch zurück geben. Bei mir funktioniert gut:
Hat auf den ersten Blick identische Spezifikation, wie dein Stick. Sogar etwas günstiger. Funktionierte bei mir auf Anhieb auf MagentaTV Stick und FireTV Stick. Anstöpseln, fertig. Da beide von mir genannten Geräte nur einen USB-Port haben, und den für die Stromversorgung benötigen, braucht man jeweils noch ein Y-Kabel. (Beim Magenta TV Stick wurde das mitgeliefert). Meine Geräte haben jeweils nur USB2 Port. Damit schafft man logischerweise keine 1 Gbit/s Geschwindigkeit. Aber kommt immerhin einigermaßen an die USB2 Geschwindigkeit ran - typischerweise kriegt man praktisch 35 MByte/s. Mit USB3-Port habe ich ihn bislang nicht getestet.
Hast du in den Entwickler Optionen das USB Debugging aktiviert?
Afaik funktionieren USB Ethernet Adapter in dem Fall nicht.
Bei mir funktioniert der Adapter auch mit aktivierten Entwickler Optionen.
Aktuell kann man die Magenta Boxen vergessen, nach zwangs update auf Android 12
kein Mehrkanalton mehr in Verbindung mit AVRs.
Kannst du das bitte etwas näher erläutern, wie das genau gemeint ist?
"kein Mehrkanalton" - bezieht sich das auf Live TV (halt IPTV von Magenta TV? Wenn ja, abhängig vom Vertrag/der Konfiguration (Magenta TV 1.0 oder 2.0 Plattform)? Oder auf Kodi? Auf alle Apps auf der Box? (z.B. Netflix, Disney+, Prime ...)
Was genau ist mit "Magenta Boxen" gemeint? Es gibt ja den Magenta TV Stick, den Magenta TV One, die Magenta TV Media Receiver und vermutlich mehr ...
Zu den Umschaltzeiten - macht mich fast bisschen traurig. Magenta TV bei mir mit dem Telekom Receiver hat wirklich exzellente Umschaltzeiten. Da ist ein "Fast channel change" (oder wie auch immer, da der Marketing Begriff ist) implementiert. Wenn ich das richtig analysiert habe, wird da neben den Multicast Streams auch noch ein Unicast-Stream übertragen, so dass man nicht auf den nächsten I-Frame des Multicast-Streams warten muss. Normale Tuner/Fernseher können da nicht mithalten
Habe selbst auch einiges investiert, um Patches zu erstellen für Kodi und ffmpeg, damit die spezifische Multicast-Technik von MagentaTV (und auch anderen Anbietern im Ausland) dort funktioniert und auch Stream-Listen für Kodi, tvh, enigma2 erstellt, wo man viele Sender ohne DRM in sehr guter Qualität sehen und auch aufnehmen kann. Ist sehr viel Ressourcen-schonender, als "normales" Streaming für lineares TV. Mein Nachbar im Mehrfamilien-Haus schaut wie ich um 20:00 Tagesschau. Die Daten werden nur ein Mal bis vors Haus übertragen. Wie easy4me nannte, wird die Technik von der Telekom wohl nicht mehr an Neukunden vertrieben. Schade.
Übrigens - auch exzellente Zapp-Zeiten haben manche Enigma-Boxen, insbesondere schon seit einiger Zeit VU+. Die dekodieren den nächsten Kanal einfach mit, und können jederzeit ohne Warten auf den nächsten I-Frame im Stream auf den nächsten Kanal schalten. Grundsätzlich können die auch ins Internet streamen (und auch Transcoding, im Vgl. zu manchen anderen Lösungen relativ energiesparend). Aber ich rate eh immer ab von sowas ... (Mit VPN vielleicht vertretbar, aber man sollte sich schon im Klaren sein, dass "unsere" Heimnetz-Medien-Technologie sehr unsicher ist. Kodi speichert Passwörter im Klartext. Enigma2 sind "root-only" Systeme - wo man auch oft Passwörter im Klartext leicht findet, etc.)
Wenn man allerdings von zu Hause selbst streamen will ins Internet wie du psychofaktory, dann wird man da immer längere Zap-Zeiten in Kauf nehmen müssen. Ich möchte fast wetten, dass da IPTV-Anbieter schneller sind, als das, was man selbst mit eigener Infrastruktur baut. Und robuster/weniger Störungs-anfällig aus vielerlei Gründen.
Deine Antwort verstehe ich so noch nicht. Ohne SSL inspection kann man ja nicht mal feststellen, wie die URL heißt. Ob das jetzt https://site.com/about oder https://site.com/dangerous_scripts heißt sieht man nicht (http://site.com/IP natürlich schon). Und du hattest im Beispiel SQL-injection (und malicious commands) genannt. Wie kann man das identifizieren, ohne SSL-Inspection?
Nach meinem Verständnis sind bei verschlüsselter Kommunikation Thread-prevention-Methoden (die über IP/Port Filterung hinausgehen) extrem begrenzt. Oder - wie gesagt - ich versteh da was falsch ...
Angriffe, die abgewehrt werden können
Thema SQL injektion
[...]
Auffällige / malious https commands auf die nextcloud wurden abgefangen
Da heute nach Außen (hoffentlich) alles verschlüsselt kommuniziert wird, benötigen Thread-Prevention-Techniken (die oberhalb OSI L3 ansetzen) nach meinem Verständnis SSL inspection bzw. ähnliche Methoden. Aller Traffic muss entschlüsselt und wieder verschlüsselt werden. Das ist wirklich möglich hier? Oder habe ich da was missverstanden?
Kann übrigens auch leicht ein Performance Bottleneck werden (Aussage nicht bezogen auf den Thread hier).
Habe dazu einen Foreneintrag bei der Telekom von vorgestern gefunden, in dem es heißt, dass 5.1 für Live-TV noch nicht unterstützt wird. Hast du da andere Erfahrungen?
Ich denke, mein Beitrag war korrekt. Allerdings kann ich es für MagentaTV 2.0 nicht selbst nachprüfen. easy4me hat das aber auch grade bestätigt. Möglicherweise war der Foreneintrag auf MagentaTV 1.0 bezogen. Das nutze ich selbst auch. Aber im LAN habe ich trotzdem 5.1 Ton. Bei zdf neo läuft gerade Zurück in die Zukunft mit 5.1 Ton. Geprüft mit ffprobe.
>ffprobe rtp://@232.0.20.236:10000?sources=87.141.215.251
[...]
Input #0, rtp, from 'rtp://@232.0.20.236:10000?sources=87.141.215.251':
Duration: N/A, start: 75545.686722, bitrate: N/A
Program 11130
Metadata:
service_name : Entertain ZDF Neo HD
service_provider: MagentaTV
Stream #0:2: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
Stream #0:3(deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:0(deu): Subtitle: dvb_teletext, 492x250
Stream #0:4: Unknown: none ([5][0][0][0] / 0x0005)
Stream #0:5(deu): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired)
Stream #0:1(mis): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s (visual impaired) (descriptions)
No Program
Stream #0:6: Data: epgSiehe Stream #0:3.
Zu den Kosten - klar, das kommt bisschen auf die konkrete Situation an und wie man rechnet. Ich meine Magenta TV kriegt man zur Zeit für 10 €. Ich rechne für mich davon ab (im Vergleich zu Kabel oder Sat) die ca. 5 €, die ich für RTL/Sat1/Pro7 und Co zahlen müsste, da ich mir das zu Hause auf dem TV nicht mehr in SD antun will (auch wenn ich die wenig sehe). Und wenn man jetzt Strom einer Digibit + eines Servers der Transoding-fähig ist gegenrechnet ... (und evt. Abschreibung).
Zur Qualität - da hat auch easy4me schon was zu geschrieben. Bei MagentaTV habe ich bei den HD-Sendern normalerweise eine Bitrate von 7 Mbit/s für die Multicast-Streams im LAN (und die sind nicht durch NALs aufgebläht). Bei den OTT-Streams etwas weniger. Die QUalität ist meines Erachtens i.d.R. etwas besser, als bei öffentlich verfügbaren IPTV Streams (die auch geringere Bitrate bieten). Aber die Qualitätsbeurteilung ohne harte Messdaten. Hatte immerhin mal Bilddetails von Standbildern verglichen. Sat ist aber oft noch bisschen besser.
Magenta TV kann auch 5.1 Ton (ich meine es gab sogar schon Broadcast mit Dolby Atmos für manche Sender). Allerdings hängt es bisschen von den Details ab. Bei meinem alten Vertrag habe ich 5.1 nur zu Hause im LAN (mit Magenta Receiver oder auch mit Kodi mit den sogenannten Multicast Streams).
Außerhalb des Heimnetzes habe ich nur Stereo - stört mich da persönlich nicht, da ich da eh Handy, Tablet oder Notebook nutze - da hilft mir die 5.1 Spur nix. Neues Magenta TV 2 kann 5.1 überall.
WIr hatten hier schon öfters ähnliche Diskussionen. War nicht deine Frage @psychofactory - aber da es nun doch diskutiert wird: IPTV könnte für deinen Usecase schon Vorteile haben. Insbesondere können Kosten für Stromverbrauch und Abschreibung von IT-Infrastruktur für das eigene Streamen leicht die Kosten eines IPTV-Vertrages überschreiten. Und damit muss man sich keine Sorgen machen bzgl. Upload-Bandbreite, Transcoding, ... Aber, da du Aufnahmen erwähntest - das kann komplizierter werden. Wobei ich da den Sinn dahinter noch nicht sehe.
Ok, kann ich jetzt nachvollziehen. Mit den bekannten HLS von Das Erste oder den ZDF Sendern habe ich überhaupt Probleme, die Untertitel zu erfassen. Ich meine, das war früher anders ... Mit den Magenta TV Multicast Streams dauert es in der Tat doppelt so lange, bis Bild erscheint für
c:\bin\ffmpeg.exe -i "rtp://@232.0.20.236:10000?sources=87.141.215.251" -map 0 -c copy -copy_unknown -f mpegts pipe:1 | "C:\Program Files\VideoLAN\VLC\vlc" -
im Vergleich zu
c:\bin\ffmpeg.exe -i "rtp://@232.0.20.236:10000?sources=87.141.215.251" -vcodec copy -acodec copy -f mpegts pipe:1 | "C:\Program Files\VideoLAN\VLC\vlc" -
Das soll jetzt nicht die optimalen Parameter für ffmpeg zeigen. Beim ersten Befehl funktionieren Untertitel, beim zweiten nicht (beides erwartungsgemäß).
Wobei, wenn man Untertitel will oder braucht (man hört nicht oder schlecht) nimmt man sicherlich gerne die zusätzliche Verzögerung in Kauf im Vergleich zu gar nix verstehen.
Vielleicht liegt es daran, dass viele Filmpassagen keine Untertitel haben, und ffmpeg warten muss, bis es den UT-Stream richtig analysiert? Ich bleib da mal dran. Möglicherweise gibt es für da noch Parameter, der hilft ... Habe auch ne ganze Menge an ffmpeg-Versionen. Probiere mal paar aus.
Datenbank ist bereits ausgelagert, da die 12GB internen Speichers bei weitem nicht mehr ausreichen.
Sicher, das du das nicht falsch interpretierst? Ich habe auch große Filmsammlung. Kodi benötigt meines Erachtens für die Datenbank wirklich nur moderat Speicherplatz. Bei der von dir genannten imposanten Menge an Medien sollte dennoch 1 GByte bei Weitem reichen.
Wo der Platzbedarf ausufert, das sind die Thumbnails, die in meinen Kodi-Installationen (und nach dem was ich hier so lese auch bei den meisten anderen) ein Vielfaches an Platz benötigen im Vergleich zu den Datenbanken.
Was mir schon aufgefallen ist - seit vielleicht 2 Jahren hat sich auf meinen Playern Kodi Scraping - gerade wenn eigentlich wenig oder nix Neues da ist, extrem verlangsamt hat. Da geht es erst sehr schnell, dann hängt er oft Minuten-lang bei 88%. Im Debug-Log ist nix zu sehen. Selbst Missing Movies Addon ist auf den meisten Geräten sehr viel langsamer geworden. Unter Windows blieb alles schnell (und CPU kann nach meiner Beobachtung von AUslastungswerten kaum der Hauptgrund sein). Erst dachte ich, das lag an der Umstellung auf den Python-Scraper. Aber die Beobachtung bei Missing Movies würde das nicht erklären.
Zu deiner Beobachtung der Verlangsamung der Datenbanken. Der "Gag" von Datenbanken ist eigentlich, dass Zugriffszeit relativ unabhängig von der Größe ist. Doppelt so groß bedeutet keinesfalls doppelte Zugriffszeit. Im Idealfall ist die Zugriffszeit praktisch kaum erhöht (bei vernünftigem Datenbank-Design mit Indizes etc.) Aber klar, eine Aktion wie alle Filme auflisten - da darf man bei doppelter Größe schon doppelte Zeit erwarten. Aber halt nicht, die sagen wir 20 Filme, die man auf eine Display-Seite sieht, aufzulisten.
easy4me, meinst du das spezifisch für telerising/die dort verwendeten Backends, dass ffmpeg ewig zum Laden der Untertitel braucht? Bzw. weißt du, unter welchen Umständen das passiert?
Die Frage, weil ich das bislang nicht bemerkt hatte. Normalerweise nutze ich ffmpeg ... -map 0 ..., was alle Untertitel, Teletext, etc. mitnimmt. Allerdings schon länger nicht mehr mit Live-TV direkt sehen probiert sondern primär bei Aufnahme des Streams.
Zum Thema Teilen der Thumbnails, siehe auch RE: Wie erreiche ich 24p-Wiedergabe mit TV, AV-Receiver, FireTV 4K Max (Gen.2) und KODI 21? und ff. Persönlich sehe ich kein grundsätzliches Problem nach Analyse des Quelltext. Aber selbst Team-Kodi Mitglieder scheinen das nicht alle gleich zu sehen.
Ein Argument, was ich fand, ist dass die verwendeten Thumbnails auch vom Gerät abhängen können (sagen wir mit 4k Bildschirm anders als mit altem VGA-Bildschirm, wo kleinere Auflösung reiche). Aber dann wäre nach meinem Verständnis das ganze Konzept kaputt. Mein Notebook nutzt mal das eigene Display, mal einen externen Monitor, mal den Fernseher mit wieder anderer Auflösung. Und, nach meinem Quelltext-Verständnis würde es eh trotzdem noch klappen. Wahrscheinlichkeit von Hash-Kollisionen steigt. Aber das ist kein neues prinzipielles Problem. Das Problem ist eh schon da bei ungeteiltem Thumbnail-Ordner Ordner.
In meiner Maria DB finde ich 3a72dfa4.jpg oder den Netzwerkpfad aber nicht. Ich würde hier erwarten, dass
in der DB hier eindeutige Einträge zu finden sind - denn woher soll der Kodi Client sonst wissen wo das Thumbnail liegt!?
Ich kenne die interne Struktur der DBs in Kodi nicht sehr gut. Allerdings weiß ich, dass Kodi für die URLs der Thumbnail-Quelle einen Hash-Wert generiert. Ich nehme an, die Quell-URL steht in der DB. Daraus wird ein 32-bit Hash Wert generiert (Kodi nutzt CRC32). Den kann man jederzeit sehr schnell aus der URL berechnen. Dieser 32-Bit Wert wird Hexadezimal dargestellt (also mit Ziffern 0-9 und Buchstaben a-f. Dein Beispiel scheint paar Vertipper zu enthalten - daher erfinde ich ein neues Beispiel. Bei mir hasht die URL zum "Ganz oder Gar nicht" Cover zu 7e8ee14a. Der Name des Thumbnails heißt dann 7e8ee14a.jpg. Abgespeichert wird er in einem Ordner "7" (das erste Zeichen des Hashwertes) - also irgendwo in Kodi-Verzeichnis/userdata/Thumbnails/7/7e8ee14a.jpg.
Die Erklärung ist sehr verkürzt und erfordert bisschen Kenntnisse (von nicht total ganz alltäglichen) IT-Begrifflichkeiten und Konzepten.
Wenn es von Hand geht, mit der Liste aber nicht, dann deutet das möglicherweise an, dass du die Anzahl der parallel zu bearbeitenden Kanäle unter TVH nicht beschränkt hast. Die Leute hier, die TVH aktiv nutzen, werden dir leicht die genaue Option zeigen können. Sonst geht das Erstellen der Muxe/Services schief, da TVH viele/alle Sender gleichzeitig scannt.
@DaVu, du hast aber schon gesehen, dass ich Log verlinkt habe? Zwar nicht vom FireTV Stick wegen beschriebenen Problematik mit dem Log dort sondern von Magenta TV Stick. Der zeigte aber sonst praktisch identisches Verhalten und sehr ähnliche Übertragungsraten wie der FireTV Stick. Deine Neugier kannst du dort stillen ...
te36, ja, da stimme ich dir zu. OT: Auch hier an der Uni hatten wir Anfang der 90er NFS genutzt, inkl. von der Client-Seite MS-DOS (mit - ich meine - PC-NFS?). Von Server Seite Dec Ultrix oder Server von Sun. Ich meine aber, wir hatten in unserem Koaxial-Kabel-Bus-Netz (10 Mbit/s) jeweils problemlos ca. 1 MByte/s erreicht (wenn der Bus korrekt terminiert war ...), auch auf schwächeren PCs, ohne viel optimieren zu müssen. Viel mehr kann man nicht erwarten. Klar, das ging auch nur, wenn ein Client aktiv Daten forderte. Jetzt wo du es sagst erinnere ich mich allerdings auch an rsize/wsize. Meine aber, da gingen überall die gleichen Standard-Parameter.
xProxyRed, hast du denn ein einigermaßen aktuelles TVH auf deinem Unraid Server laufen? Ich meine die offizielle Nicht-Beta-Version konnte noch kein rtp oder zumindest noch kein rtp mit sogenanntem "source specific multicast" - die Übertragungs-Technik die Magenta TV Streams nutzen. Die von dir gezeigte Fehlermeldung könnte andeuten, dass da alte Version von TVH genutzt wurde. Leider kann ich es im Moment nicht nachvollziehen, da ich keine gepflegte Version von TVH mehr am Laufen habe (da kein Bedarf mehr).
Du scheinst nicht die Liste aus Post #1 zu nutzen?
Du könntest noch versuchen, ob es mit cvlc (die Kommandozeilen-Version von vlc ohne GUI) klappt. Damit kann man das Magenta TV Programm aufnehmen. Musst dich bisschen einlesen, wie man das benutzt. Damit könntest du ausschließen, dass der Unraid-Server per FW o.ä. die Quellen blockiert.
Oder mit ffmpeg (falls aktuell genug, auch hier gilt ältere Versionen implementieren das rtp-Protokoll mit SSM nicht korrekt.)
ffmpeg.exe" -i "rtp://@232.0.10.146:10000?sources=87.141.215.251" -map 0 -c copy -copy_unknown -t 60 AufnahmeSat160Sekunden.ts
Der Befehl, ggf. modifiziert mit Pfad zu ffmepg, sollte ausgeführt in einem Verzeichnis mit Schreibrecht, 60 s vom aktuellen Sat1 Programm aufnehmen. Bitte bachten, dass ffmpeg da eine etwas andere Konvention für die SSM URL nutzt.
boboc, deine Erkenntnisse decken sich sehr genau mit meinen - allerdings konntest du auch noch Daten zu dem SMB-Chunksize-Patch beitragen.
Ich hatte mir auch einen neuen USB2LAN Adapter gekauft (meinen alten konnte ich nicht mehr zum Laufen kriegen). Der scheint sowohl auf dem FireTV-Stick als auch auf dem MagentaTV Stick gut zu funktionieren:
USB Type-C auf Ethernet Adapter, USB 3.0 Hub mit 1000 Mbit/s Gigabit RJ45 LAN Netzwerkadapter, USB-C auf Ethernet Adapter mit 3 USB 3.0 Anschlüssen für MacBook XPS Surface Pro Linux Chromebook usw: Amazon.de: Computer & Zubehör [Anzeige] Anders als der offizielle Amazon-Adapter, schafft dieser > 100 Mbit/s (allerdings nicht Gbit, da das die USB2 Schnittstelle nicht hergibt).
Hast du auch einen WIndows-PC? Siehst du mit neuem Kodi dort auch Wifi-Verbesserung?
Ich fasse mal paar Erkenntnisse zusammen:
- Kodi zeigt im WLAN sehr schlechte Performance bei smb-Zugriff auf vielen Geräten (einzige Ausnahme bei mir, Sony TV einigermaßen ok)
- aktueller Patch scheint in Kodi 21 zu helfen, aber nicht auf allen Geräten.
- auch NFSv3 (bei mir) deutlich schlechtere Performance als erwartet, aber besser als smb
- LAN (auch über USB-Adapter) bringt erwartete gute Performance
- ftp und webdav auch über WLAN gute Performance
- Auch bei DLAN schlechtere Performance mit smb, als zu erwarten
- Bei genügsamen Medien (z.B. alle Aufnahmen vom Fernsehen oder was Streaming-Anbieter normalerweise liefern, sagen wir unter ca. 30 Mbit/s) gibt es keine Probleme
- Kodi Cache Einstellungen spielen bei *dieser* Problematik keine Rolle - zumindest scheint keine Verbesserung möglich, eher Verschlechterung (ich sage mal, von meinem Verständnis erwartungsgemäß).
catshome - schön, dass du da auch objektive Daten beigesteuert hast.
Alles für mich keine überraschende Ergebnisse, denn wir wissen ja wofür diese Sticks und Cubes auf den Markt gebracht wurden, nämlich für online Content, und dieser wird einwandfrei wiedergegeben, da dieser deutlich unter den Bitraten der o.g. Testfiles liegt.
Hier stimme ich allerdings nicht überein. Die HW könnte es locker. Wenn Kodi smb 6*langsamer kopiert als X-Plore, geht was schief. Und auch unter Windows ist die Kodi Performance mit WLAN sehr bescheiden (im Vgl. zu dem was beispielsweise WIndows Explorer macht) boboc hat da ja auch schon einen github Fix gezeigt. Wobei auch der noch nicht alles sein wird. Siehe meine Messergebnisse zu nfs, wo es zwar doppelt so schnell geht unter Kodi, aber doch noch viel langsamer als X-Plore oder Kodi unter ftp. Habe auch noch Mal mit USB2LAN Stick getestet. Da läuft die 60 Mbit/s Variante problemlos. Kodi scheint irgendwie unter WLAN (und DLAN beim TE) schlechter zu performen als unter LAN - insbesondere auch im Vgl. zu anderen Apps auf gleicher HW.
Ich will keine Diplom-Arbeit draus machen. Aber Cache-Einstellungen machen hier keinen Unterschied, eher Tendenz zu mehr Cache -> schlechter, höchstens gleich gut. Das deckt sich mit meiner Erwartung. Habe das aber durch Messdaten bestätigt. Oft gibt es vielleicht die Erwartungshaltung "viel (Cache) hilft viel". Da kann man bei subjektiver Einschätzung ("bisschen weniger Ruckeln") leicht mal verschätzen und self fullfilling prophecy kann leicht eintreten.
te36, locha - für mich ist es nicht plausibel, dass es an Kleinigkeiten liegt wie TCP vs. UTP. Habe da viele Tests hinter mir. Damit mag man mal 10% hin oder her rausholen. Aber wenn man Faktor 3 hier sieht von Kodi Datei-Manager mit NFS (v3) gegen X-Plore - dann komme ich zum Schluss, dass es nicht an was Kleinem liegt. Auch die Erfahrung aus anderen Situationen. Hochoptimiertes (kommerzielles) Produdukt mit Jumbo-Frames und Tod und Teufel holt vielleicht 99% der möglichen Datenrate raus, normales Produkt holt 95% raus. Hier fehlen Faktoren. (Argumentation für Kopieren/Zugreifen auf große einzelne Files, wie hier. Wenn es um Tausende Benutzer geht, die alle auf NAS zugreifen mit Mix an großen und kleine Files - da laufen nach meiner Erfahrung manche Produkte einfach viel besser, als andere.)
Auch von mir - Einen guten Rutsch allerseits!
Meine Vermutung:
Der Cache hat keine Auswirkung auf Dateioperationen oder anders ausgedrückt...der Cache findet nur beim Playback Anwendung.
Ja, das vermute ich auch. Dennoch belegen meines Erachtens die Zahlen, dass Kodi (zumindest hier und vermutlich auch beim Thread-Ersteller) einfach nicht in der Lage ist Daten schnell genug zu übertragen (und den Cache zu füllen oder von mir aus ohne Cache die Daten im Filesystem zu speichern). Schaut euch die Zahlen an - das sind katastrophale Daten-Übertragungsraten, verglichen mit einem Datei-Explorer außerhalb von Kodi, der 6 Mal (!) so schnell war.
DayOne, die Testdaten haben konstante Bitrate. Ich verstehe variable Bitraten, aber deine Argumentation passt hier nicht.
Ich wollte hier bisschen mitdiskutieren - kommen jetzt aber zu viele Posts, um mitzuhalten.
Ich sehe es so: Wie Fritsch im Kodi-Forum schrieb ist dem Kodi-Team offenbar bewusst, dass Kodi ein großes Problem hat bei Cache (und vielleicht schloss er sogar Datenübertragung unter halt nicht perfektem GBit/s Ethernet ein). Da muss man nix mehr beweisen. Will man das lösen, dann erfordert das meines Erachtens jemanden mit Zeit, Skill, Verständnis für Kodi Quelltext. Vielleicht auch mal vergleichen was VLC oder von mir aus sogar ein File-Explorer anders macht. Das soll nicht wie eine Forderung klingen - mir ist schon klar, dass da Freiwillige am Werk sind.
Möchte nicht ausschließen, dass (zusätzlich) noch was Spezielles gibt auf meinen Systemen (und denen des TE). @DaVu, du hattest nach Log gefragt. Für den neuen FireTV leider nicht ganz einfach. Mit adb oder externem File-Explorer komme ich da nicht mehr ran. Kodi Dateiexplorer geht auch nicht (oder ich mache es falsch). Ich komme zwar ins Profil-Verzeichnis (hier /sdcard/Android/data/http://org.xbmc.kodi/files/.kodi/userdata), aber da komme ich nicht hoch. Klick auf die ".." bringt nix. Und von oben herab komme ich auch nicht rein, da man in neuem Android-TV /sdcard/Android/data nicht mehr lesen kann. Kodi kann das sicherlich lesen, sehe aber keine Möglichkeit da hin zu navigieren. Vielleicht ginge log-uploader, aber das habe ich noch nicht probiert ... (sondern mich lieber erneut darüber geärgert, dass Kodi uralte Unix-Konventionen verwendet, und wichtige Files, die User oft ändern müssen oder was holen in .Verzeichnissen speichert, die z.B. mit typischen Android-Versionen mitgelieferte Dateimanager von vorne herein gar nicht anzeigen und dazu auch keine Option bieten)
Habe Log erstellt auf MagentaTV Stick, mit 55 Mbit/s Testfile (der externe File-Explorer schaffte da 21 MByte/s = 168 Mbit/s über smb - da sollte genügend Puffer sein ...). Ruckelt, puffert nach, nicht immer ganz identisch. Cache verfünffacht von Default. hastebin - koritijiri (kodi.tv)
Übrigens sieht es interessanterweise auf meinem SonyTV besser aus. Habe dazu extra Kodi installiert (sah ursprünglich keinen Bedarf) und Mal das LAN-Kabel gezogen und im WLAN getestet. Da funktionierte die 60 MBit/s Testdatei einwandfrei (leere [definition='2','1']advancedsettings[/definition])
DayOne, ich hatte das vorher schon gesagt - ist für mich nicht plausibel, dass da Cache helfen kann. (Auf verschiedenen Gründen, aber da wird es schnell kompliziert in der Argumentation).
Dennoch, einen Fall nachgetestet. Cache verfünffacht von Default. Siehe das Ergebnis:
| Hardware | Software | Protokoll | Kopier-Test | Testvideo | |||
| MByte/s | 60 Mbit/s | 200 Mbit/s | 400 Mbit/s | 30 Mbit/s | |||
| FireTV 4k Max 2nd Gen | Kodi | smb3 | 5,1 | ruckelt | ok | ||
| Cache vergrößert | smb3 | 4,7 | ruckelt | ruckelt | |||
Schlechter als vorher. Aber, ich sag mal, kann auch Zufalls-Schwankung sein. Nur, ich hatte auch schon vor Jahren solche Tests gemacht - nicht ein Mal Verbesserung durch "Cache-Optimierung" objektiv bestätigen können. Wenn es mein technisches Verständnis sagt, die Messungen sagen es, dann wird schon was dran sein 
(Habe durchaus Jahrzehnte professionelle Erfahrung im Programmieren und Durchführen von Lasttests und Performance-Analysen).
Aber klar, mag sein, dass ich mich da wo täusche. Ernsthaft - mache doch eine ähnliche Messreihe (z.B. mit den Jellyfin Tesfiles, oder halt mit welchen, mit denen auch andere die Situation nachstellen können). Wenn du andere Ergebnisse erhältst kann man das im Detail vergleichen. Da wird man schon einen Schluss draus ziehen können.
Das waren übrigens die Zeilen, die ich in [definition='2','1']advancedsettings[/definition] hinzugefügt habe (und ich hatte früher schon viele andere Kombinationen getestet):
<cache>
<memorysize>104857600</memorysize>
<buffermode>4</buffermode>
<readfactor>10</readfactor>
</cache>Bei dem 30 Mbit/s Testfile, das unter diesen Bedingungen geruckelt hat bedeuten die 100 MiByte Cache übrigens, dass das ganze Test-Video-File in den Cache passt. Da kommt wohl noch hinzu, dass Kodi den Cache da nicht optimal einsetzt.