Videos ruckeln bei Bitrate > 60Mbps

Zitat von DayOne

VLC versucht immer eine gewisse Zeit zu buffern, Kodi richtet sich aber nach Datenmenge.

Was fuer eine Datenmenge, und woher soll Kodi die wissen ? Nehme Durchschnittswerte der in den letzten N sekunden gebrauchten Datenrate und denk Dir dann, das Du auch dieselbe Datenrate in den kommenden N Sekunden brauchst ? Und dann liest Du wieviel jetzt in den Cache ein ?

Sagen wir, Kodi hat zuletzt 20 Mbps Abspielrate gesehen. Wieviel Megabyte sollte Kodi da jetzt lesen wollen ?

Und wenn ich den readfactor auf 10 setze sollte Kodi ja wohl 10x soviel lesen wollen, oder ? Und das sollte dann ja doch immer reichen, wenn die Datenrate sich nicht so schnell mal selbst um einen Faktor 10 aendert. Und das tut sie sicherlich nicht bei den meisten Filmen. Zumindestens nicht gemittelt ueber sinnvolle Zeitraeume wie ein paar Sekunden.

Das erste IMHO, was gemacht werden sollte waere mal im onscreen ( 'O') output mal die cache-information anzuzeigen, damit man mal im

live abspielen sehen kann, was da passiert. Gerade das es bei so einem hohen Readfaktor immer noch nicht geht, macht wundern, das da einfach bugs drin sind.

Kodi wird immer Versuchen seinen Cache voll zu halten (Default 20MB).

Nur danach richtet sich Kodi.

undit welcher rate fuellt lodi den cache bei readfactor 1?

Zitat von buers

Habe nochmals verschiedene Konstellationen vermessen, mit ganz interessanten Ergebnissen.

Sehr schöner Test. Danke dafür. Kodi 21 bringt eine Verbesserung.

Zitat von DaVu

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

locha Kann (natuerlich>?) keine sinnvole Doku zu diesen Parametern finden. Bei NFS Version 3 z.b. kuendigt der Server zum Client sowohl eine maximal unterstuetzte blockgroesse fuer lesen und schreiben an (rtmax/wtmax), also auch eine bevorzugte (rtpref/wtpref) (siehe RFC1813). Ich wuerde mal hoffen, das die beiden Parameter die bevorzugten Groessen sind. Koennen aber auch die maximalen sein. Kannst Du nur durch ausprobieren rausfinden. Aber solange Du nicht NFS uebers Internet oder langsames WiFi verwenden willst wuerde ich einfach empfehlen, das sowohl auf server als auch auf clientseite auf 32k zu setzen.

Kann nix dazu finde, ob Kodi NFS ueber TCP kann. Befuerchte also mal nicht. Sonst koennte man wohl auch konfigurieren ob TCP oder UDP verwendet wird. Wenn Kodi TCP koennte, dann ist das mit konfigurieren von solchen blockgroessen viel weniger problematisch. Da kann man die dann eigentlich immer auf ein maximum (e.g.: 32k) setzen. Bei UDP sind die 32k dann ja ein 32k groesses UDP Paket, was ja auf kleinere IP Pakete runtergebrochen werden muss (typische Heimnetze haben nur 1.5k), und wenn dann nur eins der 22 Pakete (32k/1.5k) verloren geht, muessen alle nochmal neu gesendet werden. Bei TCP muss da immer nur das verlorengegangene neu geschickt werden.

Aka: Wuerde bei problematischen Netzbedingungen NFS immer vom OS aus mounten, wenn das OS das kann, also bei Linux und wohl auf windows (da gibts ja NFS client, allerdings sehe ich bloss das der anscheinend TCP kann, aber nicht, wie man das aufswaehlt). Aka: alles wo server und client nicht mit mindestens 100Mbps ethernet verbunden sind.

In älteren Kodi Versionen wurde viel zu kleiner Buffer für die Übertragung mit SMB verwendet. Dieser Bug ist hier dokumentiert. In Kodi v21 Omega ist das nun deutlich besser. Die Größe des Buffers kann konfiguriert werden, was die Übertragungsraten um Faktor 2-3 verbessert.

boboc : jo, danke fuer die Pointer. Ich kapiere bloss SMB nicht genug im Detail um zu wissen ob oder warum es schaden koennte, zu grosse Buffer bei SMB zu nehmen. Irgendwie bloede wenn da jetzt alle Kodi benutzer wieder einen neuen Nerd Knob ohne klare Erklaerungen optimieren muessen. Aber natuerlich besser als wenn es gar keine Moeglichkeit gibt das zu optimieren.

Zitat von boboc

In älteren Kodi Versionen wurde viel zu kleiner Buffer für die Übertragung mit SMB verwendet. Dieser Bug ist hier dokumentiert. In Kodi v21 Omega ist das nun deutlich besser. Die Größe des Buffers kann konfiguriert werden, was die Übertragungsraten um Faktor 2-3 verbessert.

Reicht hier an einen Fire TV Cube 3 trotzdem nicht aus via Samba.

Nur (S)FTP & WebDAV bringen hier die Lösung (wenn das NAS beides native nicht Supportet, einfach RClone benutzen),

Man sieht es hier im [definition='1','3']Debug[/definition] OSD ganz deutlich der Buffer füllt sich via Samba bei High Bitrate Files zu langsam, während er zB per WebDAV innerhalb weniger Sekunden voll ist und auch nie um mehr als 10% schwankt.

