WinFuture-Forum.de: [solved / gelöst] Linux Samba Windows 7 Streaming Lag Stutter - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Linux
Seite 1 von 1

[solved / gelöst] Linux Samba Windows 7 Streaming Lag Stutter


#1 Mitglied ist offline   SFFox 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.338
  • Beigetreten: 19. August 04
  • Reputation: 4
  • Geschlecht:Männlich
  • Wohnort:Bonn

geschrieben 16. April 2014 - 00:17

Heyho,

als Community meines Vertrauens möchte ich erst hier um Rat fragen, bevor ich anfange mich bei den Ubuntu Foren anzumelden oder gleich die Linux Distribution zu wechseln.

Ich hab als Einsteiger halbwegs lange damit gekämpft und mir jetzt einen Ubuntu Heimserver gebastelt. Dieser läuft mit 2* 3TB in einem mdadm Raid1 Verbund, das in /media/samba/ als Netzwerkspeicher gemountet ist. Eigentlich war anfangs noch gedacht, dass das System selbst auch auf den Platten läuft und somit nicht nur die Daten sicher sind, sondern auch das Betriebssystem gespiegelt beibehalten werden kann. Aufgrund des ext4 Journalings, das einfach ständig schreiben muss (ja man kann den commit unendlich hoch setzen, ist aber widersprüchlich zum Sinn des Journalings), wären die beiden großen Platten nie schlafen gegangen. Somit läuft das System selbst jetzt auf einer 80GB Notebook Platte, die ja auch recht gering im Verbrauch ist.

xrdp vernünftig benutzbar zu kriegen (so dass man seine angefangene Session wieder aufnehmen kann) war ein Kampf, den ich gewonnen hab. Das Raid1 per hdparm zum Schlafen zu kriegen, war ebenfalls nicht so einfach (-S 240 bringt die Platten nach 20 Minuten problemlos ins Bettchen, -S 241 sollte nach 30 Minuten greifen, aber da tut sich leider einfach mal gar nichts). Mit den 20 Minuten kann ich noch leben, vielleicht wird das mit dem Sprung auf die nächste LTS, die ja schon in den Startlöchern steht, alles etwas kompatibler und einfacher zu konfen.

(vielleicht habt ihr dazu ja auch noch ein paar Insider Tipps auf Lager)

Mein aktuell größtes Problem ist jedoch an Samba gebunden. Ich habe genau eine Dateifreigabe, die ich jeweils einzeln als Netzlaufwerk in die Windows 7 Rechner unseres Haushaltes eingebunden haben. Darauf liegen im Prinzip nur Mediadaten (Musik / Videos). Mit den Videos gibt es jetzt folgendes Problem, das ähnlich auch oft im Netz zu finden ist, aber leider bisher bei mir nicht zu fixen war.

Wenn ich ein Video von dem Media-Netzlaufwerk mit einem Videoplayer aufrufe und abspiele (mit MPC und VLC getestet) läuft es anfangs ganz gut bis das Video zum ersten Mal "stolpert". Das Bild bleibt stehen und der Sound von vor etwa 10 Sekunden fängt an sich noch einmal zu wiederholen. Ist bis dahin das nächste Stück Video geladen läuft es manchmal weiter. Ansonsten wiederholt sich das Ganze oder der Player verweigert mit "bad file descriptor" seinen Dienst.
Ich nehme an, dass es an der Art des Dateizugriffes liegt und Windows eine bestimmte Rückmeldung nicht an Samba gibt, die aber zum Erhalt der stabilen Verbindung nötig wäre. Es lässt sich folgendes beobachten:

Wenn das Video stockt und ich in einem Fileexplorerfenster von Windows auf dem Netzlaufwerk auf einen Ordner klicke, oder die Ansicht refreshe (also einen Read/Write Request an den Server schicke), dann läuft das Video in genau diesem Moment wieder problemlos weiter bis zum nächsten derartigen Ausfall. Es kommt sogar noch kurioser. Wenn ich zeitgleich auf meinem Androidphone (das die Videos übrigens problemlos abspielen kann) das Video abspiele, kommt es auch am Win7 PC zu keinerlei Aussetzern. Der Win7 PC ist per Gigabit LAN Kabel angebunden und zwischen Ubuntu und Win7 schafft der Samba Dienst stolze 95 MegaByte/Sekunde. An mangelnder Performance wird es nicht liegen, zumal das Androidphone auch nur per WLAN zugreift.

Ich bin etwas ratlos. Von Windows Registry Einträgen wie SessTimeout und Samba2 und Samba3 hab ich schon gelesen und diese erfolglos getestet. Auch der SSDP Dienst von Windows ist bereits von mir abgeschaltet worden. Das Samba Log ist sauber, Druckfunktionen von Samba sind in der Config deaktiviert. Eigentlich ist alles sauber und funktioniert schnell, bis auf diese Hänger zwischendurch.

Ein wenig bin ich schon darüber verärgert, wie umständlich so manches jetzt mit Ubuntu war und dass es trotzdem immer noch nicht läuft. Ich hatte auch mal den Floppy Linux Router (FLI4l), der auch schon ein sehr einfaches Samba konnte, und selbst der hatte nicht soviele Probleme <.< Ich bin dankbar für jeden Tipp :)

mfg
SFFox

Dieser Beitrag wurde von SFFox bearbeitet: 16. April 2014 - 19:40

0

Anzeige



#2 Mitglied ist offline   SFFox 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.338
  • Beigetreten: 19. August 04
  • Reputation: 4
  • Geschlecht:Männlich
  • Wohnort:Bonn

geschrieben 16. April 2014 - 18:39

Ewig damit rum geschlagen und just die Lösung gefunden. Für alle, die einen Linux Rechner mit Samba Freigabe als Fileserver für ihre Medien haben und mit einem Windows 7 Client darauf zugreifen und sich über Videos mit (Achtung Keywords falls jemand danach sucht im Netz) stocken ruckeln Aussetzern freeze stutter lagging Symptomen ärgert... ein kleiner fast vergessener Parameter in der smb.conf im Linux Rechner schafft Abhilfe:

Unter [global] kann man das Setting "keep alive = 1" setzen. Der Defaultwert (wenn gar nichts eingetragen ist) scheint 30 zu sein. Meine durch Tests gezeigte Vermutung hat sich bestätigt. Der Samba Dienst erklärt die Verbindung für tot, weil nach der Videoanfrage scheinbar kein echter filerequest mehr stattfindet, wenn Windows 7 auf die Datei per Media Player zugreift. Wenn nach 30 Sekunden (default) erst ein keep alive Paket gesendet wird, ist das Video schon 10 mal weg geschmiert. Sendet man das kleine Päckchen jede Sekunde mit, läuft alles flüssig. Wie hoch ich den Wert setzen kann, bis das Video wieder stockt, habe ich noch nicht getestet.

Andere Geräte (Android Phone / Tablet) scheinen mit dem MX Player wohl per Samba Protokoll die Files zu streamen und senden von alleine öfter ein paar Filerequests, so dass die Verbindung nicht zusammenbricht. Wie es mit XP/Vista/8 aussieht, habe ich ebenfalls nicht getestet.

mfg
SFFox

Dieser Beitrag wurde von SFFox bearbeitet: 16. April 2014 - 18:44

0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0