[ANNOUNCE] VDR developer version 1.7.21

Gabs es nicht mal eine Option "Aufzeichnung nach Schneiden löschen" oder irre ich da jetzt?

Zitat von Mreimer

Ich werde mal bei Gelegenheit durch den Code schauen, wo man hingreifen müsste. Es sei denn kls bringt schneller einen Fix.

VDR würde das tatsächliche Löschen sowieso nicht machen, solange ein Schnitt aktiv ist.
Aus vdr.c:

if (... && !cCutter::Active() && ...) {
           ...
           // Disk housekeeping:
           RemoveDeletedRecordings();
           ...
           }

Ich vermute den Fehler eher darin, daß das Verzeichnis von *.rec nach *.del umbenannt wurde, der Cutter aber, wenn die Aufzeichnung aus mehreren *.ts-Dateien besteht, diese ja immer unter dem *.rec-Namen sucht.
Wie gesagt, abstürzen sollte er dabei natürlich nicht, aber wirklich funktionieren kann das eigentlich auch nicht.

Klaus

Zitat von kls

VDR würde das tatsächliche Löschen sowieso nicht machen, solange ein Schnitt aktiv ist.

Das ist dann ja schonmal positiv.

Zitat

Ich vermute den Fehler eher darin, daß das Verzeichnis von *.rec nach *.del umbenannt wurde, der Cutter aber, wenn die Aufzeichnung aus mehreren *.ts-Dateien besteht, diese ja immer unter dem *.rec-Namen sucht.

Frage ist dann als nächstes, ob das mit erträglichem Aufwand gefixt werden kann.

Zitat von Mreimer

[quote='kls','index.php?page=Thread&postID=1024709#post1024709']
Frage ist dann als nächstes, ob das mit erträglichem Aufwand gefixt werden kann.

Der Fix wird wohl so aussehen, daß das Löschen der Aufnahme abgelehnt wird, solange ein Cutter für diese Aufnahme aktiv ist.

Klaus

Zitat von TheChief

Gabs es nicht mal eine Option "Aufzeichnung nach Schneiden löschen" oder irre ich da jetzt?

Oder eben solch eine Option in den Einstellungen. Fänd ich auch nicht verkehrt.

Zitat von TheChief

Oder eben solch eine Option in den Einstellungen. Fänd ich auch nicht verkehrt.

Ich weiß nicht recht. Ein Automatismus, der die Originalaufnahme löscht, hat für mich irgend etwas "gefährliches". Was, wenn dabei was schiefgeht und das Original gelöscht wird obwohl der Schnitt nicht geklappt hat?

Klaus

Im Extensions Patch für den 1.6er (siehe Signatur) ist diese Funktion im Cutterqueue Patch mit drin. Und zumindest sagt der Quellcodekommentar
---
/* Remove original (if cutting was successful) */
---
sieht auch gar nicht so wild aus. Also wers haben will... (ich überprüfe auch generell vor dem löschen des Orginals ob der Schnitt erfolgreich war. Das automatische löschen ist mir da auch zu automatisch)

Wobei es doch eh eher egal ist was der VDR hier macht, die meisten dürften das extrecmenu verwenden. Und vermutlich greift das dann eh nicht (weils das Plugin eh selber macht). Also fällt es den meisten vermutlich eh nicht auf

cu

Was wäre denn, wenn man die letzten beiden Vorschläge zusammenfasst? Ein Löschen einer Aufnahme während des Schnitts markiert diese nur als gelöscht in $VARIABLE. Hier kann dann ggf. kurz im OSD sowas wie "Aufnahme wird nach Ende des Schnittvorganges gelöscht" erscheinen. Wenn der Schnitt erfolgreich durch ist, dann wird geprüft ob $VARIABLE gesetzt ist und ggf. die dort vermerkte Aufnahme gelöscht. Wahrscheinlich kann man so eine Info direkt in eine Eigenschaft des Cutters schreiben. Falls beim Schneiden was schiefgeht (crash, ...), dann verfällt nur die Info über die zu löschende Aufnahme. Scheint mir durchaus mit erträglichem Aufwand lösbar.

