Posts by SHofmann

  • Titel der aktuellen Sendung/Wiedergabe abfragen

    Ich habe mir den Stand der Dinge nochmals genauer angeschaut. Wenn ich meine Aufzeichnungen aufliste, erhalte ich unter anderem diese:

    Code
    [BASH 2010] svdrpsend LSTR | grep Stowaway
250-6014 11.01.26 22:15 2:50 Stowaway - Blinder Passagier
250 5934 11.01.26 22:25 1:42* %Stowaway - Blinder Passagier

    Starte ich die Wiedergabe von #5934, erhalte ich:

    Code
    [BASH 2011] svdrpsend PLAY
220 HTPC SVDRP VideoDiskRecorder 2.7.7; Tue Jan 13 13:00:48 2026; UTF-8
250 5934 11.01.26 22:25 %Stowaway - Blinder Passagier
221 HTPC closing connection

    Eigentlich fände ich es am besten, wenn die Ausgabe in beiden Fällen identisch wäre:

    Code
    250 5934 11.01.26 22:25 1:42* %Stowaway - Blinder Passagier

    Das würde eine Verarbeitung der Ausgaben vermutlich vereinfachen, weil vereinheitlichen. Auch müsste man nicht noch eine weitere Abfrage durchführen, wenn man die Länge der gerade abgespielten Aufzeichnung wissen möchte.

    Sorry, dass ich gestern keine Zeit mehr hatte, mir das gleich genauer anzuschauen.

  • Titel der aktuellen Sendung/Wiedergabe abfragen

    Im Prinzip ja. Doch wenn man die Ausgabe hiermit vergleicht:

    Code
    [BASH 2112] svdrpsend chan
220 HTPC SVDRP VideoDiskRecorder 2.7.7; Mon Jan 12 16:41:29 2026; UTF-8
250 47 ntv
221 HTPC closing connection

    … (also nur ID und Titel), sollte es dann analog nicht eher so aussehen:

    Code
    250 121 16.04.24 20:15 Serien~Mord mit Aussicht~Mord mit Aussicht (46) - Furcht und Schrecken

    … sprich: "%d %s %s %s", id, date, time, filename?

  • [live] Weiterentwicklung 3.5.*

    Bei ein paar ersten Interaktionen konnte ich keinen (spürbaren) Unterschied feststellen.

    Im Code haben sich an einigen Stellen ein paar Typos eingeschlichen. Außerdem fände ich es günstiger, wenn in stringhelpers.h der Test auf Kontrollzeichen und Space ("remove all ASCII <= 32 from left and right") auch in den Schleifen einheitlich als Test auf 32 (bei Zeichencodes eigentlich bevorzugt in Hex-Notation, also 0x20) anstatt abwechselnd auf 32 und 33 ausgestaltet wäre.

    Wenn du die genannten Korrekturen übernehmen möchtest:

  • [Solved] Update auf neueste Plugin-Versionen

    Wie gesagt, bei mir ist das ein permanent laufender Prozess. Bei EPGsearch und Live sollte eigentlich alles passen. Bei MarkAd würde ich mal die History überprüfen, da hat sich bei den Aufrufparametern eine Änderung ergeben ("declare parameter --extractlogo as deprecated"). Bei StreamDev hat sich sowieso seit Ostern 2024 nichts mehr getan.

  • [live] Weiterentwicklung 3.5.*

    Im Header heißt es:

    Code
    msgstr ""
