OpenElec/Kodi - Videos ruckeln, stocken... was tun?

[cyberjonny]

Hi miteinander,

folgendes Szenario:
- Windows-Rechner mit via USB 3.0 angehängter externer HDD, auf der große Fotos und Videos in FHD liegen
- Die externe HDD ist vollverschlüsselt mit Truecrypt
- Das (entschlüsselte) TrueCrypt-Volume wird unter Windows im Netzwerk freigegeben
- Auf die Freigabe wird via Raspberry Pi 2 mit OpenElec/Kodi zugegriffen

Die Bilder und Videos werden problemlos gefunden, aber wenn Videos abgespielt werden, ruckeln/stocken diese stellenweise. Man muss dann entweder kurz pausieren und kann sie dann wieder weiterlaufen lassen oder manchmal stoppt Kodi die Videos auch selbstständig und nimmt sich einige Sekunden zum Buffern/Zwischenspeichern (Prozentanzeige am oberen Bildrand). Die Darstellung der Bilder klappt wenig überraschend problemlos.

Woran liegt das?
Das Netzwerk ist ein Kabel-Gigabit-LAN (wobei der Raspi ja ohnehin nur 100Mbit kann), daran dürfte es also nicht liegen, oder?
Liegt es an der Verschlüsselung? Kann die da irgendwas ausbremsen? Aber eigentlich liegen die Daten doch im entschlüsselten TrueCrypt-Volume bereits entschlüsselt vor, es muss doch nichts mehr "on the fly" entschlüsselt werden, oder doch?
Ist eher der Raspi, das Netzwerk oder der Windows-Rechner das Problem und warum?
Was könnte ich tun bzw. ausprobieren, um der Sache auf den Grund zu gehen und das Problem bestenfalls zu beseitigen?

Ich stehe gerade etwas auf dem Schlauch...

Danke und Gruß,
Jonny

 

[laptopheaven]

es muss doch nichts mehr "on the fly" entschlüsselt werden, oder doch?

Natürlich muss on-the-fly entschlüsselt werden....
Wenn dem nicht so wäre müsstest Du ja den doppelten Platz vorhalten und nach dem mounten warten bis alle Dateien unverschlüsselt im doppelten Datenspeicher vorliegen.

 

[Avathar]

Als erstes würde ich mal testen ob die Probleme auch dann auftreten, wenn du a) die Video-Datei lokal vom Raspi abspielst und b) von einer normalen Freigabe am Windows Rechner. Das sollte mal helfen das Problem einzugrenzen, d.h. ob es am Decodieren der Files liegt, am Netzwerk oder an der Verschlüsselung.
Wie ist denn die Netzwerk Topologie? Ich hab z.B. einen TP-Link Powerlan Adapter der immer mal wieder Probleme macht und dabei treten dann genau solche Symptome auf.

EDIT: Achja, in welcher Kodierung liegen die Files eigentlich vor? H264, H265 oder was anderes? Tritt das Problem bei allen Videos auf?

 

[cyberjonny]

Danke für eure Beiträge!

Natürlich muss on-the-fly entschlüsselt werden....
Wenn dem nicht so wäre müsstest Du ja den doppelten Platz vorhalten und nach dem mounten warten bis alle Dateien unverschlüsselt im doppelten Datenspeicher vorliegen.

Sorry, da hatte ich einen Denkfehler, du hast natürlich recht. Allerdings übernimmt die "on the fly" Entschlüsselung hier der Windows-Rechner und nicht der lahme Raspi - oder?

Als erstes würde ich mal testen ob die Probleme auch dann auftreten, wenn du a) die Video-Datei lokal vom Raspi abspielst und b) von einer normalen Freigabe am Windows Rechner. Das sollte mal helfen das Problem einzugrenzen, d.h. ob es am Decodieren der Files liegt, am Netzwerk oder an der Verschlüsselung.
Wie ist denn die Netzwerk Topologie? Ich hab z.B. einen TP-Link Powerlan Adapter der immer mal wieder Probleme macht und dabei treten dann genau solche Symptome auf.

EDIT: Achja, in welcher Kodierung liegen die Files eigentlich vor? H264, H265 oder was anderes? Tritt das Problem bei allen Videos auf?

So, ich habe mal etwas getestet:

1. Die Video-Datei ruckelt/stockt stellenweise, wenn sie übers Netzwerk von der Windows-Freigabe der verschlüsselten externen HDD abgespielt wird
2. Die Video-Datei ruckelt/stockt genauso, wenn sie übers Netzwerk von der Windows-Freigabe einer nicht-verschlüsselten externen HDD abgespielt wird
3. Die Video-Datei ruckelt/stockt nicht, wenn sie direkt am Raspi von einem USB-Stick abgespielt wird

