[warp10]

Hallo zusammen,

bevor ich zu meinem Problem komme, hier kurz mein Setup: Ich verwende einen SAT>IP Server (Telestar Digibit R1) mit der satip-axe Firmware. Der Digibit bekommt sein Antennensignal von einem TechniRouter 5/1x4 (Unicable Router). Auf der VDR-Seite verwende ich dann einen Banana-Pi als VDR-Server und zwei RPi2 als VDR-Clients.

Das ganze läuft dank der o.g. satip-axe Firmware super - bis auf folgendes Problem:

Wenn alle Tuner vom Digibit im standby sind, hat natürlich der TechniRouter keine Versorgungsspannung mehr. Wenn jetzt von irgendeinem VDR eine Kanalanforderung kommt, werden die Unicable-Kommandos vom Digibit losgeschickt, allerdings scheint das so schnell zu gehen, dass der TechniRouter nocht nicht voll da ist, da er ja im Zuge des "Aufwachens" des Tuners ja erst seine Versorgungsspannung bekommt. Ich habe das auch mal als Issue auf Github eingestellt.

Zum TV schauen ist das natürlich kein Problem, dann schaltet man einfach am Anfang kurz einen Kanal weiter und dann läuft alles wie gewünscht.
Problematisch wird es bei einer Timer-Aufnahme: Der Timer fordert einen Kanal an, der Digibit fordert diesen beim Technirouter an aber der ist noch nicht voll da und bekommt es nicht mit. Ergebnis: eine Aufnahme mit 0 Byte... Mein aktueller Workaround: Ich programmiere zu jeder Aufnahme eine kurze Aufnahme (1 Minute) auf einem anderen Transponder, damit der TechniRouter aufwacht. Das ist natürlich ziemlich nervig.

Meine Idee war, ein "before"-Recording Skript zu nutzen, welches einen Kanal anfordert. Folgendes Skript habe ich getestet (liegt im Ordner /etc/vdr/recording.d/

Code: [Select]

#!/bin/sh
case "$1" in
     before)
            svdrpsend.sh 'CHAN 2' >/dev/null
            ;;
esac

Leider führt das nach 60s zu einem Neustart des VDR (watchdog...). Kanal 2 wird auch nie angefordert, dass sehe ich auf dem Digibit. Wenn ich das Skript manuell auf der Konsole starte, funktioniert es.
Hat jemand eine Idee?

Danke und viele Grüße,
Thorsten

[BobW]

Hallo,

versuche mal -d als Parameter mitzugeben.

BobW

[clausmuus]

Hi,

ich vermute, dass an dieser Stelle die svdrpsend Schnittstelle blockiert ist.
Versuche es mal mit dem Parameter -d beim svdrpsend.sh Befehl. Ich habe aber die Befürchtung, dass dies auch nicht hilft, weil dann die Umschaltanforderung erst nach dem Aufnahme Start ankommt.
Eventuell geht es aber, wenn Du das restfulapi Plugin für's Umschalten verwendest. Ich glaube das wird nicht blockiert.
Vermutlich solltest Du nach dem Umschalten auch noch ein "sleep 1" einbauen, damit wirklich genug Zeit für's aufwachen ist.

Claus

[warp10]

Hi,

danke für die Tipps. Bei der Variante als Hintergrundprozess (-d) wird zwar umgeschaltet, aber leider zu spät - der Timer schaltet vorher bereits um. Vermutlich ist in der Tat die svdrp-Schnittstelle blockiert und dann kommt der Umschaltbefehl zwar, aber erst nachdem alles vorbei ist.
Wie kann ich denn am einfachsten die restful-API verwenden? Hatte an wget gedacht, z.B.:

Code: [Select]

wget --method=POST http://IP:8009/remote/switch/S19.2E-1-1019-10301
allerdings kennt die wget Version von MLD den Parameter "--method" nicht. Oder kann ich das plugin direkt ansprechen?

Danke und Grüße,
Thorsten

[clausmuus]

Doch, die kennt post, und zwar wenn Du per "--post-data DATA" die DATA Daten übergibst, also z.B.:

Code: [Select]

wget --post-data "x=1111&y=222" http://IP:8009/remote/switch/S19.2E-1-1019-10301oder wenn keine Daten gesendet werden brauchen:

Code: [Select]

wget --post-data "" http://IP:8009/remote/switch/S19.2E-1-1019-10301
Claus

[warp10]

Cool, danke für den Tipp.
Hab es gerade ausprobiert, es wird zwar umgeschaltet, aber wieder zu spät.
Was dann passiert ist folgendes: Der Timer schaltet zuerst auf den Sender, der aufgenommen werden soll (bevor es das Skript schafft...).
Damit ist Frontend1 des Digibit belegt, liefert aber keine Daten wegen der bereits beschriebenen Problematik. Dann wird durch das "before"-Recording Skript auf z.B: ARD geschaltet. Damit wird Frontend2 auf dem Digibit belegt. Hier kommen nun Daten an, aber Frontend1 liefert nach wie vor keine Daten.

