[ANNOUNCE] VDR developer version 1.7.11

Zitat

Original von kls
In meinem VDR stecken auch zwei FF-Karten, und eine (bestimmte) davon ist das Ausgabe-Device - ohne daß ich irgendwas mit udev mache. Warum geht es bei mir und bei dir nicht?

Keine Ahnung. Wenn ich nicht eingreifen würde, wäre mal die Budget und mal die FF Adapter 0. Wenn man so diverse Threads liest, scheint das nicht so selten zu sein.

Gruß
e9hack

Zitat

Originally posted by kls

...
Ich werde das setzen der PCR-Pid wieder einbauen und schauen, ob es möglich ist, im Falle von PPID<>VPID was zu tricksen.

Ich habe jetzt mal einige Aufnahmen gemacht von Kanälen mit VPID==PPID und VPID!=PPID, nämlich

RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0

und konnte beide mit dem Windows Media Player problemlos abspielen.
Auch Aufnahmen, in denen die PCR-Pid auf 0x1FFF gesetzt ist, spielt der WMP hier ohne zu murren ab. Angeblich sollte es doch nicht möglich sein, solche Aufnahmen mit dem WMP abzuspielenm oder?

Bevor ich da was ändere würde ich halt schon gerne selber mal einen Problemfall hier nachvollziehen können. Mit welchem Kanal gibt es denn mit dem WMP Probleme?

Klaus

versuch statt dem WMP mal vlc.

Zitat

Originally posted by Dr. Seltsam
versuch statt dem WMP mal vlc.

Die Installation wollte ich mir eigentlich ersparen

Es hieß doch, daß es auch mit dem WMP nicht geht - oder habe ich da was mißverstanden?

Klaus

Hää, ich kann kaum glauben, das der VLC irgendwas weniger gut kann als der WMP.

ich weiss nur, dass es bei vlc in Verbindung mit dem streamdev-Plugin Probleme gab, weil vlc ohne PCR nichts abspielt. Ob das nun auch das direkte Abspielen von Dateien betrifft, weiss ich nicht.

Über Probleme mit dem WMP habe ich noch nichts gelesen. Wer benutzt denn sowas?

Zitat

Originally posted by Dr. Seltsam
ich weiss nur, dass es bei vlc in Verbindung mit dem streamdev-Plugin Probleme gab, weil vlc ohne PCR nichts abspielt. Ob das nun auch das direkte Abspielen von Dateien betrifft, weiss ich nicht.

Über Probleme mit dem WMP habe ich noch nichts gelesen.

Guckst du hier: [ANNOUNCE] VDR developer version 1.7.11

Zitat

Wer benutzt denn sowas?

Ich hab's auch nur zum Testen benutzt
Aber wenn selbst der das kann, dann würde ich sagen sollte ein VLC das doch schon lange können, oder?

Klaus

dann müsste Razorblade jetzt mal sagen, ob er direkt die Files abgespielt hat, oder ob das über streamdev lief.

Ich habe auf meinem Kubuntu jetzt mal versucht, die 00001.ts in einem vdr-Ordner mit verschiedenen Playern abzuspielen:

vlc: zeigt nur ein Standbild vom ersten frame, keine Wiedergabe möglich
dragonplayer: geht
mplayer: geht

Das Problem ist, dass die stream-Plugins für Browser wohl meist auf vlc basieren

vielleicht meinte Razorblade auch MVP statt WMP

Nein, ich meinte WMP, um genauer zu sein den WMP von Windows 7 (x64).
Mit vanilla-1.7.11 erstellte Aufnahme (ProSieben) kann weder mit VLC noch VLC abgespielt werden, wenn ich die PCR Änderung wie beschrieben rückgängig mache geht es wieder (mit beiden).

Zitat

Originally posted by Razorblade
Nein, ich meinte WMP, um genauer zu sein den WMP von Windows 7 (x64).
Mit vanilla-1.7.11 erstellte Aufnahme (ProSieben) kann weder mit VLC noch VLC abgespielt werden, wenn ich die PCR Änderung wie beschrieben rückgängig mache geht es wieder (mit beiden).

