Wiedergabe von CIFS- / SMB-Freigaben mit geringer Bandbreite stabil halten bzw. cachen

    Hallo zusammen,

    wie haben in der Familie einen zentralen Filestorage an einer DSL-Leitung. Über VPN können mehrere Familienmitglieder auf diesen Filestorage zugreifen und Medien wiedergeben. Die Freigabe erfolgt über SMB/CIFS.

    Generell funktioniert es schon ganz gut, mit KODI die Medieninhalte die auf diesem share liegen über DSL/VPN wiederzugeben. Richtig Stabilität kommt in die Sache rein, wenn man den Wiedergabepuffer in Kodi hoch setzt, um kurzzeitige Latenzen oder Paketverluste mit Retransmit auszugleichen. Problematisch wird es aber trotzdem, wenn die DSL-Leitung an der dieser Filestorage dran hängt über längere Zeit ausgelastet ist und einfach keine Bandbreite zur Verfügung steht um die notwendige Bitrate durch zu bekommen.

    Netflix und Co haben in Ihrer Software entsprechende Mechanismen eingebaut um die Videos nicht nur Milisekunden bis wenige Sekunden flüchtig im Ram zu puffern, sondern da wird wohl ggf. auch ein lokaler Cache aufgebaut, der je nach Gerät auch persistent und offline weiter funktioniert.
    Bei Netflix und Co. spielen bei knapper Bandbreite sicher noch Mechanismen rein, die dem Streamingserver sagen, dass die Bitrate bei Bandbreitenknappheit dynamisch etwas runter genommen werden soll oder ähnliches, was ein einfacher SMB-Share natürlich nicht leisten kann. Dafür bräuchte man dann sicher nen Plex oder ähnliches. Darauf würden wir aber gerne verzichten.

    Gibts irgendwelche Mechanisment, Plugins oder ähnliches, wie man mit Kodi, ähnlich wie bei Netflix und Co. sich Dateiinhalte die man gestartet hat oder als "will ich in kürze angucken" markiert hat in einen lokalen Cache laden kann, damit man bei Bandbreiten oder Verbindungsproblemen trotzdem noch weiter gucken kann?

    Wir würden halt gerne vermeiden, dass man sich Inhalte "von Hand" auf die Endgeräte kopieren muss um sie bei Bedarf verfügbar zu haben.

    Vielen Dank für eure Antowrten.

    Was Netflix vor allem bei geringer Bandbreite macht ist die Bitrate runter drehen. Also die Qualität verringern. In den Puffer laden sie alle. Nur gibt es immer noch Anschlüsse wo der Puffer schneller leer läuft als er gefüllt werden kann. Dann geht's nur noch über die Qualität.

    Das was du also möchtest ist "Transcoding on the fly". Soweit ich weiß ist das mit Plex möglich. Das würde aber auch vom Server entsprechende Hardware voraussetzen. Man muss sich halt vorstellen, dass mehrere User gleichzeitig auf den Server zugreifen. Dann muss der Server auch noch wissen welchen Stream er trannscodieren muss und wenn es mehrere sind, dann geht das nur über Rechenleistung. Das heißt...das Ding braucht Dampf.

    Kodi selbst kann das nicht und mir ist auch kein Addon bekannt welches das kann. Für Kodi gibt es auch ein Plex-Addon. Das wiederum würde aber einen Plex-Server voraussetzen.

    Aber vielleicht hat noch jemand eine andere Idee

    Alternativ kannst du dir auch einen Cloud-Storage kaufen. Kostet bei Herzberg nicht so viel. Die Daten kannst du dann verschlüsselt ablegen und jeder der drauf zugreift kann die Daten halt entschlüsseln.
    Dafür gibt es verschiedenste Mechanismen.

    Vorteil ist, dass du dich nicht mehr ums VPN und/oder die Bandbreite kümmern müsstest.

    Die Leitung wird zwar auch begrenzt sein, aber ich könnte mir vorstellen, dass der Hetzner Upload vielleicht höher ist als der bei dem das NAS steht ;)

    Was Du suchst, ist bitraten-adaptives Streaming. Das funktioniert bei den gängigen Streamingformaten wie HLS, HDS und MPEG-DASH. Dazu werden mehrere Streams (oft mit unterschiedlicher Bitrate und/oder Bildgröße) parallel bereitgestellt und in sogenannte Chunks (Teilstücke) von ca. 3-7 Sek. "zerhackt" und per Webserver ausgeliefert. Je nach Netzwerkbandbreite wird immer der Chunk mit der besten Qualität ausgeliefert. Ist die Auslastung zu hoch, wird auf eine niedrigere Bandbreite geschalten und umgedreht.

    Kommerzielle Server sind Wowza und Adobe Media Server, open Source ist z.B. der Nginx mit RTMP-Modul. Letzteren verwenden wir an der Uni zum adaptiven Streaming unserer TV-Kanäle.

    https://www.wowza.com/wp-content/upl…g-Graphic-1.png
    Den Beitrag dazu: https://www.wowza.com/blog/adaptive-bitrate-streaming

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

    Leider keine Erfahrung mit dem Transcoding in e.g. Plex, ist aber sicherlich mal zumindestens eine sehr interessante Spielerei. Und koennte auch funkionieren ;)

    Wegen der Performance der CPU musst du natuerlich gucken, wie gut das geht. Wieviel DSL Bandbreite hast Du ueberhaupt ? Upstream ist da ja nie soo hoch, odr ?

    Wegen mehrer Benutzer gleichzeitig wuerde ich mir beim Transcoding keine Sorgen machen. Sagen wir Du hast 10 Mbps upstream. Ob da jetzt ein Stream auf 10 Mbps transcodiert wird, oder 3 streams auf je 3.3 Mbps, das sollte ungefaehr auf denselben CPU Bedarf gehen. Aber das ist mal grob geschaetzt und schliesst ein, das das decodieren relativ gesehen nix kostet - was aber nur dann wahr ist, wenn das auch mit HW-beschleunigt wird. Was Plex wohl kann.

    Das "pre-staging", also Kodi sagen, das er was vom Fileserver vorher runterladen sollte waere wirklich ein klasse plugin. Ich mach das halt wenn ich im Urlaub/Hotel bin immer haendisch uebre CLI, e.g.: rsync der dateien vom Server auf die lokale Platte. Unkomfortabel, aber tut.

    Oder halt Streaming mit adaptiver Bitrate ;) . Was bei einem Livestream noch geht (Echtzeit-Transkodierung pro Kanal von einem HD-Stream mit 1,5Gbit/s (SDI SMPTE 292M) nach 1080p@9Mbit, 720p@4Mbit und 480p@1Mbit), braucht bei Video on Demand (VOD) richtig Rechenpower, da ja jeder Client mit einem eigenen adaptiven Bitstream versorgt werden muss. Das sind Rechnerfarmen, die zu einem CDN zusammengeschlossen werden (müssen).

    Wir senden auf 3 Kanälen, jeder Kanal hat seinen eigenen Software-Transcoder (i7/ffmpeg) als dediziertes Gerät. Die sind mit jeweils 3 Streams/Kanal (die besagten 1080/720/480) gut ausgelastet (ca 50%-70% CPU). Der Webserver hat dagegen recht wenig zu tun, da er ja nur die transkodierten Streams entgegen nimmt, diese chunkt und je nach Bandbreite an die Clients verteilt.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

    Ich hatte vor einigen Jahren (Anfang der 2010er Jahre?) schon mal mit Plex rumprobiert. Vielleicht hat sich da zwischenzeitlich einiges getan, aber damals wars dann doch so, dass man damit halt auch nicht alles bereitstellen konnte, weil das Teil auch nicht alle möglichen Mediafiles recodieren konnte. Hier mal ein Videofile was vielleicht minimal aus der Norm war, dort mal ein exotischer Mehrkanalaudiocoded und schon hat das Teil nicht mehr richtig geliefert. Mag sein, dass das heute besser ist, aber ein Plex würde halt einfach zusätzliche Computeresourcen benötigen. Das NAS läuft zwar in ner virtuellen Maschine auf nem relativ aktuellen Ryzen, aber ohne zusätzliche Grafikkarte wäre das System dann auch überfordert - und ihr wisst ja wie das aktuell mit Grafikkarten aussieht...

    Auch wenns in der Cloud mehr Bandbreite gibt, aber dahin wollen wir aus unterschiedlichen Gründen nicht. Wir haben absichtlich alle Daten in unserem Zugriff liegen und betreiben lieber unsere eigene Infrastruktur. Zumal die Datenmengen auch in der Cloud entsprechend Geld kosten würde.

    Das NAS hängt an ner 100/40er Vectoringleitung der Telekom. Eigentlich nicht so lahm, aber es gibt halt schon Inhalte in HD oder höher, die dann gleich mal 10mbit brauchen. Wenn dann zwei Leute gleichzeitig was streamen, ggf. noch gezockt wird, an der Leitung jemand was runter lädt oder ähnliches, wirds halt doch schon ab und zu mal knapp. Es kommt nicht oft vor, aber wenn, dann nervt es halt.

    Der Begriff pre-staging gefällt mir und das triffts auch echt gut. Sowas wäre einfach klasse. Nicht nur für meinen Anwendungsfall, sondern auch wenn man das Endgerät mit in Urlaub nimmt. Wenn abends das ganze Hotel/der ganze Campingplatz online ist, braucht man mit Streaming vom eigenen NAS nämlich auch nicht anfangen, egal ob es zu Hause an der freien DSL-Leitung hängt oder in der Cloud. Da wärs cool, wenn man markieren könnte, was man sich abends angucken will und Kodi würde tagsüber einfach schon mal die Medienfiles lokal cachen. Ich vermute aber mal, dass es sowas (noch) nicht gibt.

    Ich denke die Antworten sind alle gut und erklären es auch.

    Nur ein Punkt zu Netflix: Die machen es schon gut, nicht nur die adaptive Bandbreite, auch das Puffern - und ohne, gigantische Mengen RAM zu nutzen oder dass man was konfigurieren müsste und die Streams laufen auch immer schnell an (ohne zu Warten auf Puffer-Füllen(. Kürzlich habe ich beobachtet, dass Netflix keine Unterbrechung hatte, als ich den Router durchgestartet hatte (unser alter Router startete in so 60 s durch).

    Bewog mich, das auch mal mit Kodi zu probieren.

    Versteht ihr das Kodi-Puffer-Konzept? Die Erläuterungen im Wiki sind nicht ganz leicht technisch vollständig zu verstehen. Kodi läuft auch direkt an (bei mir) und Puffer füllt sich offenbar am Anfang der Wiedergabe.

    Habe mal ein Video genommen, das (in meiner Sammlung von Fernseh-Aufnahmen) relativ hohe Bitrate hat - durchschnittlich 13,8 Mbit/s. Den Wert sehe ich auch im OS-Monitoring, wenn mal steady-State erreicht ist. Nun kann man mal raten, wie lange der Film in Kodi noch laufen sollte, wenn ich das LAN-Kabel ziehe bei testweise memorysize 600 MByte. Laut Wiki: "Note: For the memory size set here, Kodi will require 3x the amount of RAM to be free." sollte damit 1,8 GByte an Speicher verbraucht werden (Quelle: HOW-TO:Modify the video cache - Official Kodi Wiki)

    Bei 1,8 GB Puffer sollte der Puffer theoretisch für gut 17 Minuten reichen. (Abzüglich von mir aus eine kleine Menge zur Verwaltung des Puffers). Rechnet man die 600 MByte, dann für 6 Minuten. Rausgekommen ist 4:30. Erst mal noch plausibel, zu den 600 MByte. Aber warum einen Netzwerkpuffer mit Faktor 3 versehen? Und jetzt kommts: laut OS-Monitoring wurde der gar nicht gebraucht. Memory-Footprint von Kodi wuchs auf gut 1 GByte an, während der Wiedergabe (nach erreichen des Steady-State der genutzten Netz-Bandbreite blieb das auch erwartungsgemäß stabil). 1 GByte passt zum Footprint ohne [definition='2','1']advancedsettings[/definition] plus gut 600 MByte. Also Fehler in der Wiki-Doku? Warum sollte auch jemand einen Ender-User-konfigurierbaren Wert erfinden namens "memorysize", den der Enduser dann erst mal für sich mit 3 multiplizieren muss? Wenn da wirklich programmintern das in 3 Bereiche aufgeteilt wird, würde man doch im Code durch 3 teilen? Ist viel schneller gecodet, als die Faktor-3 Doku im Wiki geschrieben oder mein Beitrag hier :)

    Mein kleines Experiment war unter Windows 10, Kodi 19.3. Schaue mir bei Laune auch noch Mal die Situation an unter Android mit adb shell. Geroutetes Device habe ich nicht. Dann prüfe ich auch noch Mal genauen Memory-Footprint von Netflix.

    Ohne Cache-Konfig in [definition='2','1']advancedsettings[/definition] überdauerte der Stream übrigens 19 s in Kodi, entspricht ziemlich genau 32 MiB Puffer. Passt eigentlich auch nicht wirklich gut zu den im Wiki genannten 20 MiB bzw. mit Faktor 3 dann 60 MiB. Ist aber in den meisten Fällen sicherlich genug, um sehr viele typische kurzzeitige Netzwerk-Bandbreiten-Fluktuationen auszugleichen.

    Und bitte nicht missverstehen oder mit "PR welcome" antworten. Geht mir nicht ums Kritisieren, sondern ums Verstehen.

    Vielleicht kämpfe ich mich auch Mal durch den Quelltext, um zu sehen, was da wirklich dahinter steckt.

    EDIT: Zusatzfrage: Wie verhält es sich bei Live-Streaming? Offenbar wird es da nicht sinnvoll möglich sein, einen 600 MB Puffer zu füllen. Wird da konstanter kleiner Puffer verwendet? Der mit memorysize angegebene Puffer wird da vollkommen ignoriert? (Habe hier ja auch schon bei Livestreaming-Ruckeln die Empfehlung gesehen, memorysize zu vergrößern ... Wenn ich 20:00 das Erste anknipse, will ich doch nicht um 20:05 die Tagesschau sehen, oder schlimmer noch, die Nachbarn haben schon vor 5 Minuten über das Tor gejubelt)

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    2 Mal editiert, zuletzt von buers (23. Dezember 2021 um 11:27)

    @buers

    Interessantes Thema. Kann ich auch vielleicht das ein oder andere zu sagen.

    Meinst du aber nicht, dass das vielleicht seinen eigenen Thread wert ist? Das Thema wird sehr komplex werden und geht dann vielleicht zu sehr an diesem Thema vorbei.

    Klar, gerne auch in einem neuen Thread. Wer will oder kann, darf meine Beitrag gerne verschieben. Ich kann sonst auch gerne per Copy+Paste das nochmals neu aufmachen.

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

    Könnt das gerne auslagern, aber auch hier bleiben, wie ihr wollt. Wenn, dann bitte nachfolgendes mit umziehen. Glaub auch nicht, dass das Feature gleich umgesetzt wird oder jemand noch ne bahnbrechende Lösung hat, die über Plex und Emby als Streamingserver hinaus gehen.

    Zu der Ausführung von buers würde ich dann gleich noch folgende Frage stellen wollen.

    Was passiert denn, wenn man Kodi 600MB puffert und während er aus dem Puffer abspielt ein Netzlaufwerk oder USB-Laufwerk weg bricht, dann aber wieder online ist, bevor der Puffer leer gelaufen ist?
    Ich würde vermuten, dass der Kodi dann trotzdem am Ende des Puffers erstmal stehen bleibt und nicht während des Playbacks schon weiter puffert, sobald die Quelle wieder da ist.

    Zitat von WatchDog

    Was passiert denn, wenn man Kodi 600MB puffert und während er aus dem Puffer abspielt ein Netzlaufwerk oder USB-Laufwerk weg bricht, dann aber wieder online ist, bevor der Puffer leer gelaufen ist?
    Ich würde vermuten, dass der Kodi dann trotzdem am Ende des Puffers erstmal stehen bleibt und nicht während des Playbacks schon weiter puffert, sobald die Quelle wieder da ist.

    Gute Frage, gestern bei meinem Test lief Kodi weiter. Ich hätte vermutet, der füllt halt entsprechend vorhandener Bandbreite den Puffer wieder auf, User merkt nix. Heute bei meinem Test spielte Kodi den Puffer einfach nur leer, Abspielen beendete sich, ich landete wieder im Hauptmenu. Da kann man dann sofort wieder weitermachen. Das will man eigentlich nicht erwarten. Möglicherweise abhängig von Länge der Unterbrechung. Nachdem LAN wieder da war, hat Kodi keine Daten mehr übertragen (andere Anwendungen, wie gleichzeitig geöffnetes Outlook aber schon).

    Lokale(-USB-)Platte wird übrigens nur mit buffermode 1 gepuffert. Nicht dass ich dächte, man bräuchte das ...

    Kodi 21.1, 17.6, 21.1, 16, 20.5 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 6 (Debian Linux).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden