[Announce] vdr-plugin-satip-0.3.3 - Make your VDR to a SAT>IP Receiver. [updated]

Hallo,

ich habe jetzt auch eine Telestar Digibit R1. Da das satip Plugin ganze Transponder von der R1 holt, ist mein Raspberry mit seinem lahmen Ethernet für den Stream etwas überfordert. Und auch aus anderen Gründen habe ich mir überlegt einen VDR mit streamdev dazwischen zu schalten.

Nun habe ich Probleme beim Umschalten. Ich habe das satip Plugin auf dem Server mit "-d 1" gestartet. Der VDR hat also nur ein virtuelles Device. Schalte ich nun von Programm 1 (Das Erste HD) auf 2 (ZDF HD) um, passiert es häufig, dass der Bildschirm schwarz bleibt. Wenn ich dann auf dem Server im SVDRP "chan" eingebe, sagt er noch, er wäre auf 1. D.h. er hat irgendwie den Transponder nicht gewechselt. Im Log des Raspberry ist ohne FilterStreaming nichts anderes zu sehen, als bei den erfolgreichen Umschaltversuchen. Bei aktivem FilterStreaming stürzt der VDR oft sofort ab, da er vermutlich einfach den falschen Transponder filtert. Mit der gleichen streamdev-server Version auf meinem VDR mit TT-6400 funktioniert das Umschalten immer (dort ist allerdings eine ältere VDR Version im Einsatz).

Andererseits, wenn ich per SVDRP ohne Streamdev-Client per "chan 2" und "chan 1" umschalte, sieht es jedes Mal erfolgreich aus (dort ist nur das dummydevice aktiv, daher kann ich nicht sehen, ob es wirklich klappt).

Hat jemand eine Idee?

Viele Grüße

Tim

Ich habe das Problem das nach dem Einschalten des VDR´s es etwa ~1min dauert bis das Plugin den SAT>IP Server im Netzwerk findet.
Gibt es eine Möglichkeit statt dieser Dynamischen Erkennung ihn per IP festzuschreiben mittels Konfig, da 1min schon recht störend ist?
Wenn ich mittels DVB Viewer darauf zugreife ist sofortiger Zugriff möglich.

In den Vorraussetzungen steht

- Libcurl >= 7.36.0 - the multiprotocol file transfer library with RTSP support
  http://curl.haxx.se/libcurl/

leider hat Ubuntu 12.04.4 LTS aktuell die Version 7.22.0 umd wie ich feststellen durfte sind dagegen sehr viele Pakete gebaut.

Ist es unbedingt erforderlich die Libcurl Version >= 7.36 einzusetzen, bauen konnte ich es auch genen 7.22.0? Welche Einschränkungen ergeben sich hierduch?

Hi Frodo,

Zitat von Frodo

In den Vorraussetzungen steht

Code

- Libcurl >= 7.36.0 - the multiprotocol file transfer library with RTSP support
  http://curl.haxx.se/libcurl/

leider hat Ubuntu 12.04.4 LTS aktuell die Version 7.22.0 umd wie ich feststellen durfte sind dagegen sehr viele Pakete gebaut.

Ist es unbedingt erforderlich die Libcurl Version >= 7.36 einzusetzen, bauen konnte ich es auch genen 7.22.0? Welche Einschränkungen ergeben sich hierduch?

wohl schon. Bau Dir doch Dein curl nur für satip bspw. so:

/usr/local/src/curl-7.37.0 # ./configure --prefix=/usr/local/satip

Und starte dann den VDR mit

LD_LIBRARY_PATH=/usr/local/satip/lib vdr blahblah

So mache ich das immer.

Viele Grüße

EDIT: Du musst natürlich das Plugin dann auch so bauen:

LD_LIBRARY_PATH=/usr/local/satip/lib make plugins install

Und im satip-Plugins Makefile:

### Includes and Defines (add further entries here):


INCLUDES += -I/usr/local/satip/include
LDFLAGS += -L/usr/local/satip/lib

fnu
Wenn man das LibCurl von Dir benutzt wird doch das 7.22.0 er Curl ersetzt, gibt das keine Probleme mit den anderen Paketen welche die ältere Version zum kompilieren verwendet haben?

tehlers
Das ist für eine Paket basierte Installation so nicht umsetzbar, danach müssete ich alles händisch bauen.

Gibt es mit 0.3.3 bekannte Probleme mit EPG Scan?
Habe die entsprechende Option im Plugin aktiviert (also dass EPG Scan erlaubt ist), aber selbst wenn ich beim vdr einen EPG Scan erzwinge (aus dem Menu oder per svdrpsend) passiert nichts. Wechsel ich hingegen auf einen Kanal auf dem ich vorher kein EPG hatte, wird dieses sofort empfangen und benutzt.
Es handelt sich um einen vanilla VDR 2.1.6 (selbstkompiliert mit wenigen Plugins) unter Debian Squeeze (als chroot auf meinem NAS). Davor hatte ich lange einen Netceiver, seit kurzem eine OctopusNet mit 4 Tunern, 2 davon für diesen vdr.

Das ist recht ärgerlich, da ohne aktuelles EPG meine Suchtimer nicht funktionieren...

ja und gleichzeitige Aufnahmen auf zwei unterschiedlichen Transpondern funktionieren auch (laufen gerade)... gibt es normalerweise einen Logeintrag wenn der EPGScan startet?

Zitat von Razorblade

ja und gleichzeitige Aufnahmen auf zwei unterschiedlichen Transpondern funktionieren auch (laufen gerade)... gibt es normalerweise einen Logeintrag wenn der EPGScan startet?

Also bei mir geht Bakcground EPG Scan mit VDR 2.1.6 (selbstkompiliert) weder auf OpenSuse, noch auf Raspbian noch auf Arch LInux. Eine Analyse des Netzverkehrs mit dem Octopus läßt mich vermuten, dass bei EPG Scan das "PLAY" Kommando and den RTSP nicht geschickt wird, deshalb schickt der Octopus auch keine Daten.

Wenn ich einen Kanal aufnehme oder angucke, wird das EPG dieses Kanals (und aller anderen Kanäle auf dem gleichen Transponder) emfpangen und gespeichert.

Natürlich tritt das Phänomen nur auf, wenn keine "echte" DVB Karte im System steckt.

Hat jemand eine Idee? Sollen wir es an Rolf weitergeben, ich kann gerne bei mir mal den Debugger anschmeißen oder zusätzliche Outputs einbauen, hab das auf einem Test System isoliert? fnu hat doch einen guten Draht zu Rolf, kannst Du da helfen?

Zitat von nafets227

Eine Analyse des Netzverkehrs mit dem Octopus läßt mich vermuten, dass bei EPG Scan das "PLAY" Kommando and den RTSP nicht geschickt wird, deshalb schickt der Octopus auch keine Daten.
Hat jemand eine Idee?

Unfortunately I'm too busy to check this out by myself at the moment, but if no PLAY command is sent during the EIT scan, the plugin misses core VDR's SetPid commands. There are also some open bugs in device selection code and those might be also root causes for EIT scan problems.

In other words, I'd take a closer look at methods cSatipDevice:: SetPid() (some pids are set on) and SatipDevice:: SetChannelDevice() (correct device is selected) while running the EIT scan. The plugin should send a RTSP/PLAY command always after any pid changes.