tja,
schwierig, wie sieht es den aus wenn das selbe file local auf der platte vorhanden ist? Hört sich erst mal nach wlan an! Alternativ mal umgedreht testen. Mit mplayer (für win) ne aufnahme über samba wiedergeben. Wobei das wahrscheinlich nicht die selben datenraten sind. Oder um ganz sicher zu gehen mal nen lan kabel zu testzwecken dran.
Gruss lexi
ja klar geht das mit um das Thema "Transferraten" wenn was soll den abgespielt werden wenn die datenrate es nicht hergibt? Also wird dann erst mal gesammelt bis wieder nen paar teile mehr da sind. Und wo wird gesammelt, na klar local. Hier wird aber nichts kopiert sondern nur zwischengespeichert.
Mit meinen ersten posting wollte ich auch nun was ausschliesen also teste das nach Möglichkeit.
Lexi
Kommentiere doch mal in der mplayer.sh.conf die Zeile:
CACHE="4096"
aus und probiere, ob es schneller startet und ob es dann keine Hänger gibt, wenn vielleicht mal die Übertragung kurzzeitg einbricht.
(wenn keine CACHE-Option da ist, wird '-nocache' angenommen.)
Gruß,
Juri
Hi,
Wie mountest Du ?
mount -t cifs
sollte zumindest schneller als -t smbfs oder smbmount sein.
Hallo,
so - netio behauptet ich hab ne nettorate von 12Mbit/s im Wlan - nicht wirklich optimal für ein dediziertes G only Wlan, aber sollte eigentlich ausreichend sein.
Der mount geht über cifs auf eine IP also auch diese Variante leider ausgeschlossen und keine Probleme bei der Namensauflösung...
Ach ja - noch ein kleines, unwichtiges Detail am Rande - es sind xvids.
Die Kabel Variante kann ich noch nicht testen - mein Weibchen will fernsehgucken 
//thezeus
Hi,
Er meint die /etc/vdr/plugins/mplayer/mplayer.sh.conf
Hallo Helau,
das hatte ich dann auch gesehen
aber auch wenn ich den cache auskommentiere, dauert es mehrere(!) minuten bevor der mplayer zuckt.
Während dieser Zeit bricht auch das Wlan auf 3Mbit/ netto in Richtung vdr ein...
//thezeus
Du meinst, ohne CACHE Option dauert es länger, als mit?
Setze doch bitte mal DEBUG="true" und poste die Ausgaben inkl. Timestamp des Syslogs - dann kann man vielleicht sehen, bei welchen Schritten die Zeit draufgeht.
Ja, kannste ja trotzdem mal posten, denn es wäre ja schon interessant, wo die Zeit verbracht wird...
Gruß,
Juri
Hmmh,
ich hab des Öfteren die Erfahrung beim Verbinden von Windows <-> Unix über Samba gemacht, daß Samba trotz Optimierung recht träge ist; von diversen Konflikten in der samba.conf ganz abgesehen.
Zwischenzeitlich habe ich mich gänzlich von Samba getrennt und arbeite nur noch mit nfs. Seitdem ist Ruhe :).
Microsoft bieter die "Services for Unix" kostenlos an; da ist sowohl der nfs-client, als auch der nfs-server für Windows dabei und je nach Einsatzzweck einsetzbar. Flutscht wunderbar, ist sauschnell und ich spare mir den Krampf mit Samba.
gruss
michael
Hallo,
Noch 2 weiterere Tests:
1. Aendere in der mplayer.sh.conf SLOW_CPU=true und teste damit.
2. Schalte mit der Start Taste zu FreeVo um und spiele da das DivX ab.
Wie klappt dies, und was steht dann dazu in den logs unter /log/freevo ?
Hm, abgekürzt und als Auszug:
May 11 21:44:08 [logger] *** Starting mplayer.sh Version 0.8.7
.
.
.
May 11 21:44:14 [logger] Starte Wiedergabe...Das sind dann 6 Sekunden.
Der Start des MPlayer-Plugin selbst (mithin also des VDR) war:
May 11 21:42:10 [vdr] [3508] starting plugin: mplayeralso 2 Minuten vorher, gestoppt wurde es hier:
May 11 21:46:00 [vdr] [3508] stopping plugin: mplayerEs gibt also 2 Ca-Zwei-Minuten-Intervalle. Wird die Zeit verbraucht, bevor die 'mplayer.sh' gestartet wird (also zwischen dem Starten der Wiedergabe im VDR und dem Aufruf der 'mplayer.sh') oder erst, nachdem der MPlayer gesagt hat, dass er die Wiedergabe startet?
Das bekommst du wohl nur raus, wenn du mittels 'tail -f /var/sys/log' deinen Syslog mal live beobachtest.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!