Kodi übers Internet streamen

1. Verbindungsalternativen

1.1. SFTP (empfohlen)

Hierbei handelt es sich um SSH File Transfer Protocol, siehe
https://de.wikipedia.org/wiki/SSH_File_Transfer_Protocol
es gibt auch "Simple File Transfer Protocol" mit derselben Abkuerzung (SFTP), aber das ist irrelevant.

Wenn auf dem Fileserver OpenSSH installiert ist (was es unter Linux, Windows, Mac gibt), dann kann man darüber von einem Kodi Client aus dem Internet via SFTP auf Dateien zugreifen. Dazu muß auf dem Kodi das SFTP plugin installiert werden. Dies ist im Standard Kodi repository unter dem Ordner Virtuelle Netze. Um den Server aus dem Internet zu erreichen muß der SSH Port des Servers auf dem home router gemappt werden. Der auf dem Internet sichtbare Port muß dabei nicht der Standard-Port 22 sein weil man den Port auch beim Einrichten des Medienverzeichnisses in Kodi konfigurieren kann (anders als bei CIFS).

Unter Linux ist OpenSSH Standard. Unter Windows gibt es mehrere Alternativen. Ausprobiert wurde dies erfolgreich mit dem standard OpenSSH was bei 'cygwin' installiert wird (einer Unix Umgebung unter Windows).

1.2. VPN über Fritzbox (empfohlen, langsam, nicht fuer jeden clients)

Das in den Fritz-Boxen eingebaute IPsec VPN kann verwendet werden, um einen VPN-Tunnel zwischen einem File-Server auf der einen Seite und einem Kodi-Client auf der anderen Seite aufzubauen. Wenn der Client selbst unter Windows oder MacOS läuft, findet man auch die passenden Anleitungen bei AVM, wie man den VPN Client installieren kann. Leider ist der Durchsatz beschraenkt (siehe Durchsatzprobleme weiter unten).

Der Durchsatz, der mit Fritzbox VPN erzielbar ist liegt zwischen 10 und 20 Mbps auf Grund der langsamen CPU in derzeitigen Fritzboxen (7xx0). Dies reicht also nicht aus, um höherwertige Medien zu streamen.

Das groessere Problem bei allen VPN Loesungen ist, dass sich diese auf dem client alleine im Kodi konfigurieren lassen, sondern andere Programme benoetigen. Bei Kodi auf linux-distributionen kann es dann vorkommen, dass es keine passende client-Software gibt. IPsec z.b. wird nicht auf libreelec unterstuetzt (siehe post 5).

1.5 HTTP(s) / WebDAV (empfohlen wenn verschluesselt)

TBD

1.4 FTP / FTPS (empfohlen wenn verschluesselt)

FTP ist das aelteste noch verwendete Dateitransferprogramm im Internet. Es gibt daher viele FTP server Varianten auf allen Betriebssystemen. Die verschluesselte Variante von FTP heisst FTPS und wird von den meisten FTP servern (und auch Kodi) unterstuetzt. FTP/FTPS unterstuetzen login mit username/password oder auch anonymen, nicht-authentifizierten Zugang zum server (je nach Konfiguration). Bevor HTTP(s) im Internte der Standard war, war lange zeit anonymes FTP der Standard, um Daten im Internet frei verfuegbar zu machen.

Generell kann die nicht-verschluesselte variante von FTP NICHT fuer den Einsatz ueber das Internet empfohlen werden, weil darueber nicht nur alle transferierten Daten abgehoert werden koennen, sondern insbesondere auch der Benutzername und das Passwort, womit dann der Angreifer freien Zugriff auf den Server hat. Dieses Abhoeren kann sehr einfach passieren, wenn man seinen Client ueber einen WiFi access point im Internet betreibt, z.b. im Hotel, Konferenzen oder Geschaeften. Viele von diesen WiFi access points sind vom Betreiber schlecht gesichert.

Unter Windows 10 ist ein FTP/FTPS server in den Internet Information Services (IIS) enthalten und kann relativ leicht installiert werden (TBD). Bei einem einzelnen Test war jedoch der erzielbare Durchsatz enttauschend: SFTP/OpenSSL Durchsatz: >= 30 MByte/sec (limitiert von der Internetverbindung), IIS FTP server: < 1 MByte/sec.

1.1. SMB/CIFS über das Internet direkt (ohne VPN) (geht nicht, nur empfohlen wenn verschluesselt)