Ich habe hier mit Windows XP getestet. Das heißt also, daß der WMP in Windows XP noch geht, aber in Windows 7 "kaputt" ist. Na ja...

Windows 7 hab' ich hier nicht (XP hab' ich auch nur, weil es halt auf meinem Laptop bereits drauf war ;-).

Die Änderung, daß fest 0x1FFF als PCR-Pid in die PMT geschrieben wird, habe ich für die nächste Version rückgängig gemacht. Zumindest für Kanäle, bei denen VPID==PPID ist, sollte es dann wieder gehen.

Ich habe inzwischen VLC hier installiert und kurz mit einer Aufnahme von BVN (VPID!=PPID) getestet, und das wird anstandslos abgespielt. Also nochmal die Frage, mit welchem Sender es ein Problem gibt
(mit remux.c aus VDR 1.7.10).

Klaus

Zitat

Original von kls
Also nochmal die Frage, mit welchem Sender es ein Problem gibt
(mit remux.c aus VDR 1.7.10).

die vdr-1.7.11-Aufnahme, die mein Linux-vlc nicht abspielt, stammt von RTL2

kls: Vielen Dank für die PCR Änderung in 1.7.12, ich benutze öfters vlc aus Windows um mal schnell in eine Aufnahme "reinzuschauen"

Wenn wir schonmal dabei sind, dürfte ich dann noch einen Feature Reuqest loswerden: Könnte man das updaten des Video-Verzeichnissen aus dem vdr triggern anstatt die ".update" touchen zu müssen?
Hintergrund: Ich habe einen Aufnahmeserver und mehrere Abspielclients, alle vdr. Wenn jetzt der Server etwas aufnimmt wissen die Clients davon erstmal nichts. Ein .update im Filesystem scheint in dem Fall (evtl hat es etwas mit NFS mount zu tun?) nur den Server zu interessieren, aber nicht die Clients...

Zitat

Original von Razorblade
kls: Vielen Dank für die PCR Änderung in 1.7.12, ich benutze öfters vlc aus Windows um mal schnell in eine Aufnahme "reinzuschauen"

Wenn wir schonmal dabei sind, dürfte ich dann noch einen Feature Reuqest loswerden: Könnte man das updaten des Video-Verzeichnissen aus dem vdr triggern anstatt die ".update" touchen zu müssen?
Hintergrund: Ich habe einen Aufnahmeserver und mehrere Abspielclients, alle vdr. Wenn jetzt der Server etwas aufnimmt wissen die Clients davon erstmal nichts. Ein .update im Filesystem scheint in dem Fall (evtl hat es etwas mit NFS mount zu tun?) nur den Server zu interessieren, aber nicht die Clients...

Geht das nicht mit dem remotetimers-plugin? Dazu muss der Mountpoint der Serveraufnahmen innerhalb des lokalen Videoverzeichnisses sein. Dann im remotetimersplugin den Unterordner angeben und "Auf update achten" anschalten und schon sollte es gehen.

Trotzdem wäre dein Vorschlag besser

Razorblade.

Habe das selbe Problem, allerdings was soll VDR da triggern?
Ist mir nicht ganz klar.

Wenn ich es richtig sehe, liest VDR die Aufnahmen nur beim Start, oder wenn eine .update Datei im Videoordner liegt.

VDR-Server startet eine Aufnahme und fügt diese beim beenden der internen Aufnahmenliste zu.
Die Clienten können davon nichts mitkriegen.

Bei den . update geht es nach der Devise "Wer zuerst kommt' malt zuerst" sprich ein Client erkennt, dass es eine .update gibt, liest neu ein und löscht das File dann. Wenns blöd kommt ist es der Server der neu einliest.

Peter

Zitat

Originally posted by pixelpeter
Razorblade.

Habe das selbe Problem, allerdings was soll VDR da triggern?
Ist mir nicht ganz klar.

