[ANNOUNCE] avahi4vdr - Dienste des vdr über den avahi-daemon im Netz bekannt geben

Moin!

Da ich demnächst an einem kleinen Projekt arbeiten möchte, dass die Timer der diversen vdr in einem LAN selbstständig verteilt, musste ich erst mal eine Möglichkeit finden, wie ich mitbekomme, ob da überhaupt ein vdr im Netz ist.
Also hab ich mir avahi mal angesehen und was man damit so machen kann. Herausgekommen ist ein vdr-Plugin, dass von anderen Plugins benutzt, aber auch durch eine Konfigurationsdatei dazu gebracht werden kann, Netzwerkdienste bekannt zu geben. Außerdem lässt sich mit dem Plugin auch nach bestimmten Netzwerkdiensten suchen.

https://github.com/flensrocker/vdr-plugin-avahi4vdr

Man sollte sich ein wenig mit avahi-services auskennen, letztendlich muss ein Service einen Namen, einen Typ und einen Port haben. Zusätzlich kann man noch ein bis mehrere Subtypes definieren und dann noch diverse TXT-Records hinzufügen.

Es gibt zwei Arten, über avahi4vdr einen Dienst zu veröffentlichen:
- per Aufruf von SVDRPCommand ("CreateService")
- per services.conf-Datei im Plugin-Config-Verzeichnis

Beispiel für eine services.conf:

name=SVDRP on %h,type=_svdrp._tcp,port=6419
name=vdr-live on %h,type=_https._tcp,port=8443,subtype=_vdr_live._sub._https._tcp
name=vdr-streamdev-server on %h,type=_http._tcp,port=3000,subtype=_vdr_streamdev_server._sub._http._tcp

Wenn man dann in einer Shell z.B.

avahi-browse -f -r -v _http._tcp

laufen lässt, dann sieht man beim Starten/Stoppen des vdr, wie die Dienste erscheinen und wieder weggehen.

Um z.B. vdr-live zu finden, kann man nach dem speziellen subtype suchen lassen:

avahi-browse -f -r -v _vdr_live._sub._https._tcp

Um mit avahi4vdr nach einem Dienst zu suchen, muss man einen Browser anlegen, das macht man ebenfalls per SVDRPCommand und dem Befehl "CreateBrowser". Wenn der was findet, wird die Service-Funktion des aufrufenden Plugins mit einem entsprechendem Event aufgerufen.

Einfach mal ins README schauen. Wer sich für das Plugin interessiert und Fragen hat, einfach fragen...

Mein erster Anwendungsfall: dbus2vdr hat vor kurzem eine zusätzliche Option bekommen, mit der ein paar Methoden über einen zweiten dbus-daemon aufgerufen werden können. Dieser lauscht auf einem TCP-Port und ist somit über's Netz erreichbar. Da dbus da aber nicht so 100% für gedacht ist, gibt's leider (noch) keine Authentifizierung und dergleichen. Deshalb wird über diesen dbus-daemon nur "ungefährliches" veröffentlicht: man kann (bisher) die Timer und die Aufnahmenliste abfragen. Und damit ein anderer vdr den automatisch findet, wenn der eingeschaltet wird, wollte ich eben avahi benutzen. Ob das alles so klappt, wie ich mir das vorstelle, weiß ich noch nicht, aber ich bin zuversichtlich...

Have fun!

Lars.

Moin,

WOL wird sicherlich auch irgendwie mit reinspielen.
Ansonsten dachte ich, dass erst mal jeder alles aufnimmt, was er will, damit quasi keine Aufnahme verloren geht. Auf Konflikte wollte ich nicht prüfen, wer sowas hat, muss mehr Geräte kaufen.
Ich muss das erst mal ein wenig probieren, bis ich weiß, was ich will und ob das taugt. Avahi4vdr ist aber unabhängig davon, weshalb ich das schon mal veröffentlichen wollte. Die Timer Geschichte kommt irgendwann in einem eigenen Thread.

Lars

Moin,

Interessant, aber ich dachte eigentlich an was leichter zu konfiguriendes. Am besten ganz ohne, die vdr sollen sich selbst finden und freiwillig Aufgaben (sprich Timer) übernehmen. Aber wie gesagt, lass mir noch ein paar Tage Denkarbeit.

Lars

Moin,

Denkbar wäre z.B. auch eine automatische Konfiguration von streamdev-client. Wenn ich die dbus-Schnittstelle noch entsprechend erweitere, kann sich der Client auch on the fly die aktuellen Kanäle holen.

Oder wenn eine App einen vdr per restfulapi steuern kann, müsste man auch keine Adresse oder Port mehr eingeben, weil die App einfach nachfragen kann, welcher vdr gerade online ist.