Wenn man versucht, SMB/CIFS direkt ohne VPN zu machen, dann ist das meines Wissens nach immer unverschlüsselt. Es gibt zwar verschluesselung in neuesten SMB Versionen, das ist aber nicht in Kodi supported. Unverschluesselt ist auf jeden Fall nicht zu empfehlen, wenn man das von öffentlichen Internetzugängen machen will, wie z.b. WiFi Hotspots, wo halt sehr einfach Account-Information/Passwörter mitgelesen werden können.

TBD: Die folgenden Bemerkungen wie man fehlende verschluesselungssicherheit durch Filtern ersetzen kann sind nicht CIFS spezifisch, gehoeren also woanders hin.

Wenn man das nur dediziert von einer Lokation mit fester IP-adresse machen will kann man natürlich den SMB/CIFS export auf diese IP-Adresse beschränken. Je nachdem, was man als Server verwendet, gibt es verschiedene Stellen wo man so eine Filterung konifgurieren kann. Läuft der Server unter Windows 10, kann man dies im Windows Firewall konfigurieren, unter Linux/Samba... (TBD: habe ich noch nicht genau geschaut. Samba selbst oder Linux iptables).

Um CIFS zu streamen, wenn der Server hinter einem firewall (e.g.: Internet Zugangsrouter) sitzt muß man port 445 auf diesen Server mappen. Das ist direkt CIFS über TCP. Es gibt noch ältere Ports (137 z.b.), die volles "NetBIOS" unterstützen, aber das ist unnötiger Overhead.

Das größte Problem, CIFS direkt über das Internet zu streamen kann sein, daß Internetanbieter die CIFS ports (137, 445, ...) direkt blockieren weil einige der schlimsten Viruse im Internet (z.b. WannaCry). Das Blockieren dieser Ports ist auch Teil von Sicherheitsempfehlungen ders "United States Department of Homeland Security’s National Cybersecurity and Communications Integration Center and the Computer Emergency Readiness Team". Da die CIFS Libraries, die bei Kodi verwendet werden, es nicht erlauben, CIFS über einen benutzerdefinierten, nicht-Standard-Port zu betreiben heißt dies effektiv, daß man dann CIFS native mit Kodi nicht betreiben kann wenn einer der Provider im Internet-Pfad diese Filtering vornimmt.

2. Geschwindigkeitsprobleme

Es sind immer 3 Geschwindigkeitsprobleme zu verstehen:

(1) Geschwindigkeit des Servers (Festplatte, server-software/protokoll, {verschluesselung})
(2) Geschwindigkeit/Latenz der Internetverbindung
(3) Geschwindigkeit des Clients (client-software/protokoll, {decryption})

Wenn ein VPN eingesetzt wird, dann kommt hinzu:

(1.5) VPN server geschwindigkeit (verschluesselung)
(2.5) VPN client geschwindigkeit (entschluesselung)

2.1 Typischer Geschwindigkeitsbedarf von Medien

Der netto Geschwindigkeitsbedarf eines Mediums laesst sich einfach annaehern indem man die Gesamtgroesse durch die Spieldauer teilt. Dies ergibt allerdings nur einen Durschnittswert und die meisten Medien sind heutzutage mit variabler Bitrate codiert, so dass der Spitzenwert oft doppelt so hoch sein kann wie der Durschnittswert. Zusaetzlich kann man mindestens noch 20% Overhead fuer die verwendeten Protokolle hinzurechnen um auf einen sicheren minimalen Durchsatzwert fuer die Internetverbindung zu kommen.

Bei Medien die professionell fuer Streaming codiert werden, wird zuerst versucht, eine bestimmte durchschnittliche Bitrate zu erreichen und dabei die Qualitaet zu maximieren. Die maximale Spitzenbitrate im Encodieren wird in der Zeit limitiert, dass solche Spitzen durch einen Buffer beim Empfaenger (<- 10 sekunden) kompensiert werden konnen. Bei Medien die nicht professionel von RIP-software kodiert ist, wird haeufig nur auf die Qualitaet geachtet, nicht aber auf die Vermeidung von Spitzenwerten in der Bitrate, deswegen erfodern solche Medien haeufig hoehere Bitragen von der Internetverbindung, selbst wenn die durchschnittliche Bitrate dieselbe ist wie bei einem professionel fuers streaming codierten Medium.

Einfach gesagt: man braucht immer eine schnellere Internetverbindung als man vorher ausgerechnet hat, gerade bei Medien die auf Qualitaet codiert sind.

Der (rohe) Geschwindigkeitsbedarf (ohne den oben beschriebenen Overhead) von typischen MKV Dateien, die nicht 1:1 Kopien von DVD/BD medien sind liegt typischerweise unter 10 Mbps. Der Geschwindigkeitsbedarf von BD liegt zwischen 20 und 50 Mbps. Der von UHD liegt bei bis zu 108 Mbps.