Von so einer Lösung hätte jeder was:
- "Löschen während des Schneidens" ist möglich
- Aufnahme wird nur gelöscht, wenn Schnitt erfolgreich
- Es können auch gezielt Aufnahmen nicht gelöscht werden (ich nutze das z.B. um gezielt eine Aufnahme in mehrere Aufnahmen zu zerlegen)
- Programmieraufwand scheint mir gering, da nach Ende des Schnitts nur ein normaler Löschvorgang zu triggern wäre

Wie schon geschrieben hat bei einigen Aufnahmen das Löschen während dem Schneiden durchaus funktioniert. Fände es schade, wenn ich nun erst auf das Ende des Schnitts warten müsste, um dann erneut durch das Aufzeichnungs-Menü zu gehen. Habe dieses "Feature" irgendwie lieb gewonnen. Wäre schön wenn man hier einen gemeinsamen Nenner für eine "richtige" Lösung finden könnte. Ich würde dann versuchen das als Patch umzusetzen.

Zitat von Keine_Ahnung

Im Extensions Patch für den 1.6er (siehe Signatur) ist diese Funktion im Cutterqueue Patch mit drin. Und zumindest sagt der Quellcodekommentar
---
/* Remove original (if cutting was successful) */
---
sieht auch gar nicht so wild aus. Also wers haben will... (ich überprüfe auch generell vor dem löschen des Orginals ob der Schnitt erfolgreich war. Das automatische löschen ist mir da auch zu automatisch)

Wobei es doch eh eher egal ist was der VDR hier macht, die meisten dürften das extrecmenu verwenden. Und vermutlich greift das dann eh nicht (weils das Plugin eh selber macht). Also fällt es den meisten vermutlich eh nicht auf

cu

Alles anzeigen

Ich prüfe meine geschnittenen Aufnahmen auch nochmal vor dem Löschen. Deswegen brauche ich kein automatisches Löschen. War nur ne Anregung für die Leute, die das brauchen. Und ich meine eben auch, dass es die
Option irgendwo und irgendwann mal gegeben hat. Nutze auch den Cutterqueue Patch, eventuell war es da mit drin. Habs nur nicht mehr gefunden.

Irgendwie habe ich ein Problem mit der CUTTIME-Funktion:
Ich habe gestern einen Film gleichzeitig in SD und HD aufgenommen und nach dem Schneiden ist die Startzeit von SD (576i, 25fps) und HD (720p, 50fps) unterschiedlich: Aufnahmebeginn war jeweils 20:09, nach dem Schneiden ist der Beginn bei SD 20:15, bei HD: 20:12. Schnitte an anderen Punkten zeigen, dass bei HD nur die Hälfte der Dauer auf die die Startzeit draufgerechnet wird, d.h. Schnittbeginn bei exakt 2h ergibt eine Startzeit von +1h.
ffmpeg -i sagt mir zur HD-Aufnahme:
Stream #0.0[0x177a]: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc, die 50fps in der info-Datei sind also ok
Ein eingefügtes isyslog in cutter.c direkt vor SetStartTime zeigt, dass auch dort fps=50 von der ungeschnittenen Aufnahme ankommt.
Gemacht wurden beide Aufnahmen mit VDR 1.7.18 (inkl. cuttime patch), das Schneiden mit VDR 1.7.18 (inkl. cuttime patch) und mit VDR 1.7.21 bringt das gleiche Ergebnis, auch nach dem index-Neugenerieren.
Achja, die Längen der Aufnahmen werden übrigens korrekt angezeigt und das vdr-checkts bringt 0 Fehler ...

[Edit] in cutter.c Zeile 213 steht nur: FromMarks.Load(FileName);
müsste da nicht FramesPerSecond und isPesRecording mitgegeben werden, so wie in Zeile 302: Marks.Load(FileName, Recording.FramesPerSecond(), Recording.IsPesRecording()) ?? [/Edit]
[Edit2]Ja, das müsste so aussehen:
FromMarks.Load(FileName, Recording.FramesPerSecond(), Recording.IsPesRecording());
Damit gehts.
[/Edit2]

Copperhead: Warum hast du eigentlich aus deinem ext-patch fuer vdr 1.7.21 den wareagle patch entfernt?

Zitat von HALLO01

Copperhead: Warum hast du eigentlich aus deinem ext-patch fuer vdr 1.7.21 den wareagle patch entfernt?

Hier gibt nen Thread zum WarEagle Patch:
Suche Patches für VDR 1.7.21

HI,

für alle die, die es gebrauchen können. 3+ Patche für vdr 1.7.21

