Posts by SHofmann

Quote from FireFly

Letzendlich macht IsTunedToTransponder() auch nichts anderes, aber dafür braucht man das Device-Plugin nicht.

Deine Anmerkung verwirrt mich: Ich versuche gerade herauszufinden, wo man im SatIP-Plugin hinfassen muss, damit es sich so verhält, dass der VDR bei einem getunten Transponder auch alle Kanäle für die Aufnahme heranzieht.

Wenn du mit "Device-Plugin" das DevStatus-Plugin meinen solltest, dient es mir in diesem Zusammenhang nur als "Messgerät", ob das funktioniert, sprich: alle Kanäle des Transponders gefunden werden.

Danke für die Erläuterung. Wenn dem so ist, dann müsste man sich also ProvidesChannel() genauer ansehen um zu verstehen, warum es (siehe die Screenshots von DevStatus) früher die Anfrage korrekt beantwortet hat (ZDF HD und zdf_neo HD als Kanäle desselben Transponders), nun aber nicht mehr – richtig?

Quote from FireFly

Das DevStatus-Plugins geht für die Anzeige der zusätzlichen Kanäle die channels.conf durch und fragt für jeden Kanal, ob der auf dem gleichen Transponder liegt d->IsTunedToTransponder(channel) Diese Anfrage landet dann offenbar im Satip-Plugin in cSatipDevice::IsTunedToTransponder() was true oder false zurück gibt.

kls, FireFly war so freundlich herauszuarbeiten, wie das Plugin DevStatus die auf einem Transponder verfügbaren Kanäle ermittelt. Folgt der VDR auch diesem Ansatz oder gibt es ein anderes Verfahren (sprich: Interface), das das SatIP-Plugin derzeit noch nicht (oder nicht mehr) korrekt unterstützt?

PS – Ich sollte die Frage wohl nochmals präzisieren: Wie entscheidet der VDR für einen Kanal, von dem eine Aufnahme gestartet werden soll, ob ein Device bereits auf einen Transponder mit diesem Kanal getunt ist?

Danke, ich habe es inzwischen gefunden. Ich hatte in GitHub an der falschen Stelle nach den Projekten geschaut, die ich bearbeiten darf. Bin halt noch ein GitHub-Newbie…

Versuche es doch mal hiermit: Numerical selection of multiple-digit menu items.patch.txt

Quote from M-Reimer

Plugin liegt jetzt hier: https://github.com/vdr-projects/vdr-plugin-devstatus

Ich finde es noch nicht in der Liste der "Community maintained"-Projekte. Als Contributor müsste ich es doch sehen, oder?

Quote from kamel5

Wenn sich da also jemand angesprochen fühlt, das zu übernehmen...

Dann lass das DevStatus-Plugin doch auf "Community maitained" setzen. Für solche Plugins haben sich ja ein paar Forumsmitglieder als Contributoren für die weitere Pflege gemeldet. Und wenn du ebenfalls Contributor wärst, könntest du im Bedarfsfall ebenfalls ran.

Quote from FireFly

Die Screenshots sehen für mich nach dem DevStatus-Plugin aus, nicht nach femon ("Signalinformationen" im Hauptmenü)!

Da hast du recht, das steht ja auch in der Titelleiste. Das habe ich in den letzten Tagen konsequent verwechselt…

Quote from FireFly

Wobei Bouquet und Transponder nicht das gleiche sind, sondern ein Bouquet kann aus meheren Transpondern bestehen, siehe https://de.wikipedia.org/wiki/Bouquet_(digitales_Fernsehen).

Wieder was gelernt.

Quote from FireFly

Das ist schon ziemlich alt; heute würde man z.B. die Menüs nicht mehr von cOsdMenu direkt ableiten und auch die VDR-Funktionen zum Ermitteln der Signalstärke nutzen anstatt sie direkt mit IOCTLs abzufragen (und das Plugin das device nicht mehr schließt wenn ich das richtig gesehen habe).

