xine mit streamdev stottert bei Aufnahmen

Hi,

bessert sich die Wiedergabe, wenn du in xine den "Pause"-Knopf betätigst, ein paar Sekunden wartest und in nochmals betätigst?

Für LiveTV wird über das Softstart-Feature ein Puffer eingerichtet, damit xine immer Daten lesen kann, wenn es welche braucht.

Bei der Wiedergabe bin ich bisher davon ausgegegangen, dass VDR diese schnell genug liefern kann. Evtl. braucht es im Zusammenspiel mit streaming auch noch einen Puffer.

Bye.

Hallo winni,

ich scheine dasselbe Problem zu haben - wiedergabe von Live-TV geht prima, das Bild sieht IMHO sogar besser aus als mit Kvdr und FF-Karte, wiedergabe von Aufnahmen stottert (so etwa im Sekundentakt).
(HW ist ein Athlon 2,4)...ich denke auch nicht, dass es an streamdev liegt, weil die Aufnahmen ja lokal auf dem Rechner liegen. Gibt es mittlerweile eine Lösung des Problems? Meine vdr-xine-version ist 0.5.2.

Grüsse

Orca

Hallo winni,

danke für die schnelle Antwort und schön, dass sich da was tut. Ansonsten läuft das mit dem xine-Plugin und streamdev nämlich wirklich besser als erwartet, mp3-plugin geht auch und so steht einem DVB-Hardware-Losen Client eigentlich nicht mehr viel im wege...!
also, dann warten wir mal auf die vdr-xine-0.6.1...!

Und die anderen vdr-xine benutzer? gibt es jemanden der diesen Effekt auch hat oder gehts bei Euch ohne ruckeln ???

Hi,

anscheinend wurde mein Posting noch nicht gelesen:

http://www.vdr-portal.de/board…?postid=216525#post216525

Wüsste derzeit nicht, was ich an vdr-xine-0.6.1 diesbezüglich verbessern könnte.

Bye.

Hi,

Zitat

Original von winni
stand da anfangs nicht noch was von "todo: Aufnahme/Wiedergabe?" , also vor deinem Edit?

Stimmt. Hab gerade erst gesehen, dass sich durch mein Edit das Änderungsdatum für den Thread auch nicht geändert hat.

Zitat

Original von winni
Werd es nochmals mit Deinen Angaben testen. Das mit den beiden Transpondern ist mir auch schon aufgefallen. Welche streamdev-Versionen nutzt Du eigentlich server- und client-seitig. Ist ja momentan nicht so einfach, wegen des streamdev-clients?

Auf beiden Maschinen

vdr-streamdev-0.3.3-pre4.tgz
+ vdr-streamdev-0.3.3-pre3-geni-for-1.3.14.diff
+ folgenden Patch

diff -upr streamdev-0.3.3-pre3-geni/client/device.h ../streamdev/client/device.h
--- streamdev-0.3.3-pre3-geni/client/device.h   2004-08-14 19:57:51.000000000 +0200
+++ ../streamdev/client/device.h        2004-11-11 22:28:09.000000000 +0100
@@ -30,7 +30,7 @@ private:


 protected:
        virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView);
-       virtual bool HasLock(void) { return m_TSBuffer != NULL; }
+       virtual bool HasLock(int TimeoutMs = 0) { return m_TSBuffer != NULL; }


        virtual bool SetPid(cPidHandle *Handle, int Type, bool On);
        virtual bool OpenDvr(void);

Bye.

Hallo zusammen,

also, ich habe auch mal aktualisiert auf vdr-1.3.10 mit allen Patches von Reinhard + aktuelle Xine-Version + streamdev 0.3.3 -> Resultat ist leider immer noch das selbe, live-streaming ist voll ok, aufnahmen ruckeln-
ich denke also, der Fehler liegt NICHT am streamdev, sondern eher an den Puffereinstellungen von vdr-xine.

