VDR "Cloud"

henfri · 29. Dezember 2010

Hallo,

hier hat sich herauskristallisiert, dass ich keine Streaming-Lösung nutzen möchte, sondern dass die Clients eine eigene DVB Karte bekommen sollen.

Jetzt kann es aber ja passieren, dass der Server nicht genügend Tuner hat. In diesem Fall wären aber ja noch Tuner bei den Clients frei.

Diese möchte ich gerne nutzen.

Jetzt gibt es dafür zwei Plugins, die helfen können:
1) epgsearch zum Identifizieren von Konflikten
2) Remotetimers zum verschieben

Zunächst eine Frage zum Konfliktcheck in Epgsearch:
Erkennt epgsearch nur, wenn mehr Timer als Tuner vorhanden sind, oder erkennt es, wenn mehrere Timer auf einem Transponder sind?

Aktionen in Epgsearch im Falle eines Konflikts auslösen
EPGsearch kann ja eine Mail senden, wenn ein Konflikt ansteht.
Das könnte man nutzen. Der Server könnte dem/den Clients eine Mail senden und ihm zusätzlich per WOL wecken.

Das wäre aber etwas umständlich. Ist es auch möglich hier direkt das Remotetimers-Plugin anzusprechen

Remotetimers-Plugin
Hm... Ich sehe gerade dass man Remotetimers nicht unbedingt braucht..
Eigentlich reicht schon svdrpsend.pl NEWT, oder?

Sprich: Man müsste nur durch EPGsearch bei einem Konflikt ein Skript aufrufen.
Dieses weckt den Client per WOL und wartet ein, zwei Minuten.
Danach ein
svdrpsend.pl NEWT aktiv:Kanalnummer:Tag_des_Monats:Startzeit:Endzeit:Priorität:Dauerhaftigkeit:Titel:

EPGsearch bietet ja diese Variablen:

Code

The following variables can be used in the section <timer>:


  - %timer.date%            - date of the timer
  - %timer.start%           - start time of the timer
  - %timer.stop%            - stop time of the timer
  - %timer.file%            - recording directory of the timer
  - %timer.chnr%            - channel number 
  - %timer.chsh%            - short channel name
  - %timer.chlng%           - channel name
  - %timer.search%          - name of the search timer, that created the timer
  - %timer.searchid%        - id of the search timer, that created the timer
  - %timer.modreason%       - the reason for a timer modification in plain text

Alles anzeigen

Also: sfdrpsend.pl NEWT 1:%timer.chnr%:%timer.date%:%timer.start%:%timer.stop%:50:10:Titel

Beim "Date" müsste das Format ggf. noch geändert werden, da svdrpsend ja nur den Tag des Monats erwartet.

Was haltet ihr hiervon?

Gruß,
Hendrik

anbr · 29. Dezember 2010

Hi,

Ich möchte die Chance nutzen, doch ein wenig PR für XXV machten

Es war zwar nicht deine Frage, aber gerade XXV kann eine "VDR-Cloud" verwalten. Sprich man kann mehrere VDR in einer gemeinsamen Weboberfläche bedienen. So werden alle Timer der Cloud in eine Ansicht zusammenfasst, um sie im Überblick zu haben. Timerkonflikte werden hier auf die genutzten Transponder bezogen angezeigt. Ebenso ist möglich Timer zwischen den einzelnen VDR zu verschieben.

http://xxv.berlios.de/images/s…/xxv-1.6/xxv-jason-pe.jpg
http://xxv.berlios.de/images/s…ots/xxv-1.6/xxv-jason.jpg

Andreas

henfri · 29. Dezember 2010

Hi,

XXV kenne ich "von früher".
Hab's aber seit ich Live habe nicht mehr genutzt.
Ich wusste nicht, dass XXV das kann. Nicht schlecht!

Ich werd's mir mal ansehen. Mal gucken, was dann noch fehlt.
Kannst du mir einen Tipp geben, wo ich über die Cloud-Features etwas lesen kann?

Gruß,
Hendrik

winni · 31. Dezember 2010

Hi,

Zitat

Erkennt epgsearch nur, wenn mehr Timer als Tuner vorhanden sind, oder erkennt es, wenn mehrere Timer auf einem Transponder sind?

epgsearch simuliert den ganzen Aufnahmeverlauf und benutzt dabei den gleichen Karten-Vergabealgorithmus wie VDR zum Zeitpunkt der echten Aufnahme. Es wird also nicht nur auf Überschneidungen getestet, sondern aller mögliche Kram wie z.B. CAMs, HD und nicht-HD,... berücksichtigt.
Wer sich diese Simulation ansehen will, muss nur das Loglevel per Parameter -v 3 hochsetzen und dann einen Blick in die epgsearch.log werfen.

Zitat

Sprich: Man müsste nur durch EPGsearch bei einem Konflikt ein Skript aufrufen.

das gibts bisher nicht, wär aber sicher kein Aufwand. Sag einfach Bescheid, wenn es weiter interessiert.

Zitat

Danach ein svdrpsend.pl NEWT aktiv:Kanalnummer:Tag_des_Monats:Startzeit:EndzeitZunge raus rioritätgroßes Grinsen auerhaftigkeit:Titel:

im aktuellen git gibts eine Variable %newtcmd%, die bereits den komletten String für NEWT ausspuckt.

Gruß,
winni

M-Reimer · 31. Dezember 2010

Zitat

Original von winni
epgsearch simuliert den ganzen Aufnahmeverlauf und benutzt dabei den gleichen Karten-Vergabealgorithmus wie VDR zum Zeitpunkt der echten Aufnahme. Es wird also nicht nur auf Überschneidungen getestet, sondern aller mögliche Kram wie z.B. CAMs, HD und nicht-HD,... berücksichtigt.