Wenn ich es richtig sehe, liest VDR die Aufnahmen nur beim Start, oder wenn eine .update Datei im Videoordner liegt.

VDR-Server startet eine Aufnahme und fügt diese beim beenden der internen Aufnahmenliste zu.
Die Clienten können davon nichts mitkriegen.

Bei den . update geht es nach der Devise "Wer zuerst kommt' malt zuerst" sprich ein Client erkennt, dass es eine .update gibt, liest neu ein und löscht das File dann. Wenns blöd kommt ist es der Server der neu einliest.

Peter

Alles anzeigen

VDR löscht die .update-Datei nicht, sondern "beobachtet" nur ihren Timestamp.
Sobald der neuer ist als der zuletzt gesehene, wird neu eingelesen.

Klaus

Zitat

Original von kls
VDR löscht die .update-Datei nicht, sondern "beobachtet" nur ihren Timestamp.
Sobald der neuer ist als der zuletzt gesehene, wird neu eingelesen.

So dachte ich mir das auch, aber wenn ich besagte Datei touche (sogar vom Client auf den NFS Share des Servers!) sehe ich nur beim Server ein "video directory scanner thread" thread starten, den Client läßt das kalt...
Wie gesagt, es könnte auch am NFS liegen, aber das ganze per Befehl/Menüeintrag oder SVDRP zu triggern wäre doch auch nicht verkehrt oder?

Gruß,
Razor

Hi,

Ist das neu, dass die .update liegen bleibt?

Mir war so, als würde diese immer wieder verschwinden.
Um so besser. Wieder was dazu gelernt...

Peter

Mit der 1.7.11 hab ich von Kabel1 und Nick/Comedy zwei TS-Aufnahmen gemacht. Das auf Kabel1 aufgenommene "LOST" läßt sich wie gewohnt vor- und zurückspulen. Ebenso ergeben sich beim Schneiden mit noad-0.7.0 keinerlei Auffälligkeiten.

Anders bei "IT-Crowd", aufgenommen auf Nick/Comedy. Dort bekomme ich beim Spulen nur eine hellgraue Fläche angezeigt. Zurück auf PLAY wird dann wieder die normale, vor- oder zurückgespulte Aufnahme angezeigt. Beim Schneiden ergibt sich der selbe Effekt. Beim Anspringen und Verschieben der Schnittmarker erscheint lediglich die hellgraue Fläche. Somit ist ein kontrolliertes Setzen der Marke unmöglich. Erst bei Wiedergabe erscheint wieder das Bild.

Der Effekt ist sowohl unter xine als auch unter xineliboutput zu beobachten. Selbst bei ungepatchten Varianten von xine-lib-1.2-cvs und xineliboutput-cvs/xine. Da ich direkt von der 1.7.0 auf die 1.7.11 gewechselt bin, habe ich leider keine Vergleichsmöglichkeit mit anderen ts-Aufnahmen bzw. VDR-Versionen.

Hat noch wer das Problem?

Gruß
iNOB

Zitat

Originally posted by Razorblade
Hintergrund: Ich habe einen Aufnahmeserver und mehrere Abspielclients, alle vdr. Wenn jetzt der Server etwas aufnimmt wissen die Clients davon erstmal nichts. Ein .update im Filesystem scheint in dem Fall (evtl hat es etwas mit NFS mount zu tun?) nur den Server zu interessieren, aber nicht die Clients...

Eigentlich sollten alle Clients sich über die .update gegenseitig über Änderungen informieren. Verwendest du ein gemeinsames Video-Wurzelverzeichnis für alle Clients?

Das ist der einzige Nachteil, den ich am derzeitigen System sehe: Mountet man das /video eines VDR in ein Unterverzeichnis /video/server/ des anderen, entstehen zwei verschiedene .update-Dateien, und der Abgleich findet nicht statt. Abhilfe wäre, jede gefundene .update zu überwachen. Andererseits käme es auf einen Versuch an, ob ein externes Programm nicht mehrere .update-Dateien gegeneinander abgleichen könnte...

Gruß,

Udo