Medien die von Live-TV aufgezeichnet sind haben haeufig eine deutlich konstantere Bitrate weil sie meist ueber Kanaele gesendet werden muessen, die fixe Bitraten haben - DVB, Kabelfernsehen, Satellit. Allerdings werden haeufig alle Programme eines sogenannten Transponders zusammen codiert (maximale Summenqualitaet), so das auch dort Durchsatzspitzenbedarf auftritt. Typische Bitraten von H.264 HDTV TV Programmen liegen bei 4..12 Mbps, mit Spitzen bis zu 18 Mbps.

2.2 Begrenzte Internetgeschwindigkeit

Wenn die Internetgeschwindigkeit niedriger ist als die benoetigte Datenrate des wiederzugebenden Medium, dann gibt es im Prinzip 2 Moeglichkeiten:

(a) Medium vorab herunterladen
(b) Medium in Realzeit auf niedrigere Bitraten transcodieren

2.2.1 Transcodieren

TBD: Beschreibung / Pointer zu guten Transcoding Loesungen (Emby ?).

Probleme mit Transcodieren:

Transcodieren erfordert auf dem Server wo es laeuft zusatzliche CPU Leistung, kann evtl. aber von der GPU beschleunigt werden. Dedizierte NAS haben haeufig die langsamste CPU die den erwuenschten Festplattendurchsatz ermoeglicht, und bieten haeufig Beschleunigung nur fuer wenige standard-Verschluesselungsmechanismen an (z.b. AES). DIese NAS sind nicht gut zum transcodieren geeignet.

Transcodieren funktioniert auch nur mit Medien deren Streams auf dem server als einzelne Mediendateien vorliegen, e.g.: MKV Dateien. Es funktioniert nicht, wenn der Client einen sogenannten "Container" anfordert, z.b.: eine ISO Datei einer BD oder DVD.

Das Transcodieren ist ausserdem auch nicht fuer BD 3D MVC codierte Medien moeglich. Theoretisch moeglich, aber praktisch gibt es keinen dafuer passenden transcoder.

2.3 Einfluss der Latenz der Internetverbindung

Selbst wenn der Durchsatz zum streamen im Prinzip hoch genug ist, bedeutet dies nicht, daß es dann auch tatsächlich funktioniert. Je größer die Latenzzeit der Internetverbindung ist, desto geringer ist der faktische Durchsatz, den ein Kodi Client erreicht, weil er beim abspielen nicht ausreichend viel Daten anfordert um die Netzwerklatenz auszugleichen. In einem Beispiel erreicht ein Download von einem Server über SFTP einen Durchsatz von > 10 MByte/sec (also > 100 Mbps), aber vom Kodi client funktioniert das Streamen derselben (Blu Ray) Datei nicht zuverlässig (bei einer RTT Latenzzeit von 160 msec).

Ich dachte ich fange mal an die VPN Thematik ein wenig zu dokumentieren. Hoffentlich finde ich die zeit, kontinuierlich den ersten Post zu verbessen. Alle Hilfen willkommen.

Mein erster Dump ist gerade von ziemlich entnervenden Tests am Wochenende, weil am Ende nix geklappt hat na mal, schauen was ich noch rausfinde.

Zitat von SkyBird1980

Hm, das wär was für die FaQ - deine einzlnen Punkte würd ich noch zur besseren Lesbarkeit mit dem [b][/b] Tag dick machen.
Die Samba/Cifs Lösung übers Internet würde ich allerdings auch weglassen weil das einfach keine Alternative ist. Niemals

Jo, formattierung kommt noch.

Wegen CIFS: Gibt ja auch leute hier im Forum die finden, dass unverschluesseltes FTP ausreicht. Wie wuerdest Du versuchen, zu erklaeren, dass CIFS unsicherer ist als unverschluesseltes FTP ?

Ich fands vor allem wichtig, zu beschreiben, das CIFS eh im Internte gefiltert wird, wodurch da eigentlich niemand freiwillig versuchen sollte, das zu machen.

Ich aendere das alles gerne nach dem besten expertenwissen, aber ich wollte CIFS nicht verdammen im vergleich zu e.g.: ftp...

WannaCry ist halt der Preis des Erfolgs. Wobei ich halt nicht weiss wieviel Microsoft da wirklich unverschluesseltes SMB bei Azure angeboten hat. Wenn das wirklich massiv der Fall war, dann haetten die eigentlich Microsoft als Firma zerschlagen sollen.

