Ich frage deswegen, weil dein Fehler aus FFMPEG kommt, nicht aus VDR. Außerdem passt keine der Änderungen zu deinem Fehlerbild.
VDR Version 2.4.7
-
-
-
-
Sieht gut aus. Danke. Das mit deinen Tags der Form "V20407" war etwas lästig. "Die Regel" ist eigentlich da einfach so die Versionsnummer reinzubauen.
Wenn noch jemand den Fall hat das er eine Versionsnummer kennt und das Tag braucht:
-
Du meinst, statt "V20407" sollte es einfach "2.4.7" heissen?
Es gab aber auch mal sowas: "V10404-2" oder "V10206pre6"; das würde dann "1.4.4-2" bzw. 1.2.6pre6".
Ich könnte mein Script entsrechend ändern. Allerdings hätte das wohl zur Folge, dass man sich das komplette GIT neu holen müsste, und nicht einfach einen Update machen könnte, oder? Ich kenne mich da zu wenig mit GIT aus.
-
Sehr wahrscheinlich wäre korrekt im lokalen Repo
git tag -a v2.4.7 -m "Official release of version 2.4.7"
gefolgt von einem git push.
Aber ich stehe mit git auf Kriegsfuß.
-
Ich halte mich erstmal bisschen zurück bevor dann das Gemecker groß ist. Mein Problem hab ich erstmal gelöst mit dem Befehl von oben zum Umformatieren. Nur soviel: VDR dürfte aktuell das einzige Projekt sein das seine Releases so taggt.
Ist auch ein bisschen "Kosmetik". Aktuell würden deine ".tar.bz2", die als Snapshot vom GIT geladen werden, als "Wurzelverzeichnis" ein Verzeichnis mit dem Namen "vdr-V20407" haben. Wäre der Tag "2.4.7", dann wäre das Verzeichnis "vdr-2.4.7" und würde in etwa dem entsprechen was viele auch beim "manuellen Packen eines Releases" machen würden.
Ich würde auch das "v" weglassen. Ja, sieht man öfter. Ich frage mich aber selber wer das zuerst gemacht hat und warum das so häufig kopiert wurde.
Am besten genau so taggen wie es der VDR auch dem Nutzer anzeigt.
Eine Version wird durch ein "annotated tag" gekennzeichnet (git -a X.Y.Z -m 'Version X.Y.Z'). Dann bekommt man die, wenn man
gemacht hat auch direkt mit "git push" mit auf den Server ohne extra ein "git push --tags" zu brauchen.
"Nicht annotated" kann man dann diverse "Markierungen" machen. Die bleiben dann auch erstmal lokal und wandern nicht direkt auf den Server.
Und was das "neu runterladen" angeht: Das Tag hängt "extern" am Commit. Ein Commit kann sogar mehrfach getaggt werden. Solange sich also nur die Tags ändern würde sich am Repo selbst nichts verändern. Auch alle Commit-IDs müssten gleich bleiben.
-
Ich habe das jetzt mal testweise nach http://git.tvdr.de/?p=test.git so eingespielt.
M-Reimer passt das so?
-
Für mich passt das so. Wie erwartet sind die Commit-IDs gleich geblieben. Ist also faktisch das gleiche GIT bis eben auf die Tags.
Für "offizielle Release-Downloads" halte ich den Link auf deiner "Downloads"-Seite noch für etwas optimierungsfähig. Wäre schon schöner da sowas wie
http://git.tvdr.de/?p=test.git…h=refs/tags/2.4.7;sf=tbz2
zu haben. Gibt dann ein "vdr-2.4.7.tar.bz2" das runtergeladen wird und auch das Wurzelverzeichnis heißt "vdr-2.4.7". Würde aber erfordern das du die Ausgabe von "git tag" vorparst um da die letzte "Release-Version" manuell reinzubauen. Also das letzte Tag das an der "mittleren Stelle" eine gerade Zahl hat.
-
Ich habe das veränderte GIT jetzt unter vdr.git eingespielt und test.git wieder entfernt.
Den Download-Link zur Stable-Version habe ich auch entsprechend geändert.
-
Schön, jetzt kann man vdr-2.4.7.tar.bz2 mit http://git.tvdr.de/?p=vdr.git;…h=refs/tags/2.4.7;sf=tbz2 runterladen
Gibt's den Link auch auf der Seite und ich habe ihn noch nicht gefunden?
-
Schön, jetzt kann man vdr-2.4.7.tar.bz2 mit http://git.tvdr.de/?p=vdr.git;…h=refs/tags/2.4.7;sf=tbz2 runterladen
Gibt's den Link auch auf der Seite und ich habe ihn noch nicht gefunden?
-
Ahh, Danke, da war noch die alte Seite im Browser-Cache
-
Kein fix für das: SVDRP vdr1 < 127.0.0.1:40510 lost connection to client .
-
Da das Problem, so wie das verstanden habe, eher selten auftritt, habe ich es auf meiner TODO-Liste weiter hinten eingetragen.
Ich muss mir das erst noch genauer anschauen.
-
Ich habe gerade eine Aufnahme geschnitten und da lief die Platte voll. Es gab auch eine rote Meldung "Bearbeitung gescheitert", aber die Aufnahme wurde nicht gelöscht. Früher (tm) wurde die unvollständige Kopie immer entfernt...
Mir war das schon vor längerer Zeit mal aufgefallen, das ist also nicht erst seit 2.4.7. so, hatte es aber verdrängt.
-
Ich hatte das immer auf den Undelete-Patch geschoben, aber offenbar ... Kernfunktion.
Ist das dann auch der Grund, warum bei einer einmal vollen Platte, auch wenn man (unvollständige) Aufnahmen gelöscht hat, die *.del Verzeichnisse nicht mehr abgeräumt und freigegeben werden?
(Muß die dann ggf. per Undelete-Patch-Funktion oder SSH "richtig" löschen).
Stefan
-
Bei mir werden die wieder frei gegeben, aber es dauert etwas (10 min?), da der VDR die Aufnahmen immer verzögert löscht.
-
Ich habe gerade eine Aufnahme geschnitten und da lief die Platte voll. Es gab auch eine rote Meldung "Bearbeitung gescheitert", aber die Aufnahme wurde nicht gelöscht. Früher (tm) wurde die unvollständige Kopie immer entfernt...
Da fehlte wohl eine 'error'-Abfrage:
Diff
Alles anzeigen--- recording.c 2021/06/20 10:03:28 5.11 +++ recording.c 2021/06/21 10:51:42 @@ -1968,9 +1968,12 @@ void cRecordingsHandlerEntry::Cleanup(cRecordings *Recordings) { if ((usage & ruCut)) { // this was a cut operation... - if (cutter) { // ...which had not yet ended - delete cutter; - cutter = NULL; + if (cutter // ...which had not yet ended... + || error) { // ...or finished with error + if (cutter) { + delete cutter; + cutter = NULL; + } cVideoDirectory::RemoveVideoFile(fileNameDst); Recordings->DelByName(fileNameDst); }
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!