Das einzige was mir jetzt noch einfällt wäre im Skript die Aufnahme abzubrechen, einen Kanal anfordern, und dann wieder die Aufnahme zu starten. Irgendwie doof :-(

[clausmuus]

Eventuell lässt sich über die /etc/vdr/diseqc.conf eine Verzögerung einstellen. Wenn ich mich richtig erinnere gibt es da auch sowas wie nen Timeout. Das hätte dann aber vermutlich den Nachteil, dass das Umschalten immer verzögert wird. Aber vielleicht lässt sich da ja auch einstellen, da jeder befehl mit einer Verzögerung von einer Sekunde wiederholt wird.

Ich denke aber das Deine Idee mit dem stoppen und wieder Starten der Aufnahme die einfacherere Lösung ist. Du muss nach dem Stoppen aber bestimmt auch noch umschalten.

Claus

[warp10]

Ok, danke. Wird die diseqc.conf überhaupt benutzt (da ja alles über das satip-plugin läuft)?
Wenn das Umschalten lange dauert, wäre es nicht schlimm, da ich das nur auf dem Server machen würde damit die Timer-Aufzeichnungen funktionieren.

Gibt es eigentlich ein Skript, das aufgerufen wird sobald ein neuer Timer angelegt wird? Dann könnte ich evtl. automatisiert einen cronjob erstellen, der kurz vor der Aufnahme ein bisschen rumzappt...

Danke nochmals,
Thorsten

[clausmuus]

Hi,

das mit dem cronjob wollte ich auch gerade vorschlagen.
Es gibt aber kein Script das beim anlegen eines Timers ausgeführt wird. Eventuell geht das aber über das dbus Plugin. Ansonsten müsstest Du die Datei timers.conf überwachen oder in regelmäßigen Abstenden pollen.

Claus

[cle]

Hi,

nur so ein Gedanke: hast du schon es schon mal mit VPS probiert? Dort kann man eine Vorlaufzeit einstellen, die angibt, wie viele Sekunden vdr vor einer Aufnahme auf den Transponder schaltet, um nach VPS-Signalen zu suchen.

"Defines how many seconds before a VPS controlled timer is scheduled to start, VDR will make sure that one of the DVB devices is tuned to the transponder that timer shall record from."

Zusammen mit
"just in case there is no real VPS data available at the time of recording, so VDR has to fall back to  normal timer recording."
sollten Aufnahmen dann ja auch bei nicht-VPS-Sendern funktionieren.

Sollten ...

Gruß
Alex
 
   

[warp10]

auf den Transponder schaltet

Hi Alex,

danke für den Gedanken. Ein Timer ohne VPS schaltet ja ebenfalls auf den Transponder, nur das reicht leider nicht sofern alle Tuner des Digibit gerade im Standby sind. Im Prinzip müsste er einmal auf einen anderen Transponder schalten und danach wieder zurück auf den, von dem aufgenommen werden soll.

Im Prinzip muss "nur" vor einer Aufnahme mal kurz auf irgendeinen Transponder geschaltet werden (nur nicht auf den, vom dem aufgenommen werden soll), damit der Unicable-Router aufwacht.
Ich werde noch kirre, da muss es doch einen simplen Weg geben 

Danke und Grüße,
Thorsten

[mikeM]

Hm, blöder Workaround: zusätzlicher Timer kurz VOR dem eigentlichen Timer mit einer länge von 1-2 Minuten sollte doch auch reichen? Ambesten immer auf dem gleichen Kanal, der sonst nie aufgezeichnet wird (irgend ein Werbesender oder so)

Gruß
Michael

[warp10]

Hi Michael,

ja so mache ich es im Moment:

Mein aktueller Workaround: Ich programmiere zu jeder Aufnahme eine kurze Aufnahme (1 Minute) auf einem anderen Transponder, damit der TechniRouter aufwacht. Das ist natürlich ziemlich nervig.

Das lässt sich vermutlich mittels cronjob und Skript auch automatisieren. Aber irgendwie unbefriedigend.

Ich habe gesehen, dass minisatip5, dass ja auf dem Digibit läuft, die Angabe von diseqc-timings erlaubt (Quelle: https://github.com/catalinii/minisatip):

Code: [Select]

-q --diseqc-timing ADAPTER1:BEFORE_CMD1-AFTER_CMD1-AFTER_REPEATED_CMD1-AFTER_SWITCH1-AFTER_BURST1-AFTER_TONE1[,...]

    All timing values are in ms, default adapter values are: 15-54-15-15-15-0
    note: * as adapter means apply to all adapters
Vielleicht kann ich da einen oder mehrere erhöhen, die Frage ist welche(n).

Viele Grüße,
Thorsten