Fuer mich ist der wichtigste Unterschied zwischen unverschluesselt SMB und FTP das SMB halt schoen einfach ist, so dass da jeder unerfahrene Benutzer da beliebig Verzeichnisse exportieren kann und am Ende vielleicht noch nicht mal weiss welche Verzeichnisse er exportiert hat, oder wohin oder was das sicherheitstechnisch heisst. Ist ja alles geklaut von Apple in den fruehen 90ern als es noch keine boese Welt ausserhalb des eigenen Netzes gab. ftp-service in IIS aufsetzen dagegen ist schon eine explizite Aktion wo man eher kapiert was man da macht - und es im zweifelsfall eh nicht gebacken kriegt

Habe letsencrypt noch nie selbst probiert, bloss vor ewiger zeit mal eine beschreibung des workflows gehoert. Hat sich nicht Dummuserkompatibel angehoert. Ich glaube fuer die thematik hier (client und server selbst genutzt) waeren self-signed certs mit pinning die einfachste und ausreichende Loesung. Leider ist das mit dem pinning in den Benutzerschnittstellen nicht gut verankert.

Wenn man sich nicht schert dass man von passiven Attacken ausgespaeht wird reicht ja eigentlich schon eine nonce-basierte username/password authentifizierung aus um zu vermeiden dass jemand anderes zugriff auf den server bekommt. Weiss im moment garnicht, ob/was es da an nonce-basierender authentifizuerng gibt bei den interessanten protokollen. Muss ich mir mal anschauen. Und wenn man dadrauf self-signed cert verschluesselung vom server hat brauchst schon MITM fuers ausspionieren wenn man das pinning nicht hinbekommt.

Wenn ich mich recht erinnere, dann brauchts halt fuer letsencrypt auch einen domainnamen ueber den man ein challenge/response laufen lassen kann. Das ist halt immer mehr komplexitaet. Aber ich stell das mal zurueck und frag leute die sich damit auskennen.

So ein setup mit einem Proxy ist natuerlich optimal. Als ich den neuen FTTH Anschluss mit Fritze bekommen habe, habe ich das einfach vor den existierenden Router geklemmt und damit e-voila eine DMZ bekommen, auf die ich einen neuen windows-PC geklemmt habe. Das ist jetzt die Bastelstation. zuerst mal remote desktop zugang mit einer 2FA app abgesichert, hoffe der Laden von dem die App kommt ist vertrauenswuerdig. ansonsten koennen die jetzt prima filme gucken. Sigh.

Also zu Sicherheit kann/muss ich noch einiges runterschreiben. Bin im Moment aber eher dabei zu gucken, ob ich ueberhaupt was finde womit ich BD ISO gestreamed bekomme.

Upstream habe ich 300 Mbps, und ich kann prima ueber rsync/sftp auf dem client sehen welchen durchsatz ich da hinbekomme - eigentlich immer 100 Mbps..300 Mbps. Aber im client-kodi finde ich bisher nix womit ich das effektiv hinbekomme. Gerade noch mit den [definition='2','1']advancedsettings[/definition] fuers buffering rumgebastelt, aber das bringt bisher alles nix.

Und natuerlich geht es prima mit VLC:

sftp://<username>:<password>@<domainname>:<port>/<pathname>

Bloss network buffer auf e.g.: 5 sekunden setzen, und die BD spielt ab ohne ruckeln. Sogar als ISO (braucht bissl groesseren buffer), bloss beim BD menu hats gerade ein wenig geruckelt. Und auch an andere stellen im film springen geht prima.

Irgendwie werde ich das mulmige Gefuehl nicht los, das Kodi eigentlich nur ein Medienbrowser is, aber kein faehiger media-player.

Gibts irgendwo anleiten, VLC als player in Kodi zu nehmen ? *sigh*.

Naja, mal weiterbasteln. Wenn man lange genug auf Kodi einpruegelt sollte man es hinbekommen

Irgend jemand meinte vorher im forum das smb <= 2 kann keine verschluesselung, aber smb3 kann. Waere deswegen interessant ob fritzbox mit smb3 dann verschluesselung koennte.

Warum wuerdest du FTP/SMB nicht verwenden ?

Bei meinen Messungen war halt alles was auf der Fritzbox verschluessel war (ich hatte HTTPs probiert) auf ca. 10..15 Mbps Durchsatz beschraenkt. FTP/SMB waeren schneller. Deswegen habe ich ja auch im ersten Post eigentlich for SMB/FTP gewarnet, weil man gerne wegend er Geschwindigkeit zu diesen Optionen greift.

Hast Du Durchsatzahlen fuer WebDav auf der Fritz ?

Zuletzt: was hat in deiner Meinung WebDav als Vorteil gegenueber HTTPs ?