Damit liegt das Problem wohl am Netzwerk.

Die Netzwerk-Topologie ist denkbar simpel:
Raspi 2 --- Fritzbox 7390 --- Windows-Rechner

Fritzbox und Windows-Rechner können Gigabit-LAN, der Raspi nicht.

Die Video-Datei liegt in H.264 vor.
Das Problem tritt nicht bei allen, aber bei manchen Videos auf, und innerhalb der betreffenden Videos so ziemlich reproduzierbar an den selben Stellen/Zeitpunkten.

Das alles deutet für mich auf ein Netzwerk-Problem hin - aber was für eins?
Also zumindest in der Theorie ist ja mehr als genug Bandbreite, selbst für 4K-Material, vorhanden...

Ideen?

 

[vlooe]

Du kannst mal messen wie schnell die Datei übertragen werden kann.
Dazu musst du auf der Kommandozeile des Pi folgendes ausführen:

rsync --progress /datei/auf/share /ziel/datei

Natürlich musst du die Dateinamen anpassen. Wenn auf dem Pi nicht genügent platz ist kannst du /dev/null als ziel angeben.


Ich vermute die externe HDD ist der Flaschenhals.
Wie sieht es aus wenn die Datei auf der internen Platte des Rechners liegt?

 

[Schwartz]

Ich würde noch ne ecke weiter gehen und sagen, NTFS + Linux + Samba ist keine performante Kombination. Das zieht Daten ätzend langsam von NTFS. Kannst du selber feststellen, wenn du im Rasbpi eine Datei von einer Windows-Freigabe kopierst. Verschlüsselung setzt nur noch eins obendrauf. Versuche mal ExFAT oder ein Linuxnahes Dateisystem.

 

[soundofsilence]

Das Problem ist definitiv Windows. Es gibt ne generelle Empfehlung für NFS bei der Kombi Raspi/Openelec/KODI. Hab das alles schon durchexerziert. Seit ich Linux mit NFS oder auch nur Samba nutze auf dem Fileserver gibts keine Probleme mehr.

 

[cyberjonny]

Du kannst mal messen wie schnell die Datei übertragen werden kann.
Dazu musst du auf der Kommandozeile des Pi folgendes ausführen:

rsync --progress /datei/auf/share /ziel/datei

Natürlich musst du die Dateinamen anpassen. Wenn auf dem Pi nicht genügent platz ist kannst du /dev/null als ziel angeben.


Ich vermute die externe HDD ist der Flaschenhals.
Wie sieht es aus wenn die Datei auf der internen Platte des Rechners liegt?

Wie schnell die Daten übertragen werden, habe ich noch nicht gemessen, aber ich habe die Video-Datei mal von der internen Platte (bzw. SSD, auch mit NTFS formatiert, unverschlüsselt) übers Netzwerk abgespielt - mit dem selben Resultat. Es liegt also zumindest nicht an der externen HDD und auch nicht (nur) an der Verschlüsselung.

Ich würde noch ne ecke weiter gehen und sagen, NTFS + Linux + Samba ist keine performante Kombination. Das zieht Daten ätzend langsam von NTFS. Kannst du selber feststellen, wenn du im Rasbpi eine Datei von einer Windows-Freigabe kopierst. Verschlüsselung setzt nur noch eins obendrauf. Versuche mal ExFAT oder ein Linuxnahes Dateisystem.

Das Problem ist definitiv Windows. Es gibt ne generelle Empfehlung für NFS bei der Kombi Raspi/Openelec/KODI. Hab das alles schon durchexerziert. Seit ich Linux mit NFS oder auch nur Samba nutze auf dem Fileserver gibts keine Probleme mehr.

Damit könntet ihr wohl Recht haben; NTFS + Linux + Samba scheint eine lahme Kombination zu sein. Ich werde bei Gelegenheit mal testen, wie es sich mit einer exFAT- oder ext4-formatierten HDD verhält.

Allerdings habe ich das Problem, dass die verschlüsselte HDD, auf der die Dateien liegen, sowohl unter Windows als auch unter Linux verwendbar (lesend und schreibend) sein sollte. Dafür bin ich mit NTFS bisher ganz gut gefahren. exFAT ist afaik eigentlich eher auf Wechseldatenträger mit Flash-Speicher (USB-Stick) optimiert und hat bei HDDs einige Nachteile (die ich gerade aber nicht mehr auf dem Schirm habe).

