[ANNOUNCE] VDR developer version 1.7.11

Zitat

Original von domml
Im INSTALL file sprichst Du von "runvdr.template", die Datei heißt aber "runvdr.example".

Gruß

Dominik

oh, danke für den Hinweis!

edit: Patch ist geändert

Ja, der Patch sieht so gut aus.

Zitat

Originally posted by Dr. Seltsam
...
Ich habe dabei in der runvdr.template einen Hinweis zur Notwendigkeit des dvbsddevice-Plugins zur Nutzung der FF-Karte als output-device aufgenommen.

Wieso? Genausogut könntest du für jedes andere Ausgabedevice einen Hinweis aufnehmen.
Wenn, dann gehört das m.E. ins INSTALL.

Klaus

Zitat

Original von kls

Wieso? Genausogut könntest du für jedes andere Ausgabedevice einen Hinweis aufnehmen.
Wenn, dann gehört das m.E. ins INSTALL.

Klaus

Die INSTALL verweist heute bereits für sämtliche Details auf die Kommentare im Script:
"See the comments inside the script for more information."
Also erschien es mir am einfachsten, dort auch (erstmalig) ein Beispiel für das Einbinden eines Plugins einzufügen. Und da hat sich dvbsddevice doch angeboten.

Aber da bin ich völlig leidenschaftslos. Es ist nur ein Vorschlag.

Zitat

Originally posted by Dr. Seltsam

Die INSTALL verweist heute bereits für sämtliche Details auf die Kommentare im Script:
"See the comments inside the script for more information."
Also erschien es mir am einfachsten, dort auch (erstmalig) ein Beispiel für das Einbinden eines Plugins einzufügen. Und da hat sich dvbsddevice doch angeboten.

Aber da bin ich völlig leidenschaftslos. Es ist nur ein Vorschlag.

Na ja, nachdem das "runvdr" sowieso eine Wissenschaft für sich ist <g> kann mir das eigentlich auch völlig egal sein. Allerdings wird der Kommentar nicht mehr stimmen, sobald es mal ein dvbhddevice-Plugin gibt.

Klaus

warum nicht einfach die runvdr zukünftig als runvdr.template führen und im makefile nur kopieren wenn eine runvdr existiert?

Zitat

Original von IG88
warum nicht einfach die runvdr zukünftig als runvdr.template führen

das macht mein Patch

Zitat

und im makefile nur kopieren wenn eine runvdr existiert?

das würde m.E. nur bei der erstmaligen Installation von vdr sinnvoll sein. Wer einmal eine individuelle runvdr erstellt hat, wird sie in seinem BINDIR liegen haben. Niemand käme dann noch auf die Idee, aus dem template eine neue runvdr im Sourcen-Ordner anzulegen und dort (vor dem make install) erneut auszufüllen.

Wenn man sowieso das template manuell als runvdr kopieren muss, dann kann man es auch gleich in das BINDIR kopieren und dort bearbeiten.

Ich habe den patch jetzt an Klaus geschickt, mal sehen was er daraus macht.

Zitat

Original von kls

In der Beziehung hat sich nichts geändert.
Es wurde lediglich der Code für den Wiedergabeteil in ein Plugin verlagert.

Klaus

Hi,

gerade getestet: Mit einer technotrend-ff (rev 1.5) & Ausgabe über xine (xineplugin als output) und dementsprechend dvbsddevice nicht geladen:

Beim ARD-Transponder konnte ich 2 Aufnahmen starten ohne Störungen. Wenn dann ein 3. Kanal geschaut wird kommen die Störungen. Den Unterschied gegenüber ff als frontend merkt man, da das OSD problemlos bedienbar bleibt.

Fazit: Eine technotrend-ff kann auch als reines Aufnahmedevice nicht mehr als 2 Kanäle mit "hoher" Datenrate verarbeiten.

Entweder ich bekomme raus wie man die Verwendung der Karten priorisieren kann, oder die technotrend-ff fliegt raus! (Der ff-HW-Umbau lohnt nicht mehr, ich will eh Richtung HD)

Grüße
Ralf

Kann jemand bestätigen, dass Aufnahmen die von 1.7.11 angefertigt wurden nicht mehr mit VLC und WMP abspielbar sind? (Getestet mit SD und HD)

Zitat

Original von Razorblade
Kann jemand bestätigen, dass Aufnahmen die von 1.7.11 angefertigt wurden nicht mehr mit VLC und WMP abspielbar sind? (Getestet mit SD und HD)

diese Vermutung habe ich hier wegen der PCR-Änderung bereits angestellt.