Gehört ja alles zur Idee von Zeroconf.
Ich bin gespannt auf eure Ideen. Avahi lässt sich auch einfach per python abfragen, ist für das Spielen mit diesem Plugin evtl. ein leichterer Einstieg. Im git von dbus2vdr ist ein kleines Beispiel.

Lars

Moin!

Ich kann überhaupt kein Python und hab mir das Beispiel hier mal aus dem Internet zusammengesucht.
Solange dieses Script läuft, wartet es darauf, dass sich ein streamdev-server im Netz meldet. Sobald einer da ist, wird seine IP und sein Port in die setup.conf geschrieben (dazu wird dbus2vdr benutzt!).
Sollte streamdev-client geladen sein, werden die Parameter durch das Plugin geleitet und dieser sollte dann sofort "empfangen" können.

Ist natürlich nur ganz grob und einfach nur mal als Anregung gedacht, was mit avahi4vdr so möglich sein könnte. Dann ist vielleicht verständlicher, wo die Reise hin gehen soll...

#!/usr/bin/env python


import dbus, gobject, avahi
from dbus import DBusException
from dbus.mainloop.glib import DBusGMainLoop


# Looks for streamdev-servers
TYPE = '_vdr_streamdev_server._sub._http._tcp'


def service_resolved(*args):
    print 'service resolved'
    print 'name:', args[2]
    print 'address:', args[7]
    print 'port:', args[8]
    Setup = bus.get_object('de.tvdr.vdr', '/Setup')
    Setup.Set('streamdev-client.RemoteIp', args[7], dbus_interface = 'de.tvdr.vdr.setup')
    Setup.Set('streamdev-client.RemotePort', args[8], dbus_interface = 'de.tvdr.vdr.setup')


def print_error(*args):
    print 'error_handler'
    print args[0]


def myhandler(interface, protocol, name, stype, domain, flags):
    print "Found service '%s' type '%s' domain '%s' " % (name, stype, domain)


    if flags & avahi.LOOKUP_RESULT_LOCAL:
            # local service, skip
            pass
    else:
            server.ResolveService(interface, protocol, name, stype,
                domain, avahi.PROTO_UNSPEC, dbus.UInt32(0),
                reply_handler=service_resolved, error_handler=print_error)




loop = DBusGMainLoop()


bus = dbus.SystemBus(mainloop=loop)


server = dbus.Interface( bus.get_object(avahi.DBUS_NAME, '/'),
        'org.freedesktop.Avahi.Server')


sbrowser = dbus.Interface(bus.get_object(avahi.DBUS_NAME,
        server.ServiceBrowserNew(avahi.IF_UNSPEC,
            avahi.PROTO_INET, TYPE, 'local', dbus.UInt32(0))),
            avahi.DBUS_INTERFACE_SERVICE_BROWSER)


sbrowser.connect_to_signal("ItemNew", myhandler)


gobject.MainLoop().run()

Lars.

Moin!

Zitat von henfri

Warum (gleichberechtigt)?

Ok, ich werde mal kurz meine Gedanken skizzieren, auch wenn es dann Offtopic wird...

Per avahi4vdr machen sich die vdr im Netz bekannt und zwar den Netzwerk-dbus-daemon, der von dbus2vdr gefüttert wird. Darüber kann sich jeder vdr eine Timerliste bei den anderen vdr abholen (pull, kein push!).
Dann entscheidet jeder vdr anhand von wenigen Kriterien, ob er auch diesen Timer aufnehmen möchte oder nicht.

Die folgenden Einstellung gibt es für jeden vdr im LAN einmal (wenn gewollt) und eine globale Einstellung für unbekannte Clients.
Mit "Client" bezeichne ich letztlich alle vdr, es gibt keinen "Server" in dem Sinne. Vielleicht sollte ich es lieber "Node" nennen?

CLIENT_ALLOWED:
Dies ist eine Timer-Priorität. Sollte der Client-Timer unterhalb dieser Priorität liegen, wird er ignoriert.
Soll ein vdr gar keine Client-Timer aufnehmen, wird der Wert auf 100 gesetzt, soll er "alles" aufnehmen, einfach auf 0 setzen.

CLIENT_LOWER_LIMIT, CLIENT_UPPER_LIMIT:
Die Priorität des Clients wird auf diesen Bereich gemappt, damit sehr wichtige lokale Timer nicht übersteuert werden können.
Durch die Beschränkungen auf Integer kann es natürlich passieren, dass zwei Prioritäten eines Client auf die gleiche Priorität gemappt werden. Schicksal.
Lokale Timer unterhalb von CLIENT_LOWER_LIMIT können durch Client-Timer übersteuert werden, Timer oberhalb von CLIENT_UPPER_LIMIT nicht.
Wenn ein vdr alles von allen Clients gleichberechtigt aufnehmen soll, einfach auf 0 und 100 setzen.