Was könnte also die Lösung sein, wenn folgende Kriterien erfüllt bzw. beibehalten werden sollen:
- externe Festplatte sollte mit TrueCrypt/VeraCrypt verschlüsselt sein
- externe Festplatte muss unter Windows und Linux voll nutzbar sein
- die Dateien auf der verschlüsselten externen Festplatte sollten bei Bedarf auf dem Raspberry Pi 2 mit OpenElec/Kodi abgespielt werden können

Das Problem ist, dass ich die HDD nicht direkt an den Raspi hängen kann, weil der an der Entschlüsselung scheitert (der Windows-Rechner macht das dank Quad mit AES-NI im Schlaf). Die HDD respektive die Dateien sollen aber verschlüsselt bleiben, die Dateien einfach unverschlüsselt auf eine HDD zu legen und diese bei Bedarf an den Raspi zu hängen, ist also keine Option. Dann bleibt wohl nur noch das Dateisystem des verschlüsselten Volumes, an dem geschraubt werden kann. Aktuell ist es wie gesagt NTFS, weil es sowohl mit Windows als auch mit Linux ganz ordentlich funktioniert. Was für Alternativen gäbe es hier? Ist exFAT wirklich eine?

Oder gibt es vielleicht noch andere potenzielle Lösungswege, die ich gerade übersehe?

Danke euch soweit!

 

[vlooe]

Bevor ich etwas umbauen würde würde ich den Flaschenhals suchen.
Irgnedwie bezweifel ich, dass NTFS schuld sein soll.

Habe eben von meinem T550(win10,ssd mit ntfs)->wlan->100mbitschwitch->htpc ohne probleme eine Datei übertragen. Übertragungsrate bei ca 8-10mbyte/s --> ca 80mbit
Für ein popliges FHD Video braucht man deutlich unter 20mbit eher so um die 5.

Ich werd mich mal direkt per gbit dranhängen und dann messen....

 

[cyberjonny]

Update auch meinerseits: Ich habe vorhin eine 2,5-SATA-HDD intern in den Windows-Rechner verbaut und mit exFAT formatiert, dann eine Video-Datei draufkopiert, diese im Netzwerk freigegeben und via Raspi/OpenElec abgespielt... Leider mit dem selben Resultat.

Also vom Ergebnis her macht es bisher keinen Unterschied, ob:
- HDD intern oder extern
- HDD oder SSD
- NTFS oder exFAT
- verschlüsselt oder unverschlüsselt

Bisher ruckelen die entsprechenden Videos immer, wenn sie über das Netzwerk gestreamt werden.
Lediglich wenn sie direkt am Raspi hängen, z.B. via USB-Stick, dann klappt die ruckelfreie Wiedergabe. Auch wenn der Stick mit NTFS formatiert ist, kein Problem.

Das spricht doch wiederum sehr für eine Netzwerk-Problematik...?

 

[vlooe]

Ohne mb/s zahlen zu sehen ist das alles spekulation :thumbsup:

Edit:
hmm auf die schnelle bekomm ich keinen test mit gbit hin...

Probier mal das. Der hatte auch das Problem, dass HD zeugs über samba ruckelt auf dem Pi
http://xbian.org/forum/thread-512.html

Ansonsten bleibts dabei: Mit Zahlen kann man besser beurteilen ob eine Änderung etwas gebracht hat

 

[soundofsilence]

Ich glaub ich hab mich falsch ausgedrückt. Nicht NTFS ist meistens das Problem sondern SMB/CIFS. Ich kann ohne Probleme eine NTFS formatierte Platte in meinen Fileserver hängen und hab keine Probleme mit Rucklern, wenn ich das Gleiche von einem Windows Rechner versuche wirds ruckelig. Aber vielleicht könntest Du mal gucken was netIO so zwischen der Windows Kiste und dem Pi ausspuckt.

 

[Avathar]

Ich würde auch, nur um ganz sicher zu gehen, mal andere Netzwerkkabel probieren oder generell eine Direktverbindung herzustellen.

Ich muss aber auch sagen, dass SMB einfach der letzte D.... ist, wobei es oft die Linux -> Sambashare Verbindung ist, die Probleme macht.
Z.B. bekomme ich beim Zugriff unter Linux Mint auf den Sambashare (Ubuntu Server) nur 2-3Mbs, unter Windows gerne mal 10-14Mb/s (über Wlan), andere Protokolle (FTP, etc) gehen unter Linux ähnlich schnell.

 

[laptopheaven]

Hast Du mal probiert die Datei an den Pi mit DLNA zu streamen ? Ein Fileprotokoll ist manchmal nur bedingt zum Streamen geeignet. Ich kenne das von meinem Handy: Wenn ich den Share mounte stockt der manchmal.Nutze ich den Dlna Dienst meiner Syonolgy funzt das wunderbar