Jetzt hatte ich gesehen, dass in der Datei xineSettings.c schon vorbereitungen fürs Setup eingebaut waren (Optimized for Replay ...) um irgendwas am Prebuffer Mode einzustellen...

Reinhard, hast Du das in eine Version 0.6.1 (von der Du hier schon geschrieben hast) schon eingebaut ??? Das wäre nämlich genau das, worin ich auch die Lösung sehen würde. Leider gibt es diese Version 0.6.1 wohl (noch) nicht zum Download ??

Die wäre es nämlich, die zu unserem vdr-xine-Glück noch fehlen würde...

grüsse, orca2

Hi,

Zitat

Original von orca2
also, ich habe auch mal aktualisiert auf vdr-1.3.10 mit allen Patches von Reinhard + aktuelle Xine-Version + streamdev 0.3.3 -> Resultat ist leider immer noch das selbe, live-streaming ist voll ok, aufnahmen ruckeln-
ich denke also, der Fehler liegt NICHT am streamdev, sondern eher an den Puffereinstellungen von vdr-xine.

Zur Begriffsklärung: Nachdem ich nichts gefunden habe, Aufnahmen auf dem Server zum Client zu streamen, gehe also davon aus, dass es sich um Aufnahmen handelt, die lokal auf der Platte liegen.

Oder ist das /video-Verzeichnis vom Server auf dem Client via NFS oder SMB gemountet?

Zitat

Original von orca2
Jetzt hatte ich gesehen, dass in der Datei xineSettings.c schon vorbereitungen fürs Setup eingebaut waren (Optimized for Replay ...) um irgendwas am Prebuffer Mode einzustellen...

Das ist leider nichts neues, sondern eher uraltes, das eigentlich nicht mehr gebraucht wird.

Zitat

Original von orca2
Reinhard, hast Du das in eine Version 0.6.1 (von der Du hier schon geschrieben hast) schon eingebaut ??? Das wäre nämlich genau das, worin ich auch die Lösung sehen würde. Leider gibt es diese Version 0.6.1 wohl (noch) nicht zum Download ??

Die 0.6.1 ist noch nicht fertig. Ich hoffe, dass dieses Wochenende der große xine-Patch endlich ins CVS aufgenommen wird. Aber bezüglich dieses Problems habe ich noch nichts unternommen, denn einfach auf Verdacht möchte ich diese Änderung nicht machen

Bitte stelle mir mal dar, wie auf die Aufnahmen zugegriffen wird, dann kann ich es evtl. nachvollziehen und anpassen, denn via NFS hat es auf meinem Client bisher (letzter Test mit VDR < 1.3.11) auch nicht geklappt: die CPU-Last war einfach zu hoch!

Bitte auch mal vdr-1.3.15 oder höher ausprobieren, da sich da bzgl. Datei in Puffer einlesen was getan hat.

Was auch noch interessant ist: welche Hardware kommt zum Einsatz?

Bye.

Hi,

Zitat

Original von winni
zur Info: hab bei mir jetzt 1.3.16 auf Server- und Client-Seite, streamdev-0.3.3-pre3-geni auf beiden Seiten wie bei Dir mit Deinen Optionen. Live-Streaming geht bei mir mit dieser Version nicht mehr (jemand nen Tipp? :D)

???

Zitat

Original von winni
vdr-xine ist die 0.6.0. Die Aufnahmen, die ich früher mit einer anderen streamdev-Version gemacht hab, liegen lokal auf dem Client. Funktionieren auch ruckelfrei mit mplayer. Client ist ein AMD Duron 1200 mit GForce, 512 MB, nvidia Treiber unter x. Server siehe Signatur. Vielleicht hilft Dir das weiter.

Also ich denke, dass dieses Problem nichts mehr mit streamdev zu tun hat, aber auch nicht in vdr-xine gelöst werden kann. Ich verstehe nicht, warum dein leistungsfähigeres System hier meinem alten Client nachsteht.