FTV Cube Gen.3, GBit USB LAN-Adapter, Fritzbox/NAS, Kodi aktuelles Omega Nightly-Build, SMB, Testfiles "jellyfish-120-mbps-4k-uhd-hevc-10bit" und "jellyfish-140-mbps-4k-uhd-hevc-10bit" liefen gerade beide "ruckelfrei" bei mir.

FTV Stick 4K MAX Gen.2, WLAN 5GHz, Fritzbox/NAS, Kodi aktuelles Omega Maven-Nightly-Build, SMB, Testfiles wie zuvor, liefen beide (natürlich) "nicht" mal ansatzweise ruckelfrei. Erst das Testfile "jellyfish-40-mbps-hd-hevc-10bit" konnte ohne Meldung "Quelle zu langsam" ruckelfrei wiedergegeben werden.

Die Wiedergabe auf dem diesem Stick mit dem VLC, lief bis max. mit dem Testfile "jellyfish-50-mbps-hd-hevc" ruckelfrei.

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.

Insofern vorher überlegen was man kauft, wofür wie und wo u.s.w.. Im Zweifel Geräte mit GBit-LAN anschaffen, oder wenn 120/140mbps reichen, z.B. einen FTV-Cube Gen.3 mit GBit USB LAN-Adapter.

Alternative und mein Workaround, ich recodiere alles auf eine max. Bitrate von 15.000 in 1080p HDR, und lasse meinen OLED dann skalieren...

Allen einen Guten Rutsch ins neue Jahr...

catshome - schön, dass du da auch objektive Daten beigesteuert hast.

Zitat von catshome

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!

Nachdem ich die WLAN-Verbindungsqualitäten meiner FTVs in der Fritzbox gesehen hatte,

war ich zunächst auch ordentlich frustriert, das keine Videos >50mbps per WLAN auf den FTV-Sticks ruckelfrei wiedergegeben werden konnten bzw. können. Ich dachte zunächst an eine Hardware-Schwäche, das konnte ich allerdings mit einen auf den Stick kopierten Testfile ausschließen. Weitere Tests mit angepasster adv.xml und jetzt mögliche Cache-Anpassungen, brachten auch keine annehmbaren Ergebnisse.

An der Stelle, Respekt an alle welche sich die Mühe gemacht haben, hier ihre Testergebnisse zu teilen, vielen Dank dafür.

Frohes Neues Jahr!

Das Thema "Kodi SMB performance" is auch für mich hochinteressant. Nachdem in Kodi v21 die Einstellung für SMB chunk size eingeführt wurde, konnte ich mit meinem Fire TV Stick 4K Max 1. gen Videos mit Bitrate bis 140 Mbps über WiFi abspielen. Cache-Einstellungen spielen da keine Rolle, ich habe den Cache sogar komplett abgeschaltet.

Aber nach dem Upgrade auf Fire TV Stick 4K Max 2. gen funktioniert es ganz schlecht. 60 Mbps Videos laufen nicht mehr rückenfrei. Speed test auf dem Stick zeigt 220 Mbps (meine Internet Geschwindigkeit). Kopiertest in Kodi läuft mit 6 MB/s (auf dem alten Stick bis 30 MB/s). Zuerst hoffte ich, dass mein Stick ein Hardware-Defekt hat. Aber nachdem ich diesen (zwei Mal) ausgetauscht habe, weiß ich, dass es wohl Normalfall ist.

Da ich unbedingt den neuen Stick wegen HD Audioformate wollte, habe ich zwei USB-LAN 1Gb Adapter ausprobiert. Ein davon funktioniert befriedigend und der andere sehr gut. 30 MB/s in Kopiertest in Kodi ist wieder möglich (mit dem guten Adapter). Videos mit 140 Mbps laufen nun problemlos.

Für etwas mehr Details über getestete Adapter weise ich auf meinen Post in Kodi Forum hin.

Für mich ist es auch unerklärlich wieso Kodi solche Probleme mit SMB über WiFi hat. Über LAN laufen 80 Mbps Videos mit SMB Chunk-size 16 KB rückelfrei. Über WiFi müsste ich auf dem alten Stick den SMB Chunk-size für das gleiche Video auf 256 KB setzen. Auf dem neuen Stick kann man dieses Video über WiFi gar nicht schauen. Es wird alle zwei Sekunden nachgeladen.

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

Zitat von buers

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

Mir gings ja bloss um den Punkt, das Optimierung ueber schwierig einzustellende Nerd-Knobs nur eine zweifelhafte Verbesserung darstellt. Eigentlich muss sich das halt alles automatisch an die Bedingungen anpassen.

Bei NFS hab ich das ein wenig selbst mitgemacht, als wir in Anfang der 1990'er halt in der Uni alles mit NFS gemacht haben und dann neben dem LAN auch MAN und WAN Verbindungen dazukamen - immer unterschiedliche Latenz, Durchsatz, Zuverlaessigkeit, und man dann bei jedem NFS mount abhaengig von der Netzverbindung rsize/wsize unterschiedlich einstellen musste. Bis halt TCP kam, was eben mehr selbst dynamisch adaptiert als die muckelige flow-control von NFS ueber UDP. Da musste man da im Prinzip nie mehr an Nerd Knobs rumbasteln ("im Prinzip").