Was mich wundert: Wenn ein NetCeiver eingesetzt wird, dann werden ohne Ende Überschneidungen gemeldet... Keine Ahnung wie da der Zusammenhang ist.

henfri · 31. Dezember 2010

Hi Winni,

danke.
Das hört sich ja super an.
So ab August hätte ich Interesse daran.
Ich werde dann die Dockstar als Server einsetzen und bei einem Timer-Konflikt den Client wecken und den Timer rüber schieben.

Oder sieht noch jemand einen Pferdefuß?

Gruß und guten Rutsch,
Hendrik

henfri · 1. Mai 2011

Zitat von winni

das gibts bisher nicht, wär aber sicher kein Aufwand. Sag einfach Bescheid, wenn es weiter interessiert.

Bescheid!

(wegen Suche ein Plugin: Verteile Aufnahme Aufträge auf mehrer VDR'S)
Um das Verteilen zu realisieren, wäre wichtig, dass für den Timer, der nicht ganz aufgenommen werden kann %newtcmd dem Verteilungs-Skript übergeben wird. Wie würde dieser übergeben?
Außerdem benötigt man den Index des Timers, um ihn lokal zu löschen

Ich nehme mal einfach an, diese Parameter würden als $1 und $2 übergeben. Dann würde man einfach dieses Skript aufrufen:

Code

!#/bin/sh
partner_mac=""
partner_ip=""
newtcmd=$1
local_timer_index=$2


###############
wakeonlan $partner_mac
sleep 180


svdrpsend.pl -d $partner_ip NEWT $newtcmd
svdrpsend.pl -d localhost DELT $local_timer_index

Alles anzeigen

Gruß,
Hendrik

winni · 2. Mai 2011

Hallo Hendrik,

da die Sache doch etwas "speziell" ist, denke ich, dass man auf GUI/OSD verzichten kann. Ich würde deshalb vorschlagen, dass wir das über einen Eintrag in der setup.conf regeln, z.B.:

Code

epgsearch.ConflCheckCmd=meinscript.sh %newtcmd% %timer.index%

%timer.index% gibt's noch nicht, ist aber auch kein Problem. Man kann dann natürlich beliebige andere Variablen auch noch reinsetzen, falls nötig.
Ich würde dann - falls belegt - für jeden Timer, der einen Konflikt hat, epgsearch.ConflCheckCmd ausführen und das bei jedem Konflikt-Check. Wenn Du die Konflikt-Timer sofort löschst, sollte ein Mehrfachaufruf für einen Timer eh nicht passieren, ich würde das aber nicht von epgsearch-Seite her abfangen.

Würde Dir das so reichen?

Gruß,
winni

henfri · 2. Mai 2011

Hallo,

ja, so wie das aussieht, würde das reichen.
Ich würde dann den Timer eben an den nächsten Aufnahmeknecht weitergeben. Dabei würde ich nicht prüfen, ob der Zeit/Platz hat oder auch einen Konflikt. Macht aber ja nix.
Ggf. läuft da dann das gleiche Skript und er gibt es eben an den nächsten weiter.

Gruß,
Hendrik

winni · 28. Mai 2011

Hallo Hendrik,

bin jetzt endlich mal dazu gekommen Im git ist nun ein Stand, mit dem das klappen sollte:

Beispiel in der setup.conf:

epgsearch.ConflCheckCmd = system(/bin/echo, '%timer.file% starts at %time%!')

macht wenig Sinn, aber ist ja nur zum Testen. Kann man mit Loglevel 3 (-P'epgsearch -v 3') in der epgsearch.log nachvollziehen.

allgemein:

epgsearch.ConflCheckCmd = system(dein_skript.sh, parameter1, parameter2,...). Im Manual steht auch noch etwas dazu:

Zitat

Note:
There's a 'hidden' setup option epgsearch.ConflCheckCmd, that allows executing a
command for each timer causing a conflict. You have to set this directly in VDRs
setup.conf like this:

epgsearch.ConflCheckCmd = system(your_script_handling_the_conflict.sh, any_arguments like %timer.file%)

(Please have a look at 'Calling a system command' below for the possible arguments)
One could use this for example to forward a timer to another VDR machine in case of a conflict.
This command is evaluated for each timer causing a conflict whenever an automatic
conflict check is running. When calling the conflict check via OSD the command is not
evaluated.

Alles anzeigen

Überraschenderweise ist das mit dem Timer-Index nicht so einfach. Da der Konflikt-Check mit einer Kopie der Timer arbeitet, kann ich auf den Original-Index nicht mehr zugreifen. Ich könnte mir den zwar irgendwo zwischenspeichern, allerdings verträgt sich das wieder nicht mit dem Ansatz, dass man in epgsearch.ConflCheckCmd mit Event- und Timer-Variablen arbeiten kann. Ich fürchte also, dass Du Dir hier in Deinem Skript etwas mehr Arbeit machen mußt, also anhand SVDRP-LSTT die Timer auslesen und den Index des richtigen Timers selbst ermitteln mußt.

Dann bin ich mal gespannt, ob Deine "Cloud" klappt

Gruß,
winni

henfri · 4. Juni 2011

Hi Winni,

vielen Dank für das Einbauen! Ich weiß das zu Schätzen
Ich bin gerade im Hausbaustress. Sobald ich aus dem Gröbsten 'raus bin, kümmere ich mich darum.

Gruß,
Hendrik

VDR "Cloud"

Jetzt mitmachen!

Teilen