Dann wurde aus der Vermutung jetzt wohl Gewissheit

Habe die PCR-Änderungen aus dem 1.7.11er wieder rückgängig gemacht, also:

int Ppid = 0x1FFF; // no PCR pid
wieder durch:
int Ppid = Channel->Ppid();
ersetzt und nun kann man die Aufnahmen auch wieder mit VLC und WMP abspielen. Gab es einen bestimmten Grund warum das geändert wurde?

Gruß,
Razor

Ähm.... bei mir geht mit der 1.7.11 das Streamen von Aufnahmen (erzeugt mit vdr-1.7.0) über das Browserfenster vom Live-Plugin auch nicht. Liegt das an der vorgenannten Änderung im VDR?

Wenn ja würde ich das auch gerne zurückändern, nur wo?

Gruß
iNOB

in remux.c, bei mir am 325 (allerdings mit extension patch...)

Ganz einfach der string suchen und änderen.

Carel

Ist denn diese Änderung wirklich derart sinnvoll und notwendig, dass man deswegen diese Inkompatibilitäten mit allen relevanten Streaming und Abspielclients wie VLC in Kauf nehmen muss? Ich verstehe halt zu wenig davon, aber falls es "nur" darum geht, dass dieser Zeitstempel theoretisch gesehen in einer Aufzeichnung keinen Sinn macht, er aber sonst keine Probleme verursacht, sein Weglassen aber schon, dann würde ich ihn ja (zumindest vorerst) noch drin lassen...

Zitat

Originally posted by batDan
Ist denn diese Änderung wirklich derart sinnvoll und notwendig, dass man deswegen diese Inkompatibilitäten mit allen relevanten Streaming und Abspielclients wie VLC in Kauf nehmen muss? Ich verstehe halt zu wenig davon, aber falls es "nur" darum geht, dass dieser Zeitstempel theoretisch gesehen in einer Aufzeichnung keinen Sinn macht, er aber sonst keine Probleme verursacht, sein Weglassen aber schon, dann würde ich ihn ja (zumindest vorerst) noch drin lassen...

Der "Zeitstempel" ist nur "drin", wenn die PCR-Pid gleich der Video-Pid ist. Bei Sendern, die eine separate PCR-Pid benutzen, wird diese (traditionell nicht mit aufgezeichnet. Das Setzen der PCR-Pid auf 0x1FFF war der Versuch, dem Player zu sagen "Junge, es gibt keine PCR-Pakete, also spiel das Zeug so ab, wie es die anderen auch machen, die ohne PCR-Daten auskommen (wie etwa die FF-DVB-Karten, Kaffeine oder gxine)". Nur leider funktioniert das anscheinend nicht, da manche Player einfach stur auf PCR-Daten bestehen. In meinen Augen machen sie beim Abspielen einer Aufzeichnung keinen Sinn, da sie nicht dazu verwendbar sind, eine lokale Uhr zu synchronisieren. Das kann eigentlich nur im Live-Modus funktionieren.

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

Klaus

Besser spät als nie: Angepasste Versionen meiner Patches für VDR-1.7.11:

S2API-Wrapper Patch:
http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper

Hard Link Cutter Patch:
http://www.udo-richter.de/vdr/patches.html#hlcutter

Gruß,

Udo

Zitat

Originally posted by e9hack
Der Vdr darf nicht davon ausgehen, daß /dev/dvb/adapterX/frontendY zu /sys/class/dvb/dvbX.frontendY gehört. Udev-Regeln dürfen da umsortieren.

Und welchen Sinn macht es, wenn die udev-Regeln da "umsortieren"?

Klaus

Zitat

Original von kls
Und welchen Sinn macht es, wenn die udev-Regeln da "umsortieren"?

Ich muß für Avards wissen, welche DVB-Karte die FF ist. Bei Karten, die unterschiedliche Kernel-Module verwenden, geht das sicherlich auch anders. Wenn man zwei baugleiche FF hat, und eine spezielle davon das Ausgabe-Device werden soll, geht es eigentlich nur per fixer Zuordnung über Udev-Regeln.

Gruß
e9hack

Zitat

Originally posted by e9hack

Ich muß für Avards wissen, welche DVB-Karte die FF ist. Bei Karten, die unterschiedliche Kernel-Module verwenden, geht das sicherlich auch anders. Wenn man zwei baugleiche FF hat, und eine spezielle davon das Ausgabe-Device werden soll, geht es eigentlich nur per fixer Zuordnung über Udev-Regeln.

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?

Klaus