Posts by kfb77

    Fix ist im git im Branch V02, bitte testen.

    Der Bug war, dass ich die timebase für den Video Stream falsch gesetzt habe. Das war ffmpeg < 4.3 egal, es hat halt einen Fehler gebracht, den ich ignoriert habe, da ich den Video Stream eh nicht decode/encode sondern nur an den iFrame Grenzen kopiere. Ab 4.3 erzeugt der ungültige Wert einen Crash in ffmpeg.

    Vielen Dank für den Hinweis auf den Bug.

    Glaube ich nicht, der timebase error kommt aus dem Video Stream, nicht aus Audio. Vermutlich ist eine generelle ffmpeg Änderung die Ursache, die irgendwo in 4.3.x rein gekommen ist. Solche Änderungen sind laufend ein Thema, der markad Decoder ist voll von Compiler Direktiven, abhängig von den ffmpeg Versionen.

    Post mal bitte noch die Ausgabe von ffmpeg, damit ich dann gleich die richtige libavcodec Version rein machen kann.

    Ich ziehe die letzte Frage zurück, ich kann dein Problem mit der originalen VDR Datei und ffmpeg 4.3.2 unter Debian bullseye reproduzieren. Mit 4.2.4 unter Ubuntu 20.04 läuft es. Ich mache mich morgen dran ...

    Ok, was ich noch festhalten will, ist, daß ohne "--cut" der markad in diesen Fällen zu funktionieren scheint, der "timebase"-Fehler erscheint erst mit dem cut.

    Ja klar, der Crash kommt vom encoder und der wird nur bei --cut verwendet.



    Ich versuche es mal ohne "saveinfo"

    Das wird an dem Problem nichts ändern, das war nur als "Tipp am Rande" gedacht.


    Gegen welche Datei lässt du denn markad laufen ? 0000x.ts nach naludump, oder ?

    Die Version 3.0.6 läuft bei mir sowohl mit Tntnet 2.2 wie auch mit Tntnet 3.0 ohne irgendwas umbenennen zu müssen. Ich vermute auch, du hast irgendwelche Reste drauf. Am besten alles Tntnet, cxxtools und live (auch alle Header) löschen und eine Version neu installieren.

    Das ist mein Lieblingssender, wenn du damit ein Problem hast, habe ich die Aufnahme bestimmt ;-)

    Meine marks zu der Sendung sieht fast identisch aus, nur ca. 10s versetzt. Auch --cut läuft ohne Probleme. Sogar das "*" Thema ist bei mir gleich.

    Code
    1. 0:03:34.07 aspectratio change from 16:9 to 4:3 (5352)
    2. 0:04:52.23 aspectratio change from 4:3 to 16:9 (7330)*
    3. 0:10:48.18 aspectratio change from 16:9 to 4:3 (16217)*
    4. 0:31:30.22 aspectratio change from 4:3 to 16:9 (47271)
    5. 0:38:34.10 aspectratio change from 16:9 to 4:3 (57859)*
    6. 0:56:38.16 aspectratio change from 4:3 to 16:9 (84965)

    Ok, ich werde eine komprimierte Version irgendwo hochladen

    Das können wir uns sparen, wenn deine Aufnahme auch FTA ist, dann habe ich ja die Aufnahme und die läuft bei mir, auch mit --cut.


    Wenn ich vor naludump oder ggf. Vereinigung von 0001/0002 etc. das markad laufen lasse, stimmen die Indizes dann wieder nicht hinterher und er schneidet ggf. an den falschen Stellen?

    Jetzt wird es kompliziert:

    1. markad ist der vdr index egal, er verwendet ihn nicht, er baut intern einen eigenen Index auf. In der marks stehen für vdr relevant nur offset Zeiten in Sekunden, Rest (auch die Framenummern) ist Kommentar

    2. naludump dürfte eigentlich die Zeiten nicht verändern (reine Vermutung, habe das Programm nie verwendet)

    3. Vereinigung der 0000x.ts Dateien verändert auch keine Zeiten (hoffentlich, nicht getestet). Gehe auf Nummer sicher und spare dir den Schritt und drehe in der VDR Einstellung die maximale Filegröße der Aufnahme hoch.

    2. Wenn du die VDR 0000x.ts manipulierst (egal mit was) musst du eh den VDR index neu erzeugen.

    Könnte also auch umgekehrt funktionieren.

    Das sind ja viele Punkte, ich versuche die mal thematisch zu strukturieren.

    Mir fällt dabei und bei anderen ähnlichen Vorkommnissen meist auf, daß die Sternchen "ungerade" sind

    "*" ist Bestandteil vom Kommentar Feld und bedeutet: das ist eine Start Marke. Hat aber keine funktionale Bedeutung, ist nur für mich zum besseren Lesen der Marken. Somit kommt normalerweise immer eine Zeile mit "*" und eine Zeile ohne "*", außer: wenn im VDR Info File eine falsche aspect ratio Information steht. Das erkenne ich dann am Ende des Start Abschnitts und die bis dahin (falsch) erkannten Stop/Start werden invertiert. Da das "*" nur ein Kommentar ohne Bedeutung ist, korrigiere ich in den Kommentar nicht. Ich war mir sicher, das merkt eh nie einer ...

    Deine Marks sehen genau nach so einem Fall aus und scheinen sinnvoll und korrekt aus (ohne die Aufnahme zu kennen).

    Fri Mar 5 19:02:33 [1342376] ERROR: segmentation fault

    Egal was du da gemacht hast, einen Crash darf es nicht geben. Und schon gar nicht "öfters". Hier läuft was grundsätzlich schief. Kannst du mir ein tar auf das Aufnahmeverzeichnis machen und per PM einen Download Link senden ? Die Serie habe ich zufällig auch aufgenommen, bei mir läuft die problemlos. Aber ich vermute mal, die Aufnahme ist nicht FTA wie bei mir.

    Ein vdr-checkts für das Verzeichnis liefert 0 errors.

    Grundsätzlich habe ich den Anspruch, dass eine etwas kaputte Aufnahme noch im Rahmen des Möglichen bearbeitet wird, aber selbst eine total kaputte Aufnahme nicht zum Crash führt. vdr-checkts liefert hier auch nur, ob komplette Frames fehlen, nicht aber fehlerhafte vorhandene Frames. Die würden aber auch im markad Log stehen (AvLog ...).



    --saveinfo

    Lass den mal lieber weg, der Rest passt. Den gibt es in markad schon immer, aber grundsätzlich gefällt es mir nicht, damit eine VDR interne Datei neu zu schreiben. Hat aber nichts mit deinem Problem zu tun.



    Ich verwende ein Script, welches nach der h264-Transcodierung und/oder naludump einen Markad-Lauf mit --cut durchführt

    Die Reihenfolge gefällt mir nicht. markad geht von einer originalen VDR Datei aus. Vielleicht ist das sogar die Ursache des Problems. Zuerst markad und dann deine Scripts wäre mir lieber.

    Die SDT Syslog Meldung wurde hier eingeführt um tuning Probleme an Unicable zu erkennen und zu re-tunen. Die Frage bleibt aber, warum das bei vielen Usern so oft notwendig ist.

    Ich habe von den Meldung auch eine Menge im Syslog.


    Keine Empfangsprobleme, Stichproblem mit vdr-checkts zeigt immer 0 Fehler.

    Empfang über OctopusNet-8 an Unicabel. Normalerweise 2 VDR (yavdr ansible unter Ubuntu 20.04 virtuell im LXC Container) aktiv, einer mit 4 Devices (produktiv) und einer mit 2 Devices (Entwicklungs-VDR).


    Ich vermute, die kommen vom EPG-Scan

    Das vermute ich auch.

    Edit: Dir häufigen Kanalwechsel kommen vom EPG-Scan, die Frage ist, warum so häufig der Kanalwechsel nicht funktioniert ?

    Die Version 2.6.4 ist auf vdr-plugin-markad verfügbar.

    Sie enthält nochmals Optimierungen und Fehlerkorrekturen der in 2.6.0 eingeführten neuen Funktionen.

    Zusätzlich wird jetzt auch erkannt, wenn vor dem eigentlich Logo der Titel der Sendung mit einem Play Symbol statt dem Logo kommt.

    Die gleiche Fragestellung hatte in der Zeit meiner Patch Sammlung auch ein paar mal.

    Zum Beispiel macht die "mark new recording" Funktion keinen Sinn für User, die Aufnehmen, Anschauen und dann löschen. Für andere schon ...

    Ev. müsste man das konfigurierbar machen.

    So habe ich das damals auch gelöst.

    Ich habe die Tntnet30 Änderungen mit Tntnet20 getestet und auch keine Probleme feststellen können. Somit auch von mir an MarkusE das GO für den merge.

    Das habe ich bereits. Das meinte ich mit dem o.g. Post. OK, ist natürlich Tntnet 2.2 und nicht Tntnet 2.0, was in Ubuntu focal dabei ist.

    Der Tntnet30 Branch läuft bei mir jetzt seit einer Woche auf meinem produktiven VDR mit Tntnet 2.2 ohne Probleme.

    Die meisten Änderungen sind eh in Compiler Direktiven gekapselt und wirken nur, wenn man gegen die libs von Tntnet30 kompiliert..

    Ja, damit ist es mir auch nicht gelungen. Aber mein Verdacht war richtig, du kannst den Crash "mit Gewalt" erzeugen, indem du einen Timer aus der Programmübersicht erstellst und vor dem Speichern im Browser die letzte Stelle der URL löscht um eine ungültige Event ID zu erzeugen. Beim Speichern kommt dann genau dein Crash. Man sollte besser Pointer auf NULL überprüfen bevor man sie verwendet ...

    Fix ist im Branch Tntnet30, Branch crash ist gelöscht.

    Das wird eine schwierige Nummer ...

    Ich vermute, der Crash hat gar nichts mit Tntnet30 zu tun.

    Code
    1. eventTimer = std::unique_ptr<cTimer> = {get() = 0x0}

    Der Crash ist im VDR selbst, die Ursache ist vermutlich aber der o.g. NULL Pointer in edit_timer.ecpp:138.

    Kann es sein, dass du beim Zurückblättern einen Timer editiert hast, dessen EPG Event bereits abgelaufen war ?

    Installiere mal den Branch "crash" vom git und versuche den Crash nochmals hinzubekommen.

    Falls mein Verdacht stimmt, dann müsste im syslog "live: edit_timer.ecpp eventid ... not valid" stehen.