Meines Wissens bist du der erste, der mit der Wiedergabe von "lokalen" Aufzeichnungen Probleme hat. Das soll nicht bedeuten, dass ich an vdr-xine gundsätzlich nichts anpassen möchte, aber ich denke, dass hier irgendwas an deinem System noch nicht perfekt konfiguriert ist.

Schon mal

hdparm -u1 /dev/hda

probiert?

Und wie steht's mit DMA?

Bye.

Hallo zusammen,

also, nochmal ein paar Infos von mir:

Ich hatte die 1.3.15 noch nicht verwendet, weil es da Compile-Probleme mit streamdev gab...deshalb noch 1.3.10. Also ich habe die Probleme AUCH bei lokalen Aufnahmen (also Winni ist nicht der allereinzige). Und was bemerkenswert ist': die Prozessorlast geht hoch auf sagenhafte 40-50% (vom VDR-Prozess) (normal 5-10%).

/Video über nfs mounten hab ich auch probiert, es sah eigentlich genauso aus wie lokal (also auch nicht schlechter)

Meine Hardware:
Athlon 2,4 Ghz, 256 Mb, 40Gb Maxtor (DMA aktiviert -d 1, -u 1 hab ich noch nicht probiert), alte trident-GraKa (ich weiss, könnte besser sein, aber live-TV geht ja auch gut, also denk ich, das passt schon)

Was ich jetzt noch für einen Verdacht habe: könnte es sein, dass das NFS irgendwie alles durcheinanderbringt (auch wenn man lokale Aufnahmen abspielt)? ich werds heute abend noch mal testen.

Grüsse und viel Erfolg !!

Orca2

achso, übrigens spielt mplayer sowohl über Netz als auch die lokalen aufnahmen gut ab, die aufnahmen an sich sind also ok.

Hallo Reinhard, hallo Winni,

hier mein nächster Versuch:

vdr-1.3.15 + Replay-Patch + Transfer-Patch
vdr-xine-0.6.0
DMA aktiviert

KEIN nfs, KEIN streamdev

-> Resultat: wieder dasselbe, Ruckeln bei Wiedergabe von lokalen Aufnahmen, Prozessorlast durch VDR-Prozess 40 % !!!

(vorher bei streamdev nur 10%)

gegen Ende der Aufnahme kommt ffffffffff als Ausgabe aber ich glaube das ist normal,oder?

also langsam weiss ich nicht mehr, was ich noch probieren kann ...?
Irgendeine Idee, wo ich ansetzen könnte?

grüsse

Orca

Hallo Winni,

also ich hab xine mit Default-Parametern gestartet; da die Karte keinen xv-Treiber hat, würde ich mal davon ausgehen, das das XShm entspricht...ähhh, was ist eigentlich xhms??? in der xine-Doku ist das irgendwie nicht zu finden (Tippfehler ?)
grüsse

Hi,

Zitat

Original von winni

ne, kein Tippfehler. Ich kannte das auch nicht und hab das irgendwo als Tipp bekommen. Nur mit dieser Einstellung funktioniert bei mir ein Snapshot aus xine samt Bild UND Osd.

Damals habe ich es als Tippfehler abgetan, aber ich denke, das sollte jetzt geklärt werden:

xine --help
...
  -V, --video-driver <drv>     Select video driver by id. Available drivers:
                               aadxr3 dxr3 xv caca aa xshm none sdl opengl vidixfb vidix fb

Also lautet es korrekt "xshm". xine ist allerdings recht tolerant bzgl. dem Argument und ein "-V egon" führt bei mir auch zu "-V xv", d. h. xine bevorzugt den xv-Treiber.

Das erklärt nun auch, warum man bei "-V xhsm" das OSD mit auf den Screenshot bekommt, denn typischerweise funktioniert dies gerade bei "-V xshm" nämlich nicht (xine Internas lassen dies derzeit nicht zu).

Wer also mit "-V xshm" Screenshots mit OSD haben möchte muss leider zu Tools wie xv oder gimp greifen und das Fenster "abfotografieren".

Bye.