ständiges Buffern bei grossen Dateien

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Her Leute,

    Folgendes. Ich habe Openelec auf meinem Pi der mittels Samba auf meinen Windows Server (2008 R2) auf Filme und Musik zugreift.
    Pi und Server sind beide mit Cat 5 an einem D-Link DIR-645 verbunden.

    Läuft auch alles wunderbar, nur ist mir aufgefallen dass der Pi bei großen filmdateien (bei mir ab 20 GB Dateigröße) ins stocken gerät.
    Der Film läuft 5 Sekunden und dann wir gebuffert, es läuft eine Sekunde, wieder buffern, dann wieder 5 Sekunden.
    Kleinere HD Filme laufen ohne Probleme, nur die Grossen machen Schwierigkeiten.

    Herr der Ringe (1080p mit DTS und 2 Tonspuren, ca. 60GB pro Film) ist nicht anschaubar. Jetzt wollt ich wissen ob es am Netzwerk liegt, oder habe ich die Grenzen des Pi damit erreicht.

    Einmal editiert, zuletzt von iGordon (11. April 2013 um 22:58)

  • Wie haste das Problem letztendlich in den Griff bekommen?
    Wäre interessant zu wissen bei mir is auch ab 20gb schluss mit Ruckelfrei.
    Der RPi zieht vom ftp ca 3mb aber net dauerhaft...

  • Und warum läuft dann beim Abspielen einer Audio-CD über USB sofort der Cache von MPlayer leer, wenn doch die Übertragungsgeschwindigkeit der USB-Ports nicht das Problem ist? Mir ein totales Rätsel!

  • der datenstream ist da einfach zu hoch. eine hdd an usb schafft da doch noch etwas mehr als über lan oder wlan. ich habe das zu laufen über NAS und muss sagen das es nur mit einer hdd am usb port besser läuft.

    nach webdurchsuche ist auch klar warum
    rasberry pi hat 100mbit lan d.h. teoretisch 12,5 mb/s (das ist ein nie ereichbarer maxwert)
    usb2 hat 400mbit d.h. bis zu 60mb/s wobei 20 - 30 mb/s normal sind

    wie zu ersehen ist mit usb doch noch etwas mehr möglich als mit lan.

    ich hatte mal zum test ein 150mbit wlan stick was max 18,75 mb/s maxwerte hat aber das war nur etwas geringfügig besser als das kabel-lan.

    also beste werte bleiben bei einer hdd direkt am usb port.

  • Das mit der Audio-CD brauchst Du nicht mehr testen!

    Ich hab die Lösung!

    Man muss statt des Paketes "mplayer" das Paket "mplayer2" installieren!

    Das enthält optimierte Libraries, Bugfixes, andere Optimierungen...

    Damit muss man beim CD-Abspielen sogar gar keine Cacheoption mehr setzen. Läuft perfekt.

    Hilft vielleicht auch bei Bufferingproblemen bei Filmen (kann's nicht ausprobieren, da ich den Raspi nur headless als Audiostation betreibe). Bei den Filmen des OP vermutlich aber nicht, da die vermutlich endgültig eine zu hohe Datenrate haben.

    Einmal editiert, zuletzt von hasenbein (5. August 2013 um 08:27)

  • Hallo,

    hier ein Vorschlag, der zumindest in meinem Fall zum Erfolg geführt hat:

    Problem/Rahmenbedingungen:

    Ich habe seit kurzem auch einen RPi und hatte ebenfalls das Problem mit dem ständigen buffern (1080p, mkv-container, h.264 codec)

    Da ich es mir nicht erklären konnte, habe ich sehr viel gelesen und Unterschiedliches probiert:
    - alternatives OS (Openelec, Raspbmc)
    - Übertakten (mitsamt dem Einbau von Kühlkörpern)

    Beides führte nicht zum Erfolg.

    Mein RPI ist per HDMI mit einem Onkyo TX SR 876 verbunden. Das Gerät ist in der Lage DTS und AC3 per Pass-Through vom RPi zu erhalten, ohne dass der RPi sich hierfür mit eigener CPU-Leistung krumm machen müsste (und damit wertvolle Ressourcen, die er für das reibungslose Streamen benötig, verschwendet).

    Die Hinweise in einem Forum, man solle sich die Codecs kaufen, halte ich für Quatsch, da nämlich h.264 gerade vom Raspberry unterstützt wird. Das konnten auch durch andere User verifiziert werden, die sich die Codecs gekauft haben und weiterhin "Stutter"-Probleme bei 1080p-Material hatten.

    Nun lass ich weiterhin, dass manche User bei einer Kabel-Lan-Verbindung absolut keine Schwierigkeiten hatten und andere wiederum Abhilfe durch die Verwendung eines WLan-Sticks erzielen konnten. Die meisten der aktuellen Wlan-Sticks schaffen die 150MBit (oder gar mehr), mithin also mehr als das 100Mbit-Kabel-Lan.

    Das der Lan-Port im RPi wohl an einen insgeamt relativ langsamen USB-Host gekoppelt ist (so hab ich es zumindest beim Lesen verstanden), existiert also sowohl für die Lan-Verbindung über Kabel als auch Wireless derselbe Flaschenhals.
    Es leuchtete mir aufgrund dessen also überhaupt nicht ein, dass der vermeintlich schnellere WLan-Dongle ein besseres Ergebnis in der Bandbreite und damit beim Streaming erzielen sollte, da er seine Daten durch denselben Flaschenhals wie auch das Kabel schiebt.

    Nun habe ich angefangen, den Fehler bzw. die Lösung des Problems in meinem Netzwerk zu suchen.

    Mein Netzwerk ist wie folgt aufgebaut:

    1. Fritzbox 7390 (1.000er LAN):
    - Port 1: Raspberry (100er LAN)
    - Port 2: weiterer D-Link-Switch (siehe unten)

    2. Weiterer D-Link Switch (1.000er Lan)
    - Port 1: PC (1.000er LAN)
    - Port 2: Windows Home Server (100er LAN) (Samba-Freigabe)

    Die Geräte sind jeweils über Cat5e-Kabel verbunden. Alles in allem also eine Infrastruktur, die grundsätzlich dazu geeignet ist, dass die Medien in 1080p ganz entspannt vom Homeserver zum RPi gestreamt werden müssten (wenn auch der Homeserver in diesem Fall auch nur mit einem 100er LAN ausgesattet ist), ohne dass es zu Aussetzern kommt.

    "Beschneidung des Netzwerks":

    Wer selbst eine Fritzbox 7390 in Gebrauch hat, weiß, dass man in den Netzwerkeinstellungen für jeden Port auswählen kann, ob er mit 1GBit oder 100Mbit (energy saver) betrieben werden soll.
    Aus irgendeinem unerfindlichen Grund habe ich alle Ports von 1 Gbit auf 100Mbit umgestellt. Anschließend den Raspberry neugestartet und wieder eine Test-File abgespielt.

    Wie durch ein Wunder hatte ich von jetzt auf gleich keinen Aussetzer mehr. Auch die Debugging-Anzeige, die ich während des Abspielens dazuschaltete, zeigte, dass der Puffer nun immer konstant hoch blieb und nur in Ausnahmefällen mal kurzzeitig auf 80% fiel, aber dann sehr schnell wieder hoch auf 90+.

    Anschließend habe ich noch ein paar mal hin- und hergewechselt zwischen (1Gbit und 100Mbit auf allen Ports), um dieses Ergebnis zu verifizieren. Nach jedem Umstellen im Router war es immer nötig den RPi neuzustarten. Ich hatte es nun in der Hand den RPi bei der Wiedergabe zum "Stutter" zu bringen (Fritzbox auf 1Gbit auf allen Ports) bzw. die Wiedergabe flüssig und ohne jeden Aussetzer zu gestalten (Fritzbox auf 100 Mbit auf allen Ports). Es handelt sich also um keinen Zufall. Das Ergebnis ist bei mir absolut rekonstruierbar.

    Anschließend bin ich noch dazuübergegangen wahlweise nur Port 1 (RPi) auf 100Mbit und Port 2 (D-Link-Switch) auf 1GBit zu stellen. Das Ergebnis war, dass der Puffer nun wieder abbaute, aber sehr viel langsamer als sonst als die Fritzbox insgesamt auf allen Ports auf 1GBit lief.


    Lösung:

    Kurzum lautet die Lösung für ruckelfreies/stutterfreies Streamen: Entschleunigen der für das Streamen verwendeten Netzwerkverbindungen von 1 GBit auf 100Mbit.

    Dieses Ergebnis hätte ich (kein Informatiker) nie erwartet.

    Fazit:

    Das Ergebnis passt auch gut zu den widersprüchlichen Angaben, die man sonst in Foren liest. Die User haben bei ihren Äußerungen ("Bei mir läuft alles wunderbar über das LAN-Kabel" oder "Bei mir ruckelt es nur über LAN-Kabel") nie dazugesagt, welche LAN-Verbindung sie nutzen. Offenbar sind all diejenigen User benachteiligt, die eigentlich ein schnelleres LAN daheim installiert haben, damit nichts dem FULL-HD-Streaming im Wege steht *welch Ironie*.

    Dass mit den WLan-Dongles offenbar auch unproblematisch gestreamt werden kann, hängt möglicherweise mit der Wandlung der elektrischen Signale in Funksignale zusammen?! Das muss kann uns ja dann mal ein Fachmann näher erläutern.

    Ich hoffe, dass diese Erkenntnisse künftig auch anderen Nutzern von Hilfe sind, die wie ich absolut keine Erklärung für die Bild-Ruckler bei der Wiedergabe von 1080p-Material hatten.

    Gruß,
    Kailly

    Einmal editiert, zuletzt von kailly (25. August 2013 um 00:52)

  • Hi,

    gute Idee, werde ich bei mir - auch eine Fritzbox in Verwendung und Ruckler - gleich mal testen.
    Grundsätzlich ist WLan immer langsamer als Kabel - da hier der TCP-Overhead größer ist. Manche Datenpakete gehen bei WLan verschwindibus - und müssen erneut gesendet werden, weshalb die Bandbreite sinkt.

    Bei WLan rechne ich von den Brutto 150 Mbit (oder 300, je nachdem) immer 50% ab - das kommt dann "in etwa" in Richtung Netto-Rate; im Falle von 150 Mbit Brutto also etwa 75 Mbit Netto.

    Ich kenne das mit dem Feststellen der Geschwindigkeit insbesondere immer dann, wenn ein Gerät Probleme macht, die in Richtung Netzwerkbandbreite gehen. Manche Geräte erkennen selbstständig, welche Geschwindigkeit an z.B. einem Switch anliegt, und stellen sich dann darauf ein.

    Bei manchen Geräten klappt das nicht so gut - das z.B. das Gerät dann immer zwischen 100Mbit Duplex und 1000Mbit Duplex hin- und herspringt, das löst natürlich Verzögerungen aus, und wenn's 100 x die Sekunde passiert,... naja.

  • Bin gespannt, wie dein Test verläuft.

    Evtl. kann man ja auch eine Testumgebung schaffen, in der man ausschließlich einen 100Mbit-Switch verwendet, an dem sowohl der RPi als auch das NAS/Server/PC (Medien-Quelle) hängen.

    Gruß,
    Kailly

  • Mein RPI ist per HDMI mit einem Onkyo TX SR 876 verbunden. Das Gerät ist in der Lage DTS und AC3 per Pass-Through vom RPi zu erhalten, ohne dass der RPi sich hierfür mit eigener CPU-Leistung krumm machen müsste (und damit wertvolle Ressourcen, die er für das reibungslose Streamen benötig, verschwendet).


    darf man erfahren wie du das realisiert hast... die option für Pass-Through finde ich in der Openelec Version nicht

    die Netzwerkproblematik die du beschreibst kann ich nicht nachvollziehen.. ich spiele 3D Filme in 1080p und DTS ab ohne Probleme im 1Gb Netz..

    Einmal editiert, zuletzt von arteck (26. August 2013 um 09:45)

  • das Problem liegt einfach daran das der Netzwerkchip nicht mehr leisten kann wenn die CPU so doll am rödeln ist, daher auch die geringe Übertragungsrate per FTP. Per USB funktioniert es sogar mit ner m2ts Datei (BluRay File) + DTS

    Verstehe ich das richtig, dass hier einen USB zu LAN Konverter im spiel ist?

  • darf man erfahren wie du das realisiert hast... die option für Pass-Through finde ich in der Openelec Version nicht

    die Netzwerkproblematik die du beschreibst kann ich nicht nachvollziehen.. ich spiele 3D Filme in 1080p und DTS ab ohne Probleme im 1Gb Netz..

    In den Audio-Einstellungen die Häkchen bei
    - "Receiver unterstützt DTS" und
    - "Receiver unterstützt AC3" setzen.

    Zu der Netzproblematik:
    Ich nehme an, dass du keine Fritzbox in Betrieb hast, sondern einen anderen Router und/oder Switch, der besser mit dem RPi die zu verwendende Bandbreite abstimmen kann.
    Meine Message oben war nicht, dass GBit-LANs ungeeignet sind, sondern dass in meinem Fall meine Netzwerk-Hardware (Fritzbox, Switch) nicht sauber die zu verwendende Bandbreite mit dem RPi abstimmen konnten.
    Jedes Gerät in einem Netzwerk teilt den anderen Geräten eigentlich mit, welche Bandbreite es nutzen. Und genau hier lag der Hund bei mir - und wahrscheinlich vielen anderen auch - begraben.
    Die meisten suchen das Problem nämlich im verwendeten Betriebssystem oder im RPi selbst und nicht in der physischen LAN-Verbindung.
    Ich hoffe, dass ich das hierdurch noch mal etwas verständlicher machen konnte.

    Gruß,
    Kailly

  • In den Audio-Einstellungen die Häkchen bei
    - "Receiver unterstützt DTS" und
    - "Receiver unterstützt AC3" setzen.

    soweit mir bekannt bewirkt dies kein Pass-Through.. diese Option muss explizit im Menü stehen wie auch im XBMC unter Windoofs zu sehen ist
    dies kannst du auch erreichen wenn du RASPBMC installierst nur, dass es zwar einstellbar ist aber es kommt (zumindest bei mir) kein Ton aus dem Onkyo (ich hab einen 809)..ergo nix Pass-Throught...


    und ja ich hab eine Fritz Box: 7390
    dazu ca. 100 m Cat 7 Kabel hier im Haus liegen
    es hängen 3 1 Gb Switche drann verteil auf die 4 Ports,
    7 Rechner,
    4 Handys (Wlan)
    und die 2 Pi's wobei der Media Pi am Kabel hängt und der andere steuert das Garagentor und hängt mit Wlan (Kabel :bravo2:kleiner Scherz am Rande) drann.

    Einmal editiert, zuletzt von arteck (26. August 2013 um 21:46)

  • Pass-Through bedeutet, dass z.B. der DTS-Ton nicht vom RPi decodiert wird, sondern dies erst im Endgerät (z.B. dem Onkyo) geschieht.

    Sobald ich die o.g. Optionen "unterstützt DTS" u. "unterstützt AC3" in Openelec aktiviert habe, werden die Tonspuren offenbar von meinem Onkyo decodiert und auch sauber wiedergegeben. Der Onkyo zeigt bei mir im Display auch die entsprechende Tonspur an (entweder "DTS" oder "DolbyDigital").

    Nehme ich im RPi die beiden Häkchen jedoch raus, erkennt der Onkyo das eingehende Ton-Signal schon nicht mehr. Im Display des Onkyos gibt es dann keine der o.g. Anzeigen.

    Das heißt also weiter, dass bei aktiviertem "unterstützt DTS" u. "unterstützt AC3" automatisch ein Pass-Through der nicht-decodierten Tonspur stattfindet. Das ergibt sich für mich auch aus der Erläuterung hier: http://wiki.xbmc.org/index.php?titl…em#Audio_output.

    Vielmehr stellt sich mir die Frage, weshalb es in anderen XBMC-Versionen extra noch ein Auswahlfeld für das "Passthrough-Output-Device" gibt. Das würde ja nur Sinn machen, wenn man parallel mehrere unterschiedliche Geräte per HDMI mit XBMC verbunden hat.
    Am RPi kann zu selben Zeit jedoch immer nur ein HDMI-Gerät angeschlossen werden.

    Gruß,
    Kailly

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!