In der VDR-Projektübersicht auf github.io wird kamel5 als aktiver Maintainer geführt. Insofern war ich der Hoffnung, dass es einen einigermaßen guten Stand hat. Aber da es funktioniert, ist der Stand wohl gut genug – wenngleich vielleicht auch nicht auf dem letzten API-Stand des VDR. Vielleicht mag es kamel5 ja in einer ruhigen Minute mal nachziehen?

Quote from FireFly

Das DevStatus-Plugin zeigt nicht an welche Kanäle gerade empfangen werden, sondern zeigt unter dem gerade empfangen Kanal, welche Kanäle auf dem gleichen Transponder liegen und empfangbar wären.

Und dass diese derzeit nicht angezeigt werden (können), ist meines Erachtens eine Ausprägung des Problems.

Quote from FireFly

Diese Anfrage landet dann offenbar im Satip-Plugin in cSatipDevice::IsTunedToTransponder() was true oder false zurück gibt.

Danke fürs Eingrenzen. Die spannende Frage ist aber doch, warum "früher" der VDR die übrigen Kanäle auf dem Transponder nutzen konnte, jetzt aber – etwa bei zwei aufeinanderfolgenden, sich überlappenden Serien-Episoden – offensichtlich nicht mehr. Wenn der VDR eine ähnliche Abfrage durchführt, würde deine Analyse das beobachtete Verhalten erklären.

Quote from FireFly

Soviel ich weiß, hatte er alle meine Änderungen übernommen, das ist auch der Stand den ich in meinem git https://github.com/FireFlyVDR/vdr-plugin-satip habe und nutze (ich nutze nicht Wirbels git).

Ehrlich gesagt, kann ich bei manchen Plugins (und SatIP gehört dazu) nicht mehr einschätzen, welcher Fork der aktuelle und "beste" Stand ist. Ich hatte seinerzeit halt den Fork verwendet, der den "jüngsten" Commit aufwies. Aber das heißt leider nicht zwangsläufig, dass darin auch andere wichtige Patches drin sind. Wenn du Pech hast, hast du nur einen Fork für einen Pull request erwischt…

Deshalb die Frage an die Wissenden: Welches ist die derzeit – beste – bekannte Quelle für das SatIP-Plugin? Die VDR-Projektübersicht auf github.io verweist jedenfalls auf den Fork von wirbel.

Ich habe eine TT S2-6400 mit den Devices 1 und 2 (Tuner) sowie Device 4 (Decoder) und zusätzliche Device 3 per SatIP, das den zweiten Empfänger in meinem Smart-TV nutzt.

Ich habe zum Vergleich einmal den letzten Stand von rofafor (Commit 02a842f) gebaut. Und hier bekommt man in femon die Kanäle des Bouquets – wie bei den TT-Devices – angezeigt:

Für mich hindeutet dies darauf hin, dass:

• damit die mehrfache Nutzung von Kanälen im Bouquet funktionieren
• sich die Ursache für das abweichende Verhalten anhand des Code-Vergleichs beider Stände eingrenzen lassen

sollte. Leider stecke ich zu wenig in der Thematik VDR-Devices und SatIP-Protokoll drin, als dass ich da viel helfen könnte.

Sag bitte Bescheid, wenn du noch Daten aus dem syslog brauchen solltest.

PS: Gefühlsmäßig würde ich bevorzugt an den Codestellen ansetzen, wo die Kanäle des Bouquets ermittelt bzw. an den VDR weitergeleitet werden. Vielleicht ist es ja "nur" eine Kleinigkeit bezüglich der Kanalabfrage (wird die evtl. versehentlich übersprungen?) bzw. deren Übergabe an den VDR…

Das hatte ich doch geschrieben: Mit Commit 1a1377e konnte ich hin- und wieder in femon alle Kanäle im Bouquet sehen, mit dem aktuellen Stand im Git konnte ich diesen Zustand nicht mehr herstellen.

