[Announce] Neues Plugin: peer-0.0.1

Hallo nochmal,

seit vielen Jahren in Planung habe ich es nun endlich geschafft, eine erste Version dieses neuen Plugins zu veröffentlichen. Es richtet sich in erster Linie an die, die kein Client/Server haben (also alle Aufnahmen erledigt ein Server) sondern eher Peer-to-Peer (mehrere VDRs, alle mit eigener DVB-Karte). Aber auch für die Client/Server-Gemeinde ist vielleicht das eine oder andere nützliche Feature enthalten. Download unter http://vdr.schmirler.de.

Hier die aktuelle Feature-Liste:

* Timer anlegen/bearbeiten/löschen auf lokalem VDR und Peer-VDR sowie verschieben zwischen lokal und Peer (nutzt remotetimers-Plugin)
* Zugriff auf Menü des Peer-VDR (nutzt remoteosd-Plugin)
* OSD-Nachricht an Peer schicken
* Device-Status des Peers anzeigen
* Benachrichtigt werden, wenn auf dem Peer die Wiedergabe beendet wird
* Wake-on-LAN Paket an Peer senden

Manches ist sicherlich noch ausbaufähig (wie der Device-Status) oder ist eher eine Machbarkeits-Studie (Benachrichtigung wenn Peer-Wiedergabe beendet).

Die Abhängigkeiten von anderen Plugins unterscheiden sich stark - je nach gewünschten Features. Details sind im README zum Plugin zu finden. Wer die volle Funktion will, muss auf allen Peers die Plugins peer, remotetimers, remoteosd, svdrposd und svdrpservice installieren sowie den SVDRP-Zugriff für alle Peers erlauben.

Um remotetimers und remoteosd nutzen zu können, ist jeweils mind. Version 1.0.0 dieser Plugins erforderlich. Patches für ältere remotetimers/remoteosd-Versionen kann ich auf Anfrage bereitstellen.

In den peer-Quellen ist ein Makefile für VDR < 1.7.36 enthalten. Wie weit nach unten peer kompatibel ist, habe ich jedoch nicht getestet.

Viel Spaß!
Frank

Zitat von fnu

schmirl
Ich weiß das hört sich nun unverschämt an, so direkt nach Veröffentlichung, aber evtl. ergibt sich ja irgendwann die Möglichkeit das mit den Timern zu automatisieren. Also man setzt lokal den Timer, es ist kein Device frei und das Plugin schlägt direkt einen Peer zur Aufnahme vor ...

Dass das Plugin Begehrlichkeiten in diese Richtung weckt, habe ich kommen sehen. Habe mir daher auch mal ein paar Gedanken in diese Richtung gemacht. Um aber die Euphorie gleich einzubremsen: Ich brauche selbst nur Client/Server, von daher ist meine Motivation in diese Richtung recht gering. Aber wenn sich ein Entwickler findet, der Zeit und Testumgebung mitbringt - warum nicht?

Das große fehlende Stück im Puzzle ist eigentlich - in Anlehnung an kls cDevice::GetDevice-Funktion - die Berechnung des "Impact" für das Verschieben eines Timers an einen anderen VDR: Angefangen von "kannst Du löschen - nehme ich bereits auf" über "kannst Du mir geben - nehme auf dem selben Tansponder etwas auf" und "meinetwegen - habe noch Devices frei" bis zu "nur im Notfall - würde lokales LiveTV einschränken" und "nein Danke - bin ausgelastet". Als Grundlage würde sich die Konflikterkennung von epgsearch eigenen, da diese die VDR Device-Vergabe komplett simuliert. Eine andere Implementierung die ähnlich weit geht ist mir nicht bekannt. Ergänzen müsste man die Konflikterkennung um den Modus "was passiert wenn ich den folgenden Timer hinzufüge" mit den genannten Rückgabewerten. Falls sich also jemand berufen fühlt...

Der generelle Algorithmus für die Timer-Verteilung könnte dann wie folgt aussehen: Alle VDRs sind anhand ihrer Instanz-ID numerisch geordnet. Jeder VDR fragt im Hintergrund alle in der Ordnung unter ihm liegenden, gerade erreichbaren VDRs, ob diese einen lokalen Timer "billiger" aufnehmen können. Falls ja wird der Timer nach unten verschoben. Besteht lokal ein Konflikt, der sich so nicht lösen lässt, wird der Konflikt an höher liegende, gerade erreichbare VDRs verschoben. Timer ohne Probleme sammeln sich als unten, Konflikte oben in der VDR-Ordnung. Liegt ein Konflikt vor und die Aufnahme steht unmittelbar bevor, werden zusätzlich ausgeschaltete VDRs der Reihe nach geweckt - wer gerade ausgeschaltet ist nimmt logischerweise auch nichts auf. Die Chance ist also recht hoch, den Konflikt loszuwerden.

Vielleicht sind ja ein paar theoretische Informatiker anwesend, die eine bessere Lösung parat haben. Den Anspruch einer optimalen Timer-Verteilung erfüllt meine heuristische Lösung sicher nicht. Dafür ist sie aber recht einfach zu implementieren (abgesehen von der "Impact"-Berechnung) und kommt ohne zusätzliche Datenhaltung und ohne permanent laufenden Master-VDR aus.

Zitat

Und ganz cool, also noch unverschämter wäre, wenn man in noch fernerer Zukunft die Aufnahmen dann kreuz und quer zwischen den Peers gucken könnte ...

Da sieht es schlecht aus. Für HTTP ist das in streamdev ja schon ansatzweise eingebaut. Für VDR-zu-VDR macht das meiner Meinung nach wenig Sinn. Das reine Streamen einer Aufnahme samt Vor- und Zurückspulen geht ja noch. Aber ich befürchte, mit z.B. Schnittmarken bearbeiten dürfte es kompliziert werden. Über Netzwerk-Dateisysteme gibt's das ganze Quasi umsonst, von daher habe ich da ein Problem mit dem Verhältnis zwischen Aufwand und Nutzen.

Zitat von Frodo

Ich habe da aber ein Anzeige Problem beim Aufruf aus dem VDR Hauptmenü.

Hinter de Namen des Peers tauchen in der nächsten Spalte 3 - 4 Zeichen auf welche nicht lesbar sind:Ist hier ein spezieller Font nötig?

Da sollte eigentlich die IP stehen. Schau ich mir an. Danke für den Hinweis!