[ANNOUNCE] ExtP-NG für VDR-1.7.13/14/15/16

Hi Copperhead,

würdest Du bitte die angehängten rumänischen Texte mit in den Patch einfliessen lassen?

Gruß,
Lucian

Moin!

Zitat

Original von SurfaceCleanerZ
Hi,
cool,
könntest du evtl. den Dynamite-Patch berücksichtigen:
[ANNOUNCE] das dynamite-Plugin

Zitat

Original von Copperhead
ungern

Verrätst du mir, warum? Ich würde sonst gerne aushelfen, wenn es Schwierigkeiten gibt.
Ich weiß, dass es Überschneidungen mit anderen Patches gibt, den LNB-Sharing-Patch hab ich deswegen auch schon angepasst.

vdr-Patches bzgl. dynamite

Lars.

Moin!

Der Patch ist so implementiert, dass er nichts am Verhalten von vdr ändert, wenn dynamite nicht geladen ist.
Wenn du deine Bedenken weiter ausführst, finden wir vielleicht eine Lösung.

Ich persönlich brauche ihn nicht im ExtP-NG, da ich yaVDR benutze und er dort integriert ist.

Aber trotzdem Dank an deine Arbeit, ich kann mir vorstellen, was es bedeutet, so ein Sammelsurium zusammen zu basteln!

Lars.

Moin,
ich hab ein Problem mit dem ext-patch 1.7.17v1b3,
sobald ich den patch eingespielt habe startet der vdr zwar fehlerfrei, gibt auch das Live-signal wieder und das Aufnehmen funktioniert, aber es ist ein Lotteriespiel ob sich eine vorhandene Aufnahme abspielen läßt, in 5 von sechs Versuchen lande ich einfach wieder beim Live-programm.
Wenn sich die Wiedergabe starten läßt, dann sind vorhandene Schnittmarken nicht sichtbar, setze ich neue, kann ich zwar den Schnitt anstoßen, er bricht aber unterwegs mit Fehlermeldung ab.
Kann irgendwer ähnliches Verhalten beobachten?

Christoph

Das hört sich fast danach an, als wenn etwas mit den Rechten nicht stimmt, damit hätte dann aber der Patch nichts zu tun. Startest Du den vdr evtl mal als user mal als root?

Nope, kann ich ausschließen, vdr wird per script gestartet, und da sind die entsprechenden Befehle drin die das verhindern.
wenn ich einen vanilla vdr-1.7.17 ohne extpng nehme und exakt gleich starte habe ich keine probleme, dan tun alle Aufnahmen und die (vorher unsichtbaren) Schnittmarken werden fehlerfrei angezeigt.
wenn ich auf den 1.7.16-er zurückgehe geht der auch mit dem extp und zeigt alles fehlerfrei an.

PS: Status ist zwar Grünschnabel, aber ich nutze den vdr schon seeehr lange, nur hier im Portal bin ich nicht wirklich aktiv....

Stell mal versuchsweise "Jumpplay" ab. Da der VDR mittlerweile selber eine ähnliche Funktion hat (zumindest was das Lesen der Marken während Timeshift angeht) könnte das zu Konflikten führen.

Nope, hab ich schon vorher abgeschaltet gehabt.
jetzt hab ich testweise noch die letzten Teil-Patches deaktiviert, aber der beschriebene Effekt tritt immernoch auf.
(ja alles neu kompiliert und installiert, vorher sogar alle vdr-binarys und plugins gelöscht).
und im log oder auf der konsole keine Meldungen.

Hallo Zusammen

Zitat

Original von stupid-crissi
Moin,
ich hab ein Problem mit dem ext-patch 1.7.17v1b3,
sobald ich den patch eingespielt habe startet der vdr zwar fehlerfrei, gibt auch das Live-signal wieder und das Aufnehmen funktioniert, aber es ist ein Lotteriespiel ob sich eine vorhandene Aufnahme abspielen läßt, in 5 von sechs Versuchen lande ich einfach wieder beim Live-programm.