Dinge, über die ich noch nachdenken und ausprobieren muss:

• Per acpiwakeup kann man alle vdr so konfigurieren, dass sie ab und zu alle gleichzeitg an sind, evtl. können sie sich auch gegenseitig per WOL wecken.
• Timer müssen irgendwie markiert werden, damit ich sie wiedererkenne, insbesondere, wenn ein Client einen Timer wieder löscht.
• Timeshift-Timer erkennen und ignorieren.

Ich möchte nicht Timer zwischen den vdr verschieben, sondern verteilen. Warum soll ein Client nicht aufnehmen, wenn er kann? Wenn der Platz nicht reicht, hört er von alleine auf... Oder man deaktiviert das automatische Aufwachen für einen Timer. Oder man denkt sich noch was anderes aus, um Timer nicht zu starten.
Ich finde es sinnvoller, dass bestimmte Sachen von mehreren vdr aufgezeichnet werden. Manchmal bockt ja auch ein vdr und dann hat man ein "Backup".
Außerdem möchte ich keine "komplizierte Intelligenz" bei der Verwaltung der Timer. Nachher versteht das keiner und keiner kann es warten...

Ich glaube, dass mein Ansatz übersichtlich und verständlich ist und einfach "funktioniert".

Lars.

Moin!

Zitat von ludi

Nehmen wir an, eine Person hat VDRs mit verschiedenen Empfangsmöglichkeiten im lokalen Netz. Zum Beispiel hat er einen ersten VDR der DVB-S2 und DVB-C empfängt, einen zweiten der nur DVB-S (also ohne S2) und einen dritten der nur DVB-C empfängt. Wird das Plugin damit umgehen können?

Noch nicht, aber ich bin mir dieser Tatsache bewusst. Das hab ich auf der Liste für Version 2.

Da dieses Projekt aber nicht das einzige ist, wo dieses Problem zu lösen ist, dachte ich an ein weiteres channelmapping-Plugin, das von anderen Plugins gefragt werden kann. Da werden sicherlich die übergreifenden Kanal-IDs aus xmltv2vdr eine Rolle spielen. Bei der Kommunikation zwischen den vdr darf dann nicht nur die "lokale" vdr-Channel-ID übergeben werden, sondern sollte zusätzlich noch die "globale" Kanal-ID mitgeliefert werden, damit der Ziel-vdr weiß, worum es geht.
Aber so ganz ernsthaft hab ich noch nicht darüber nachgedacht. Ich wollte erst mal den Fall einer homogenen Umgebung lösen, hab aber die heterogene im Hinterkopf.
Zusätzlich gehört in diese Kategorie auch "Kanal in HD" und "Kanal in SD" über den gleichen Übertragungsweg.

Wäre vielleicht auch etwas für streamdev-client, aber da gibt es sicherlich noch ein paar Detailschwierigkeiten.

Lars.

Moin!

Zitat von ludi

Das mit den Kanalübergreifenden IDs sehe ich als zusätzliche Option, die der Benutzer ausschalten können sollte. Es wäre zum Beispiel möglich, dass die Empfangsqualität bei einem Empfangsweg besser ist als bei einem anderen.

Dafür würde ich die Reihenfolge der Kanal-IDs im Mapping als Priorität heranziehen. Außerdem wäre es ja fast wünschenswert, wenn ich auf einem SD-vdr einen Timer programmiere, den es auf einem anderen vdr in HD gibt und der dort dann in HD aufgenommen wird.
Manchmal ist es auch nicht gewünscht, weil man dann ja evtl. die HD-Aufnahme nicht auf dem SD-vdr abspielen kann. Das sehe ich aber wieder als Einstellung auf dem vdr, der sich von einem anderen vdr einen Timer holt: entweder "möglichst den gleichen Kanal" oder "nimm den ersten (besten) Kanal aus dem Mapping".

Das channelmap-Plugin sollte meiner Meinung nach einfach nur zwei Funktionen haben:

• gebe mir die globale ID zu lokaler vdr-channel-id
• gebe mir lokale vdr-channel-id zu globaler ID (können auch mehrere sein)

Die Konfiguration oder Datenbasis ist internes Detail und für die Funktion irrelevant. Zuerst werde ich sicherlich mit einer manuellen Datei testen, ob man die dann durch channelpedia o.ä. automatisch erzeugen kann, ist dann ja eine andere Sache.

Lars.

Moin!

Der vdr schneidet da bei der Ausgabe leider ein paar Buchstaben ab, da hat das Plugin keinen Einfluss drauf.
Ist mir auch schon aufgefallen, aber ich weiß ja, was ich da angeben muss...

Ich bin mir noch nicht sicher, wie ich das lösen/ändern soll. Diese 4-Buchstaben-Kürzel sind irgendwie etwas doof...

Lars.