Posts by SHofmann

  • Unterstützung für "vdr-projects" gesucht

    Quote from rell

    Wer kann mergen? Brauchts (sinnvollerweise) einen weiteren review dafür? Konkret gehts mir darum.

    Mergen können sollte doch eigentlich jeder der Community Maintainer. Ich für meinen Teil beschränke mich aber auf die Plugins, die ich auch selber nutze – womit ich auch gleich eine entsprechende Testabdeckung habe.

    Einen Review durch den Maintainer, der den Pull-Request bearbeitet, sollte meines Erachtens ausreichen. Wenn ein Maintainer selbst eine Änderung per direktem Push einbringen möchte, würde ich es dem jeweiligen Maintainer überlassen, ob er für die jeweilige Änderung (abhängig von Umfang bzw. Komplexität) eine vorausgehende Testphase bzw. einen Review für erforderlich hält.

  • VDR hängt beim Löschen des Timers einer Sofort-Aufnahme, wenn die Aufzeichnung noch läuft

    Das kann ich mit VDR 2.7.7 nicht bestätigen. Wenn ich bei laufender Aufnahme deren Timer löschen, wird die Aufnahme ganz normal beendet. Der VDR lässt sich danach wie gewohnt bedienen.

    Allerdings hatte ich es auch schon, dass sichder VDR nach einer Abfolge von Bedienvorgängen auf Tastendrücke nicht mehr reagiert hat. Ich kann das nicht eingrenzen, es könnte aber ein Deadlock mit dem Plugin extrecmenung sein.

  • 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.