"Project-Id-Version: VDR-LIVE 3.5.3\n"
"Report-Msgid-Bugs-To: <cwieninger@gmx.de>\n"
"PO-Revision-Date: 2007-08-19 20:15+0200\n"

    Ich verstehe das so, dass unter Project-Id-Version das Projekt und dessen Versionsnummer eingetragen sein soll, zu der die PO-Datei mir ihren msgid-Strings gehört. Anders gesagt, soll die Kollektion der msgid-Strings mit dem angegeben Projekt und dessen Version übereinstimmen. Das hängt also nicht vom Übersetzungszeitpunkt (Translation) ab, sondern vom Commit bzw. der damit korrespondierenden Versionsnummer (Compilation). Gestützt wird diese Einschätzung von folgendem Zitat:

    Den von dir genannten Aspekt deckt dann wohl eher das PO-Revision-Date ab, richtig? Weil wir aber meist keinen PO-Editor (wie etwa Poedit) verwenden, müssen wir das PO-Revision-Date in der Regel manuell aktualisieren – und vergessen das meist.

  • Blockieren von Kanälen auf bestimmten Adaptern

    Ich habe ein ähnliches Problem mit den öffentlich-rechtlichen HD-Sendern. Auf manchen meiner Empfänger laufen sie gut, auf anderen sind Aufnahmen ziemlich sicher mit TS-Fehlern durchsetzt. Bei kls hatte ich deswegen angefragt, ob man Kanälen nicht optional eine Affinität zu Devices zuordnen könnte (so wie man bei Betriebssystemen Threads eine Affinität zu Cores zuordnen kann), sodass Aufnahmen solcher Sender bevorzugt "ihre" Devices nutzen und erst dann auf andere ausweichen, wenn "ihre" Devices nicht frei sein sollten. Das wäre vermutlich flexibler aus die Lösung mit Conditional Access, richtig?

    Klaus fand das hinsichtlich der Device-Auswahl aber zu kompliziert und hat das leider nicht weiter verfolgt. Keine Ahnung, ob – wie von Klaus angedeutet – ein Plugin so ein Verhalten realisieren könnte und was das für Konfliktprüfungen bspw. von EPGsearch hieße.

  • [EPGSearch] Neue Version v2.4.5

    Quote from TomJoad

    Neuer allgemeiner Parameter für Suchtimer: Frist zur Begrenzung der Timererstellung

    Vorneweg: Die Implementierung tut, was sie soll; und 999 Tage (gut 2,7 Jahre) als Defaultwert sind sicherlich mehr, als ein EPG jemals liefern dürfte.

    Dennoch finde ich die Implementierung nicht optimal, weil sie mit Konventionen bricht:

    • In EPGsearch steht der Wert 0 als Defaultwert bei praktisch allen Einstellungen dafür, dass eine Funktion abgeschaltet ist. Das ist hier aber weder der Fall noch überhaupt möglich.
    • In den Menüs haben wir an vielen Stellen die Einheiten, anstatt sie in den Fließtext einzubetten, in eckigen Klammern angefügt, damit sie leichter gesehen werden. Auch bei den Einstellungen oberhalb der Timer-Zeitbegrenzung ist das beispielsweise der Fall.
    • In den Menüs haben wir entweder auf Verben verzichtet bzw. meist die Infinitiv-Formulierung ("Per OSD warnen") anstelle der imperativen Form ("Warne per OSD") genutzt.
    • In den Man-Pages habe ich bei der Überarbeitung, wo immer möglich, die exakte Schreibweise des Menüeintrages als Überschrift bzw. Kennzeichnung für die entsprechende Einstellung verwendet, damit eine Zuordnung ohne großes Rätselraten gegeben ist.

    Der folgende Patch (jetzt ohne Tippfehlerteufel):

    … würde die obigen Punkte adressieren:

    Quote

    Zeitbegrenzung für Timer [t]

    Begrenzt die Erzeugung von Timern auf einen Zeitraum in Tagen. Ein Wert von 0 deaktiviert die Begrenzung.

  • [markad] überarbeiteter Decoder

    Quote from kfb77

    Aber einen Massen Diff mit 460 Zeilen, ohne Info dazu, was das verbessern soll, werde ich nicht übernehmen. Dedizierte Diffs je Thema, mit konkreter Beschreibung was damit verbessern soll und nur mit Änderungen für dieses eine Thema, sind immer willkommen.

    Tja, das hat sich mit der Zeit so ergeben. Dass ich das nicht wieder alles in seine Einzelteile zerlegen möchte, versteht du aber sicherlich auch.

    Im Wesentlichen habe ich ein paar Default-Variablen aus vdr.pc hinzugefügt, weil ich einige davon in meiner Umgebung brauche. Das sollte aber auch in anderen Umgebungen das Bauen nicht beeinträchtigen.

    Das "Entering/Leaving directory" habe ich entsorgt, weil die untergeordneten Makefiles das Verzeichnis als Teil von "CC", "LD" usw. mit ausgeben. Die Unterverzeichnisse plugin und command habe ich durch Variablen adressiert, ebenso praktisch auch die Namen aller anderen Verzeichnisse, Binärdateien und Man-Pages.

    Dort, wo es bei mir zur Installation notwendig ist, habe ich ein sudo vorangestellt, sodass ich nicht als root bauen muss. Auch habe ich manche Installationsschritte nochmals aufgeteilt, so dass für jede Gruppe von Dateien eine eigene Regel vorhanden ist, bspw. für die Logos.

    Zusammen mit dem Patch (hier ein Update, denn in einem Test hat ein -r gefehlt):

    … gestaltet sich der Durchlauf dann wie folgt (die Installationspfade entsprechen meiner Umgebung, nicht dem Linux-Standard):

    Die mehrfache Ausgabe von Compiler- und API-Version ist etwas unschön und ließe sich vielleicht noch adressieren.

    Ein grundsätzliches Problem ist auch, dass die Installation von Dateien in praktisch allen Plugins ohne Prüfung der Zeitstempel, somit also bei jedem Aufruf von make erfolgt, selbst wenn das eigentlich gar nicht notwendig wäre. Das könnte man zwar ändern, muss man aber nicht. Ich erinnere mich noch an das Drama, als alle Makefiles auf das neue Build-Konzept umgestellt wurden…

    Wenn du jetzt fragst, was ich gewonnen habe, wenn ja sowieso alle Dateien installiert werden: Beim Aufruf von make erkennt man jetzt sofort, ob es eine "echte" Codeänderung gegeben hat und nicht nur ein Update von version.h. Mir ist das wichtig genug, um den Aufwand für den Patch zu spendieren.

  • [live] compiler warning: variable 'i' set but not used

    Die Variablen scheinen sich bei der Überarbeitung durchgemogelt zu haben. Keine Ahnung, warum die Warnung bei uns nicht gekommen ist. Vielleicht fehlt im Makefile noch eine Compiler-Option (bei mir läuft g++ v13.3.0)?

    Der Pull-Request ist natürlich in Ordnung. Eleganter fände ich aber diesen Patch, weil er die eigentliche Laufvariable innerhalb der for-Schleife (und immer nach dem gleichen Pattern) deklariert:

    Welche Variante du wählst, überlasse ich dir.

  • [markad] überarbeiteter Decoder

    Quote from kfb77

    Dazu muss diese eine Datei neu gebaut werden., dauert bei mir unter 1 Sekunde. Ist so gewollt und werde ich auch nicht ändern.

    Aber es würde doch genügen, das nur einmal zu tun. Wenn sich die SHA-Checksum im Git nicht geändert hat, was sich ja leicht prüfen lässt, ist das nicht nur überflüssig, sondern schädlich (wie wir ja sehen). Könnte man hier nicht den Ansatz von Live übernehmen:

    Code
    VERSION_SUFFIX = "_git_local_c6fe165_20251222142346+0100"

    … der sogar vermerkt, ob der Commit genuin ist oder ob noch nicht eingecheckte Änderungen vorliegen:

    Code
    VERSION_SUFFIX = "_git_local_c6fe165_20251222142346+0100_patched"

    Mir hilft das ungemein, wenn ich anhand einer solchen Versionsnummer im VDR erkennen kann, welchen Entwicklungsstand auf Basis einer offiziellen Version ich gerade geladen habe. Und das Problem des ständigen Neuübersetzens hat diese Lösung ebenfalls nicht.

    Soll ich das einmal ausarbeiten?

  • [markad] überarbeiteter Decoder

    Mir ist ein kleines, aber lästiges Problem mit den Makefiles aufgefallen. Ruft man make mehrfach hintereinander auf, dann werden command/markad und plugin/libvdr-markad.so jeweils neu gebaut, ohne dass eine der Quellen geändert wurde:

    Das gleiche passiert, wenn man in command das Makefile lokal aufruft:

    Anders beim Makefile von plugin:

    Leider habe ich in den Makefiles die Ursache nicht eingrenzen können, aber vielleicht sieht ja einer von euch mehr als ich gerade.

    PS: Ich habe mir in den Makefiles ein paar Verbesserungen eingebaut und den Diff beigefügt. Das grundsätzliche Verhalten ist aber auch mit den originalen Makefiles nachvollziehbar.

  • [EPGSearch] Neue Version v2.4.5

    Quote from TomJoad

    Bei der Gelegenheit hätte ich auch gerne gewusst, ob noch jemand statt des internen svdrp-Calls die Möglichkeit eines externen Skripts nutzt (da kann man dann die Fehlerrückgabe komplett vergessen).

    Ich bin mir nicht ganz sicher, du genau mit "internen SVDRP-Call" meinst. Aber ich erinnere mich, das VDRadmin als Perl-Skript implementiert ist und und für alle Zugriffe auf den VDR und die unterstützten Plugins (somit auch EPGsearch) die SVDRP-Schnittstelle nutzt.