Hmm, bei mir ist es so, dass ich mit eingespieltem v1b3 (selbst wenn ich in Make.config alle Patches deaktiviere) überhaupt keine Aufnahmen abspielen kann. Mit 'Vanilla'-1.7.17 und der von mir zuletzt verwendeten 1.7.15-ExtPatch funktioniert das Abspielen von Aufnahmen reibungslos.

Ich habe mich jetzt nicht wirklich sorgfältig durch die Sourcen gewühlt, aber folgende Änderung im v1b3 ist mir ins Auge gefallen - insbesondere, da sie nicht von irgendwelchen defines abhängt und wohl mit dem Öffnen der Datei zu tun hat:

diff -ruN vdr-1.7.17/dvbplayer.c vdr-1.7.17.patched//dvbplayer.c
--- vdr-1.7.17/dvbplayer.c	2010-03-07 15:24:26.000000000 +0100
+++ vdr-1.7.17.patched//dvbplayer.c	2011-03-14 16:23:36.207062074 +0100
@@ -270,9 +270,6 @@
   dropFrame = NULL;
   isyslog("replay %s", FileName);
   fileName = new cFileName(FileName, false, false, isPesRecording);
-  replayFile = fileName->Open();
-  if (!replayFile)
-     return;
   ringBuffer = new cRingBufferFrame(PLAYERBUFSIZE);
   // Create the index file:
   index = new cIndexFile(FileName, false, isPesRecording);

Hat jemand eine Erklärung für diese Änderung?

Verwende ich 1.7.17 mit v1b3, mache jedoch diese Änderung rückgängig, d.h. füge die Zeilen wieder ein, so kann ich Aufnahmen wieder abspielen. In 1.7.15 mit ExtPatch sind diese Zeilen ebenfalls noch vorhanden bzw. werden durch den ExtPatch nicht entfernt.

Disclaimer: Ich habe mich allerdings nicht wirklich in die Sourcen hineingedacht und langwierige Tests gemacht. Vielleicht kann die Änderung ja mal jemand gegenchecken oder zumindest erklären?

HTH, Alex

Zitat

Original von Alex

Code

-  replayFile = fileName->Open();

Na ja, wenn das File nicht geöffnet wird, dann kann das schon in die Hose gehen.

Gerald

Zitat

Original von gda

Na ja, wenn das File nicht geöffnet wird, dann kann das schon in die Hose gehen.
Gerald

Dachte ich mir spontan auch. Was ich allerdings nicht verstehe - habe mich halt nicht weiter eingelesen - ist allerdings, wie es sein kann, dass es laut Christoph ab und zu doch geht und warum sonst niemand (ausser er und ich) ein Problem hat...

bye, Alex

Stimmt, warum es bei mir gelegentlich doch ging ist mir auch ein Rätsel, dürfte eigentlich nicht möglich sein.
Es sei denn da ist noch ein irgendwo im vdr verborgener Bug/Racekondition.
Ach ja, die fehlenden Schnittmarken sind auch auf so einem Weg verloren gegangen, (zeile 4762 vom Patch löscht einfach die Zeile die die einlesen sollte......)

Copperhead
keine Panik, sowas kann passieren.
Wir sind ja froh, das wir dich haben, all die Patches selbst nachzupflegen wäre für mich absolut unmöglich.
Darum ein dickes Danke für die geleistete Arbeit.

Das wurd aber auch Zeit

Mal ohne Flachs, Danke für Deine Arbeit und nur die Ruhe...

Gruß

Oliver

Auch von mir ein Dankeschön für die gute Arbeit! Leider kompiliert der b4-Patch nicht bei mir:

dvbdevice.c:296:38: Fehler: fehlender binärer Operator vor Token »USE_LNBSHARE«

Kann das jemand bestätigen, oder hab ich Murks gebaut?

Grüße, caps!