Posts by kfb77

Auch markad hat ein Problem mit Ubuntu 22.04, genauer gesagt mit dessen ffmpeg Version.

Wenn man --cut und --fullencode nutzt, ist die MP2 Tonspur weg. Somit:

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

Habe es getestet, funktioniert.

Ich selbst werde aber wegen der LXC Probleme von maraidb die epgd Funktion in einen eigenen Container legen und den vorerst bei 20.04 belassen. Das ist sind mir zu viel Workarounds.

Also nichts, was man im VDR Universum fixen könnte.

Und es gibt noch ein Problem mit mariadb unter Jammy, wenn man es, wie ich, im LXC Container laufen hat.

Hier die Infos dazu, auch ein Workaround ist dort beschrieben.

epgd macht auch Probleme unter Jammy, da ist irgendwas schief mit dem Plugin Verzeichnis:

Das Plugin ist da:

Aber mariadb will es wohl jetzt woanders:

Von Hand bauen nutzt auch nichts, weil selbst mariadb_config den falschen Pfad liefert:

Link in das richtige Verzeichnis umgeht erfolgreich das Problem.

Das kann ja aber nicht die finale Lösung sein. Hat jemand eine Idee, wie man das sauber lösen kann ?

Problem ist gelöst, danke.

seahawk1986

ich habe ein seltsames Problem: Mein Test VDR unter Ubuntu 22.04 mit vdr aus deinem Jammy Respository crashed beim Aufruf von "vdr --version". Nur da, sonst läuft er.

Ich konnte es eingrenzen auf das epg2vdr Plugin. Der Fehler ist weg, wenn ich es aus deinen Sourcen neu baue. Ist da was beim Build schief gegangen ???

MarkusE : Bitte prüfen und übernehmen.

Der Timer ist noch da, wird aber durch die Änderung inaktiv. Das tritt beim Ändern von laufenden Aufnahmen auf, da Live das Flag für "laufende Aufnahme" nicht setzt.

Fix ist hier im git von MarkusE , bitte testen.

Es sind zwei Probleme und zwei Lösungen:

Im "copy" Branch ist der Bug behoben, dass mit tntnet 3.0 das Kopieren einer Aufnahme nicht funktioniert.

Um das ungewollte Überschreiben von bestehenden Aufnahmen beim Rename zu verhindern (egal welches tntnet), braucht es zusätzlich noch das.

SurfaceCleanerZ wrote:

Nur das Tool kann es, das Plugin bisher nicht.

Ist auch nicht geplant, weil sich dadurch die Laufzeit von markad deutlich erhöht und somit der shutdown blockiert werden würde.

Scheiden geht mit dem zusätzlichen Parameter --cut beim Aufruf von markad.

sk001 wrote:

hat man eigentlich keine Chance mehr, auf die ungeschnittene Version zurückzukommen

Die originale Datei bleibt unverändert, es wird eine neue Datei erzeugt, die dann aber nur außerhalb VDR abgespielt werden kann. Wer es innerhalb VDR nutzen will, nutzt die VDR Schnittfunktion, auch dabei bleibt die originale Datei erhalten.

seahawk1986 wrote:

Das vdr-plugin-dbus2vdr bietet ein nulldevice an

Wozu braucht man das ? Mein VDR läuft als reiner Backend ohne das alles.

Du hast Recht, das Beispiel war "quick and dirty".

Der move sieht auch so aus (andere Aufnahme):

heifisch wrote:

Nein, das passiert gerade eben nicht!

Die Posts haben sich überschnitten, das habe ich inzwischen auch erkannt.

kamel5 wrote:

dann wird in diesem Fall "1ARD-Buffet" in das Verzeichnis "ARD-Buffet" verschoben und nicht gelöscht.

Was aber im Falle vom VDR meist das gleiche ist, weil ja die Dateinamen gleich sind. Höchstens mehr/weniger *.ts Files.

heifisch : Und genau in so einem Fall würde deine Änderung ein unbeabsichtigtes Ergebnis erzeugen: Wenn der originale Inhalt des Verzeichnises mehr ts Files hat, würden die mit den höheren Nummer stehen bleiben und nicht zur neuen Aufnahme passen.

Edit: Stimmt nicht, der move wird ja nicht gemacht, weil er auf einen Fehler läuft. Müsste funktionieren. Mal sehen, was MarkusE dazu meint.

heifisch wrote:

Klar, aber sollte sich ein GUI so verhalten?

Nein, nicht unbedingt, da gebe ich dir Recht. Das ist aber kein Bug, sondern ein Feature Request mit html Anteil. Und das fasse ich mangels KnowHow nicht an.

heifisch wrote:

Wenn ich jetzt "1ARD-Buffet" in "ARD-Buffet" umbenenne, verliere ich eine Aufnahmen.

Ja klar, das ist genau das, was im Filesystem auch passiert.

Mit "mv 1ARD-Buffet ARD-Buffet" ist auch 1ARD-Buffet weg, egal, ob es gleich war, oder nicht.

heifisch wrote:

Wozu ist die 0 vor dem .rec?

Das ist die VDR Instance, default ist 0.

Damit verschiedene Namen garantiert sind wenn mehrere VDRs auf den gleichen Storage schreiben.

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

Ich habe es gefunden: In deiner Konstellation gibt es nach dem rename einen redirect auf den delete. Damit ist die Aufnahme weg.

Was der redirect in einer anderen Konstellation möglicherwiese für einen Sinn hat, konnte ich nicht raus bekommen. Wenn man ihn raus nimmt, funktioniert es. Getestet mit tntnet 2.1 und tntnet 3.0.

Fix ist hier, bitte ausgiebig alle Funktionen von Live testen bevor MarkusE das übernimmt. Vielleicht habe ich noch was übersehen, wofür es diesen redirect im Code gibt.

Das VDR Log vom rename direkt nach dem delete über Live bestätigt genau das, was wirklich passiert: Umbenennen der Aufnahme (1ARD-Buffet -> ARD-Buffet) entfernen der vorher gelöschten Aufnahme (*.del) und dann fälschlicherweise auch das löschen der umbenannten Aufnahme. Ich suche noch ...

Ich habe mir das mal angeschaut, es gibt sogar zwei Probleme:

1. unter tntnet 3.0 funktionieren die Checkboxen in edit_recording nicht, somit u.a keine Funktion, um eine Aufnahme zu kopieren. Fix ist bei MarkusE  hier im git. heifisch : bitte testen.

2. Das von dir beschriebene Problem tritt entgegen meiner obigen Aussage auch unter tntnet 2.1 auf, selten geht es aber auch. Scheint ein timing Problem zu sein. Hier habe ich noch keine Idee, an was das liegen könnte. MarkusE : bitte schaue auch mal rein, ob du dafür eine Ursache sehen kannst.