Quote from FireFly

Das ist gut möglich, auch wenn ich eher erwarte, dass der VDR für die mehrfache Belegung eines Device zuständig ist.

Ich denke, das tut er auch. Nur leider liefert ihm SatIP nach meinem Dafürhalten nicht alle Kanäle im Bouquet, sondern nur den einen, auf den es tunen sollte…

Deinen Ausführungen kann ich leider nicht entnehmen, ob ich darauf hoffen darf, dass du dir das einmal etwas genauer anschaust. Spannend ist ja immerhin, dass das Device bis zum dem von dir genannten Commit wenigstens hin und wieder alle Kanäle ausgewiesen hat, mit dem aktuellen Head-Commit aber nicht ein einziges Mal.

Danke für den Hinweis, aber leider hilft beides nicht.

Ich bin auf Commit 407ed39 zurückgegangen:

Das Plugin habe ich danach mit make clean; make install übersetzt und den VDR 2.7.4 neu gestartet. Nach einem ersten Timer für Device 2 habe ich einen zweiten für Device 3 gestartet. Gleiches Ergebnis wie zuvor:

Ich habe dann die Timer mehrfach an- und wieder abgeschaltet. Als ich zuerst den Timer für Device 2 und dann für Device 3 abgeschaltet und in dieser Reihenfolge wieder angeschaltet habe, sind hin und wieder (leider nicht jedes Mal) alle Kanäle im Device 3 sichtbar gewesen:

Nach einem erneuten ab- und anschalten des Timers für Device 3 hat sich wieder der alte Zustand mit nur einem Kanal eingestellt. Das Ab- und Anschalten beider Timer in der genannten Reihenfolge hat aber gelegentlich wieder zum "erwünschten" Zustand geführt.

Für mich sieht das so aus, als ob dies von der Vorgeschichte, sprich: von internen Zuständen des Plugins abhängt. Könnten das Race conditions oder un- bzw. falsch initialisierte Variablen sein?

Mit dem aktuellen Commit ist es mir übrigens nicht mehr gelungen, diesen Zustand mit den zwei Kanälen im Device 3 zu reproduzieren.

Hallo wirbel, ich beobachte einen seltsamen Effekt, an den ich mich so nicht erinnern kann. Ich habe folgende Einstellungen fürs Plugin:

-P 'satip --devices=1'

Ich möchte auf diesem Device (Device 3) zwei aufeinanderfolgende Episoden einer Serie aufnehmen, deren Timer sich überlappen. Sobald die zweite Episode startet, wird diese Aufnahme (unerwarteterweise) einem anderen Device zugeteilt.

Sollten nicht alle Aufnahmen auf Sendern des gleichen Bouquets (oder zumindest des gleichen Kanals) diesem Device zugeteilt werden? Ich meine mich zu erinnern, das das früher so war.

Seltsamerweise zeigt auch femon – anders als für Device 2 meiner S2-6400 – keine Kanäle für dieses Device an:

Ist das normal oder was ist die Ursache dafür?

Mein Stand ist der aktuelle von deinem Git-Repository:
be96a98 add comment

Beim Löschen von Aufzeichnungen hat man doch auch eine Verzögerung: Wenn du mehrere Aufzeichnungen zum Löschen markierst und dann "Ausgewählte löschen" anklickst, dauert es schon ein paar Sekunden, bevor die Seite neu aufgebaut wird. Selbst bei nur einer gelöschten Aufzeichnung ist die Verzögerung schon spürbar. Die Verzögerung mag allerdings von der Zahl der Aufzeichnungen insgesamt abhängen und auch davon, ob Live nach jedem Löschvorgang die Liste neu einliest (was ich derzeit vermute, aber nicht überprüft habe) oder erst nach dem Löschen aller markierten Aufzeichnungen. Könnte Markus sich vielleicht nochmals kurz ansehen…