Bitte in dieser Reihenfolge patchen:
http://www.minidvblinux.dyndns…3/vdr/branches/natty/src/

10_vdr-1.7.21_dynamitelnbshareunicable.patch
11_vdr-1.7.21_extpngv2_mld.patch ---> Dank auch an Copperhead "es sollten alle inkludierten Patche funktionieren"
12_vdr-1.7.21_livebuffer.patch

Extpngv2 (inkludierte Patche)

#ALTERNATECHANNEL = 1
#CHANNELBIND = 1
#CUTTERLIMIT = 1
#DDEPGENTRY = 1
#DVLVIDPREFER = 1
#GRAPHTFT = 1
#HARDLINKCUTTER = 1
#JUMPPLAY = 1
#LIEMIKUUTIO = 1
#LIRCSETTINGS = 1
#MAINMENUHOOKS = 1
#MCLI = 1
#MENUORG = 1
#NOEPG = 1
#PINPLUGIN = 1
#PLUGINMISSING = 1
#ROTOR = 1
#SETUP = 1
#TIMERINFO = 1
#WAREAGLEICON = 1
#YAEPG = 1

Ich habe in letzter Zeit ehr andere Probleme als den Extension Patch.

Ich habe mich jetzt informiert, wie und was ich machen muss, aber wenn man da sieht, dass Unicable, Dynamite und LNBShare untrennbar verbunden sind, bereitet mir das schon große Kopfschmerzen.

Moin!

Zitat von Copperhead

Ich habe mich jetzt informiert, wie und was ich machen muss, aber wenn man da sieht, dass Unicable, Dynamite und LNBShare untrennbar verbunden sind, bereitet mir das schon große Kopfschmerzen.

Das hat den Vorteil, dass sie miteinander funktionieren. Und dieser Patch wird von vielen benutzt und noch gab's keine Probleme damit.
Wenn keins von ihnen konfiguriert/aktiviert ist, haben sie auch keinen Einfluss auf das Standardverhalten des vdr. Darauf hab ich geachtet (darf aber gerne überprüft werden, je öfter, desto besser).

Oder du wartest bis 1.7.22, dann wird der Unicable- und LNB-Sharing-Patch überflüssig. Ich hoffe, es dauert nicht mehr zu lang... Dann wird nicht nur für dich die Arbeit leichter.

Lars.

Das Unicable überflüssig wird wusste ich schon. Aber woher stammt das mit dem LNBShareing ?

Zitat von Copperhead

Das Unicable überflüssig wird wusste ich schon. Aber woher stammt das mit dem LNBShareing ?

Von mir

Bin aber noch am testen. Da ich selber weder Unicable ("SCR") noch LNB-Sharing ("Device bonding") im Alltagsbetrieb verwende, kann ich Tests immer nur am Wochenende mit einem speziellen Setup machen. Sieht aber inzwischen schon recht gut aus. Werd's freigeben, sobald es aus meiner Sicht stabil ist. Den endgültigen Alltagstest müssen dann natürlich diejenigen machen, die das tatsächlich benutzen.

Klaus

Klingt ja toll. Du hattest mir mal geschrieben, dass du Patches von Rolf Ahrenberg bekommen hast.

Was genau umfasst das denn? Bzw. wieviel Liemkuutio wird dadurch überflüssig?

Zitat von Copperhead

Klingt ja toll. Du hattest mir mal geschrieben, dass du Patches von Rolf Ahrenberg bekommen hast.

Was genau umfasst das denn? Bzw. wieviel Liemkuutio wird dadurch überflüssig?

Kann ich schlecht sagen da ich "Liemkuutio" (was immer das heißen mag) nicht kenne.

Ich habe einige seiner Patches übernommen, andere folgen noch, wiederum andere kommen erst nach der Version 2.0.

Klaus

Zitat von kls

Kann ich schlecht sagen da ich "Liemkuutio" (was immer das heißen mag) nicht kenne.

Hehe, das kann man m.E. mit Suppenwürfel übersetzen, rofafor hat einen sehr interessanten Humor ...

Aber die Kleinigkeiten des Patches haben den VDR viele Jahre lang durchaus sinnvoll erweitert. rofafor wußte glaube ich bis vor kurzem gar nicht wie "wichtig" und verbreitet der seit vielen Jahren war.

Gruß
Frank