[Feature request] EPGsearch client/server fähig machen

  • Hallo,


    Ich habe bisher EPGSearch benutzt und das originale Programm Menü ersetzt. Seit der Umstellung auf Server/Client nutze ich jetzt remotetimers. Durch die vielen Einstellungsmöglichkeiten gefällt mir aber EPGsearch besser (Kanal-/Tagesseparatoren, Ansicht mit "Jetzt" starten etc.). Ich habe auch schon im Bugtracker von EPGsearch ein Feature-Request eröffnet. Winni ist gegenüber Patches aufgeschlossen.
    Da ich aber keine Ahnung von programmieren habe, wollte ich hier mal nachfragen, ob jemand Zeit und Lust hat, hier dran zu arbeiten. Louis hat ja z.B. im TVGuide-Plugin auch eine Funktion eingebaut, die übers remotetimers-Plugin die Timer auf dem Server setzt.
    Ich weiß leider nicht, wie schwer das wäre oder wieviel Arbeit das macht.


    Evtl. ist es ja auch einfacher das remotetimers-Plugin anzupassen. Was meint ihr dazu?


    Schöne Grüße
    Viktor

  • Da ich aber keine Ahnung von programmieren habe, wollte ich hier mal nachfragen, ob jemand Zeit und Lust hat, hier dran zu arbeiten. Louis hat ja z.B. im TVGuide-Plugin auch eine Funktion eingebaut, die übers remotetimers-Plugin die Timer auf dem Server setzt.


    Na ja, du könntest ja zumindest schon mal anfangen eine funktionale Spezifikation zu schreiben, also was soll der Patch denn konkret machen?


    In dem Zusammenhang kam mir letztens in den Sinn, dass die Suchtimer sehr gut in der Datenbank des epgd von horchi/CKone aufgehoben wären. Für die eigentliche Suche ist der VDR nicht erforderlich. Der Suchtimerupdate wird ja auch jetzt schon von einem externen Job gemacht IIRC. Wenn der epgd die Suchtimer hätte, dann könnte er nach jedem EPG-Update eine Suche starten und die so gefundenen Timer auch in der Datenbank ablegen. Die VDRs holen sich dann die Timer. Das Tüpfelchen auf dem i wäre es, wenn der epgd dann auch noch bei Bedarf einen VDR per WLAN weckt, wenn bis zum Aufnahmezeitpunkt keiner die Timer geholt hat.


    Leider habe ich keine Zeit dafür.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Leider habe ich keine Zeit dafür.


    ich denke auch epgd hat viel Potential für solche Sachen, sei es scraping, Suchtimer, remotetimer, oder auch live oder ähnliches.


    Wenn sich die Lösung des epg2vdr gut duchsetzt könnte ich mir gut vorstellen das die Entwickler der angesprochenen Tools auch Interesse finden auf Basis ihrer Erfahrungen bei der Implementierung mitzuarbeiten oder diese selber vorantreiben. Wir können eh nicht alles allein abdecken und werden im Rahmen einer solchen Entwicklung mehr als genug mit dem Core zu tun haben.


    Aktuell ist es aufgrund der jungen Entwickling verständlicherweise eher so das sich die Entwickler ungern von der erforderlichen DB abhängig machen und stattdessen ihre Plugins lokal oder mit eigenen Abhängigkeiten bauen. - Lass uns mal in einem halben Jahr weitersehen...


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Auch in Zukunft stehe ich da eher auf der Seite von Klaus und bin der Meinung, dass ein gut gemachtes Plugin nur vom VDR selbst abhängig sein sollte. Für VDR-Basisfunktionalität einen Daemon zwangsweise laufen lassen *müssen* fande ich eher unschön. Mir gefällt epgsearch so wie es ist. Keine externen Abhängigkeiten, leicht zu installieren, leicht zu bedienen.

  • Na ja, du könntest ja zumindest schon mal anfangen eine funktionale Spezifikation zu schreiben, also was soll der Patch denn konkret machen?

    Okay, ich weiß jetzt nicht genau, was eine funktionale Spezifikation ist, aber bei der eigentlichen Anfrage wünsche ich mir die einfache und übersichtliche Programmansicht und Konfigurationsmöglichkeiten vom EPGSearch-Plugin auf dem Client und wenn ich da einen Timer setze, soll der Timer auf dem Server landen. Im TVGuide-Plugin ist diese Remotetimer-Funktion optional einstellbar. Sorry, wenn das nicht ganz klar war.


    Schöne Grüße
    Viktor

  • Moin,


    ich bin da auch hin und her gerissen...ich sehe schon die Vorteile, die der epgd mit seinem Stand Alone Ansatz und einer mächtigen Datenbank liefert...aber ich sehe auch die Abhängigkeiten, und das finde ich genau so wie mein Vorredner nicht so prickelnd.


    Alternativ könnte man natürlich auch zwei Plugin Versionen anbieten, eine "Standalone" und eine "epgd Integrierte"...aber den Aufwand will sich ja auch keiner ans Bein binden.


    Ciao Louis

  • EPGSearch-Plugin auf dem Client und wenn ich da einen Timer setze, soll der Timer auf dem Server landen.


    Man, die ganze Welt redet von cloud computing! :mua


    Was nutzt dir das wenn du 3 Aufnahmen hast und der Server hat nur 2 Tuner, ein anderer VDR hat aber noch noch eine Karte über? - Meine Vorstellung wäre da eher das er in der DB landet und der Prozess wie von Gerald angeregt die Timer entsprechend der definierten HW verteilt , die betroffenen VDR dazu notfalls aufgeweckt werden.


    Alles nur Denkanstösse, wird ja ein langer Winter...


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Niemand wird das benutzen müssen. epgsearch wird ja nicht abgeschafft...


    Was Gerald meinte, ist, wenn man schon epg2vdr/epgd benutzt, dann wäre eine sinnvoller Erweiterung, dass die Suchtimer auch in der Datenbank abgelegt werden, und zwar von einer Oberfläche, die unabhängig vom vdr ist. Stellt euch eine Weboberfläche auf einem ständig laufenden Plug-Computer/NAS vor, mit der man bequem von PC, Tablet, Phone usw. im Programm blättern kann. Dann noch mal eben ein paar Timer angelegt (bzw. die schon programmierten Events werden natürlich entsprechend markiert dargestellt) und der vdr muss nur noch dann laufen, wenn er was aufnehmen muss.


    Ich benutze gerne live, aber wenn ich aus der Firma mal eben einen Timer anlegen will, muss ich mich erst mal per ssh einloggen und die Kiste aufwecken. Würde aber auf meiner GoFlex ein vdr-loses "live" laufen, wäre es wesentlich unkomplizierter, gerade auch von unterwegs mit dem Handy. Dann kann der epgd (oder wer auch immer) den vdr aufwecken, damit der sich dann die neuen Timer aus der Datenbank holt und dann natürlich unabhängig von epgd den Kram aufnehmen.


    Was das Aufwecken bestrifft: Ich hab da einen kleinen Python-Daemon geschrieben, der sich über Avahi im LAN bekannt gibt und automatisch die Hostnamen und MACs untereinander austauscht und mit dem man einfach einen PC über den Hostnamen aufwecken lassen kann. Ist im yavdr-PPA als "yavdr-hostwakeup" bzw. in einem Repository auf GitHub: https://github.com/flensrocker/hostwakeup
    Dann muss man nicht mehr manuell die Hosts/MACs irgendwo hinterlegen.


    Wenn also epg2vdr zusätzlich die Timer aus der Datenbank abholt und sie entweder direkt im vdr ablegt oder epgsearch damit füttert, gibt es für den eigentlichen Betrieb keine Abhängigkeit.
    Und ist es nicht der *nix-Weg, kleine Programme/Daemonen mit spezifischen Aufgaben geschickt miteinander zu verknüpfen, damit man eben nicht alles noch mal neu schreiben muss?


    Ob diese Richtung im Sinne des Thread-Erstellers ist, muss Viktor sagen. Und wenn ihm diese Richtung gefällt, dann sollten sich hier die Leute zusammen tun, die sowas gerne bauen möchten. "Finde ich nicht gut" und "braucht man nicht" Aussagen sind dann nicht hilfreich. Niemand wird gezwungen, das zu benutzen... :)


    Lars.

  • Wenn also epg2vdr zusätzlich die Timer aus der Datenbank abholt und sie entweder direkt im vdr ablegt oder epgsearch damit füttert, gibt es für den eigentlichen Betrieb keine Abhängigkeit.


    aber irgendwie müssen sie ja auch da reinkommen, es sei denn du kommst wieder über ssh, diesmal aber mit

    Code
    insert into timers values ( ...


    Wobei zum Basteln kannst ja ohne weiteres dazu einen dummy vdr auf deiner GoFlex ohne tuner starten, dem verpasst du epg2vdr und live und du hast doch quasi schon das was du möchtest? - dann müsste es in der Tat nur noch eingesammelt werden...


    [Edit] ich muss das noch mal revidieren: das was Gerald und ich meinen ist eher push als pull, also der Daemon weckt und pushed, der client polled nicht [/Edit]


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • aber irgendwie müssen sie ja auch da reinkommen, es sei denn du kommst wieder über ssh, diesmal aber mit


    Dafür muss noch ein extra Programm/Daemon geschrieben werden. Ich rede nicht vom OSD, sondern einer Programmzeitschrift im Browser, mit der ich (Such-)Timer in der Datenbank ablegen kann, die dann automagisch in den vdr wandern, wenn der mal wieder läuft (bzw. geweckt wird).
    Klar kann man auch einen vdr nehmen, aber dann muss ein neues Plugin geschrieben werden, das sich in live einklinkt oder selbst eine Weboberfläche darstellt. Eine Lösung unabhängig vom vdr wäre mir da lieber.
    Ich brauche dann nur ein Port-Forwarding im Router und kann dann mit jedem Browser loslegen.


    Da gab's immer mal wieder Ansätze zu, aber die haperten immer an der EPG-Datenbank (bzw. dem EPG-Zugriff auf den vdr). Jetzt haben wir ja die Daten... :)


    Lars.

  • ich muss das noch mal revidieren: das was Gerald und ich meinen ist eher push als pull, also der Daemon weckt und pushed, der client polled nicht


    Das heißt aber eben auch, dass der Daemon die vdr irgendwie kennen muss. Ich sehe das irgendwie anders herum, soll heißen, die Clients entscheiden selbst, welchen Timer sie aufnehmen möchten (evtl. sogar mehrere den gleichen, wenn er mir wichtig genug ist, quasi als Backup).
    Es fehlt evtl. eine Benachrichtigungsmöglichkeit, wenn der epgd neue Timer in der Datenbank abgelegt hat. UDP-Broadcast wäre möglich, finde ich aber irgendwie unschön,weil die auch verloren gehen können. Ich hab auch schon ein wenig mit DBus über Netzwerk experimentiert, das geht durchaus (siehe dbus2vdr-Daemon in yaVDR). Darüber kann ich z.B. die Timer-Changed-Events des vdr-Status-Interface ins Netzwerk pushen. Wenn andere vdr gleichzeitig laufen, könnten die darauf reagieren.
    Das ist aber ein Szenario, an dem ich noch arbeite, eher Peer2Peer als Client/Server. Will ich nutzen, damit die vdr in einem LAN bei Timerkonflikten diese automatisch selbst auflösen können. Ein paar Grundsteine hab ich schon, aber bisher ist noch alles nur im Kopf und zu wenig Zeit dafür.


    Weiß jemand einen schönen Mechanismus, mit dem man solche Ereignisse im Netzwerk herumschicken kann? Vorstellen könnte ich mir auch, dass man Avahi dafür benutzt. Die Datenbank kann man darüber ja auch im Netzwerk ankündigen, so dass man das Plugin quasi nicht mehr konfigurieren muss (bzw. bei der Konfiguration einmal kurz per Avahi im Netz nachfragt und dass dann als Auswahl anbietet). Solche Avahi-Announcements können eine beliebige Anzahl an TXT-Records beinhalten, da kann man die aktuellen, unabgerufenen Timer listen. Wenn ein vdr startet, fragt er per Avahi nach diesem "Dienst" und wenn da Timer drin sind, schaut es in der Datenbank nach. Vermutlich müssen da noch nicht mal die Timer aufgelistet werden, sondern nur die Info "Die Datenbank hat noch Timer, die aufgenommen werden wollen".


    Dafür lässt sich mein Plugin avahi4vdr nutzen, mit dem andere Plugins ohne eigene Abhängigkeiten zu Avahi nach solchen Diensten suchen (und auch anbieten) können.
    Ich hab da zwar noch ein kleines Problem beim Beenden des vdr, wenn dbus2vdr gleichzeitig aktiv ist und die Netzwerk-Option nutzt, aber das finde ich auch noch.


    Lars.

  • so gesehen wäre das völlig autark vom epgd, die Applikation kann ein paar Tebellen erstellen (timer,userberechtigungen, etc) und liest im Weiteren dann unsere


    Haben wir denn so einen Webdesigner hier im Forum, damit das auch was her macht? ;D


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Es fehlt evtl. eine Benachrichtigungsmöglichkeit, wenn der epgd neue Timer in der Datenbank abgelegt hat.


    das ist aber doch nicht so schwierig, lass sie doch über die DB kommunizieren, machen wir doch auch:


    machst du Plugin welches einmal die Minute die Tabelle checkt, vdr checkt den Timer dann ein wenn er ihn abnimmt damit der nicht doppelt aufgenommen wird. Für Timer die der Damon nicht los wird weckt er die vdrs der Reihe nach auf - im Grunde ist genau das die benötigte epgsearch Erweiterung weil es semantisch da besser hinpasst (das schraubt der Jörg an einem Nachmittag da rein wenns sein muss, und der winni natürlich schon lange ;D )


    das Einzige was ich anders sehe als du ist warum das neue superduper Webprogramm den blöden Timer da nicht selbst auf die Tabelle schreibt und warum der epgd da mitspielen muss, vllt mag das ja jemand auch gar nicht und möchte das Webprogramm lieber in einer Art DMZ betreiben?


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Mal eine kurze Zwischenfrage: ich spiele ja auch mit dem Gedanken, mehrere VDRs in einem lokalen Netz "peer-to-peer"-mäßig zu verknüpfen und im ersten Schritt zu ermöglichen, bei jedem Timer mit angeben zu können, auf welchem VDR er aufnehmen soll. Allerdings wird das eine ganz "einfache" Schnittstelle werden, also nix "avahi", "dbus" oder sonst irgendwelche Dämonen.
    Wenn das aber dann niemand benutzt, weil alle eine super-wuper-avahi-dbus-client-server-datenbank-Variante verwenden, dann kann ich mir eigentlich jegliche Arbeit in dieser Richtung auch gleich sparen.


    Bitte nicht falsch verstehen: damit möchte ich keinesfalls die Diskussion hier in Frage stellen. Mich würde nur mal interessieren, ob an einer "nativen" Verbindung von VDRs überhaupt Interesse besteht, oder ob ich da eher für die Tonne arbeiten würde...


    Klaus

  • Allerdings wird das eine ganz "einfache" Schnittstelle werden, also nix "avahi", "dbus" oder sonst irgendwelche Dämonen.

    Wie stellst du dir das mit der "einfachen" Umsetzung vor? Eher über SVDRP wie es das remotetimers-Plugin macht oder mit ein bisschen mehr Intelligenz, damit sich z.B. die VDRs automatisch gegenseitig finden können? Ich fände es schon prima, wenn der VDR in der Richtung Netzwerk neue Fähigkeiten erhält, weil dann diese Funktionen in anderen Plugins leichter nutzbar werden ohne dass Plugins untereinander wieder über eigene Service-Schnittstellen reden müssen. schmirl hat da ja einige schöne Plugins wie remotetimers und das peer-Plugin vorgelegt, wenn das oder auch Teile davon einfach nativ im VDR möglich werden würde mich das freuen.

    Wenn das aber dann niemand benutzt, weil alle eine super-wuper-avahi-dbus-client-server-datenbank-Variante verwenden, dann kann ich mir eigentlich jegliche Arbeit in dieser Richtung auch gleich sparen.


    Ich sehe das eher als mögliche epgsearch-Ergänzung (was ja vermutlich sowieso nie ein Kern-Feature des VDR werden dürfte) - wenn man schon eine MySQL-Datenbank mit EPG-Daten zur Verfügung hat, bietet es sich doch geradezu an die für groß angelegte Suchanfragen mit zahlreichen Selektionskriterien und Triggern für neue Daten zu nutzen statt das zyklisch immer wieder auf jedem einzelnen VDR zu machen. Mir gefällt der peer-to-peer Ansatz aber trotzdem besser, weil man keine zentrale Verwaltung (wie z.B. bei MythTV) braucht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich fände es schon prima, wenn der VDR in der Richtung Netzwerk neue Fähigkeiten erhält, weil dann diese Funktionen in anderen Plugins leichter nutzbar werden ohne dass Plugins untereinander wieder über eigene Service-Schnittstellen reden müssen.


    Das hier ist glaub ich der entscheidende Punkt, und selbst Lars räumt ja ein es durchaus als sinnvoll zu empfindenden bereits entwickelte Funktionalität einzubinden...


    genau wie das hier

    Ich sehe das eher als mögliche epgsearch-Ergänzung (was ja vermutlich sowieso nie ein Kern-Feature des VDR werden dürfte)


    ich glaub auch das eine Halbautomatik (manuell einem vdr einen Timer zuweisen) Potential nach oben bietet: wenn der vdr aber die technische Plattform bereitstellt damit ein Plugin Timer im eigenem Ermessen auf einen anderen vdr transportiert, dann ist das doch Hand in Hand und nicht dagegen...


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()


  • Natürlich sollen die sich gegenseitig automatisch finden können.


    In diese Kommunikation von Klaus zwischen den VDRs könnte sich solch ein "EPGD" ja durchaus einhängen. Er muss ja gar nicht verraten, dass er gar kein VDR ist. So wäre auch die Möglichkeit gegeben einen Proxy zu haben, der schon mal Infos von einem VDR ausliefert, der gar nicht aktiv ist und stellvertretend, für diesen schlafenden VDR, Timer entgegen nimmt. Das wäre dann völlig transparent. Niemand muss dafür irgendwas konfigurieren, ob er nun einen solchen Daemon hat, oder nicht.
    Insofern bin ich dann schon sehr gespannt, was Klaus da zaubert.


    Wenn ich von Daemon spreche, dann meine ich nicht unbedingt den real existierenden EPGD. Das kann auch ein völlig eigenständiges Programm sein. Es sollte nur auf die Datenbank mit den EPG-Daten zugreifen können.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!