Man könnte also nach solch einer Aktion vielleicht doch erwägen, den Seitenaufbau um bspw. 1 Sekunde zu verzögern. Besser wäre natürlich noch, max. 1 Sekunde darauf zu warten, dass der VDR den Vollzug meldet und die Seite dann oder nach dem Timeout neu aufbauen.

Eine weitere Option wäre, nach einer solchen Änderungen per JavaScript einen Reload nach 1 bis 2 Sekunden auslösen. Ich bin mir allerdings nicht sicher, ob solch ein Auto-Update nicht eher stören würde.

Quote from dile

Einen weiteren Patch lokal mitzuführen möchte ich auch vermeiden.

Wenn du Git verwendest, ist das gar nicht so kompliziert und aufwändig: Ich habe den master geklont und per git checkout origin/master -b enhancements einen Branch für meine lokalen Erweiterungen erstellt. In diesem Branch sind alle meine Patches drin (siehe hier), und für das Bauen verwende ich dann eben diesen Branch. Sobald Markus ein Update liefert, ist – wenn enhancements noch immer der aktive Branch ist – mit einem git pull origin master alles erledigt. Außer, es gibt Merge-Konflikte, was bei deinem einzeiligen Patch wohl eher selten der Fall sein dürfte. Und falls doch, ist der Patch schnell wieder eingespielt.

Mit deinem Patch geht einher, dass du im Prinzip alle Texte durch die Übersetzung leiten müsstest. Denn "Tab", "Esc", "Menu", "Red", "Green" usw. heißen halt in jeder Sprache und den Tastenbeschriftungen anders. Hier ein kurzer Auszug, wie das den Patch verändern würde:

<area shape="rect" coords="42,345,116,355" alt="<$ tr("Keyboard shortcuts in the remote view") $>" title="&amp;lt;<$ tr("Tab") $>&amp;gt; - <$ tr("menu") $> ... />

Und sauber tabelliert möchtest du es im Popup ja bestimmt auch noch haben. Ist zwar alles machbar, wird dann aber ganz schön kompliziert, weil du den HTML-Code für die Tabellierung in title kodieren musst, um es an die Event-Prozedur für die Anzeige durchzutunneln.

Wenn du diese Erweiterung bei dir lokal einbaust, kannst du dir – weil nicht für die mehrsprachige Allgemeinheit bestimmt – die ganze Übersetzerei sparen und gleich deutsche Texte einsetzen.

Quote from dile

Und wenn ich schon dabei bin, wäre es denn aufwendig das man auch Kanallogos im SVG Format verwenden könnte.

Das betrifft den Code in whats_on.ecpp ab Zeile 232. Der Aufwand ist meines Erachtens überschaubar.

Etwas diffizil (und bei Skins bzw. Plugins leider nicht einheitlich gehandhabt) ist die die Abbildung der Sendernamen auf die Dateinamen. Sie unterscheiden sich dahingehend,

• ob der Sendername in Groß/Kleinschreibung oder klein geschrieben verwendet werden soll
• wie Slashes ("/") in den Sendernamen behandelt werden sollen, etwa bei "SAT.1 NS/Bremen"

Für Letzteres sind folgende Ansätze üblich:

• Der Slash wird Teil des Pfadnamens. Im Dateisystem benötigt man dann entsprechende Unterverzeichnisse für die Bestandteile nach den Slashes. Das ist nicht nur sehr unübersichtlich, sondern leider auch nicht eindeutig: man bekommt nur ein Logo, wenn mehrere Sendernamen bspw. auf "/Bremen" enden. Insofern ist das keine gute Idee.
• Der Slash wird durch "_" ersetzt (das war der ursprüngliche Ansatz von Live, siehe Zeile 232).
• Der Slash wird durch "~" ersetzt (wie im VDR, Markus hat das inkl. Kleinschreibung dankenswerterweise für mich zusätzlich in die Codebasis aufgenommen).

MarkusE, anbei der getestete Patch:

Ich baue den VDR auf Basis von v2.7.4 gerade neu auf. Beim Einspielen des aktuellen Undelete-Patches ist mir in menu.c folgendes aufgefallen:

Das LOCK_RECORDINGS_WRITE als letztes Statement ohne nachfolgende Anweisungen scheint mir ein wenig sinnlos zu sein. Müsste das nicht an den Anfang der Prozedur (also vor Zeile 3143)?

Ich finde es auch etwas unschön, dass alle Codeänderungen mit #if(n)def USE_UNDELETE gekennzeichnet sind. Mir ist klar, dass das dem späteren Auffinden der Codezeilen dient. Wenn man aber mit Git arbeitet, ist das eher überflüssig, denn ein git diff oder git blame führt ebenfalls zum Ziel. Wer den Patch also lieber ohne die Extrazeilen (und mit der oben angemerkten Änderungen) in seine Codebasis übernehmen möchte, findet diese Fassung anbei.

PS: Ich trenne begrifflich zwischen "Aufnahme" (die Prozedur) und "Aufzeichnung" (das Ergebnis davon). In der Übersetzung ist das angepasst; gegebenenfalls also die aus dem ursprünglichen Patch resultierende Fassung verwenden.

Hallo Klaus,

ich kann mich meinen Vorrednern nur anschließen: ohne den VDR, nur auf das lineare Programm oder (flüchtige) Mediatheken angewiesen, würde mir ein wichtiges Element meiner "Programmgestaltung" fehlen.

Ich bin seit dem ersten Bericht in der c't dabei (das war 2003, wenn ich mich recht erinnere) und dem VDR seitdem treu geblieben. Nur einmal habe ich den Rechner (den von der c't empfohlenen MSI-Barebone mit einem "Turbinen-Lüfter") zwischenzeitlich durch einen "normalen" (nun flüsterleisen) Rechner ausgetauscht (siehe Signatur). Das war so etwa zu der Zeit, als DVB-S2 kam. Und weil der VDR so "genügsam" ist, war auch gar nicht mehr an Hardware-Aktionen erforderlich.

Hatte ich mich anfangs noch auf fertige Distributionen verlassen, baue ich den VDR und alle Plugins seit diesem Plattformwechsel selbst. Meine Umgebung ist zwar hinsichtlich der Pfade ziemlich speziell, dafür habe ich alles unter einem einzigen Dateibaum, sodass ich schnell und einfach zwischen unterschiedlichen VDR-Ständen hin- und herwechseln kann. Und seitdem du den Code in Git bereitstellst, ist das Bauen noch einen Tick bequemer geworden.

Besonders gefallen hat mir schon immer die Erweiterbarkeit des VDR, gerade auch mithilfe von Skripten. So habe ich mir etliche RecCommand-Skripte erstellt, die mir alle nötigen Handgriffe bei Aufnahmen zu bewerkstelligen helfen, etwa Updates in den Infos von Aufzeichnungen. Durch die Hooks lassen sich genialerweise schon gleich bei der Aufnahme auch solch lästige Dinge automatisieren, wie etwa Altersangaben im Untertitel ("S") in "echte" Altersangaben ("R") zu transformieren, Produktionsdaten aus der Beschreibung in den Untertitel zu verfrachten, Wiederholungsvermerke zu eliminieren und dergleichen mehr.

Es sind seitdem tolle Skins entstanden und etliche geniale Plugins. Vielen Dank deshalb auch an alle, die diese geschaffen haben bzw. pflegen. Und gelegentlich kann ich ja auch ein paar Anregungen und Patches beitragen…

Es wäre schön, wenn uns der VDR und seine Komponenten noch einige Zeit erhalten blieben und weiterhin so engagiert weiterentwickelt würden.

PS – beinahe vergessen: Herzlichen Dank für den VDR und das Ökosystem, das du damit geschaffen hast, sowie weiterhin viel Spaß bei der Weiterführung des Projektes!