SAT>IP Plugin und Fritz!WLAN Repeater DVB-C

  • Hallo zusammen,


    ich habe hier den vdr-1.2.6 auf einem RPi installiert.
    Dazu dann das vdr-satip-plugin und das vdr-rpihddevice-plugin.


    Der Fritz SAT>IP (KABEL>IP) Server wird auch gefunden, jedoch bleibt es schwarz.
    Auf der Homepage des Plugins steht, dass das Plugin auch DVB-C unterstützen würde.
    Bis vor kurzem hatte ich einen Octopus Net DVB-C hier, mit dem es funktionierte.
    Die RTSP-URLs, die beim Octopus Net DVB-C auf einem PC mit VLC funktionierten, funktionierten auch beim Fritz!WLAN Repeater DVB-C auf diesem PC mit VLC.


    Weiß da jemand genaueres?
    Die aktuelle libcurl Version 7.36 wird verwendet. Welche XML Parser library sollte man nehmen? Sind beide getestet?


    Gruß
    Nano


    /var/log/syslog



    http://192.168.10.4:49000/satipdesc.xml


  • SatIP Plugin direkt auf dem Rasp? Ich hatte da nur Stotterbild.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Code
    Oct 29 07:19:41 raspberrypi vdr: [2444] SATIP: cSatipDevice::ProvidesChannel(0)
    Oct 29 07:19:41 raspberrypi vdr: [2444] SATIP: cSatipDevice::ProvidesTransponder(0)
    Oct 29 07:19:41 raspberrypi vdr: [2444] info: Kanal nicht verfügbar!


    Das hier ist offenbar das Problem bei mir.

  • Funktioniert es denn mit dem streamdev-Plugin flüssig bei Dir?


    Ja, auch mit HD

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Könnte auch sein, dass das Plugin mit dem Fritz SAT>IP Server nicht kompatibel ist?!

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Ok, danke. Hattest Du es auf dem RPi auch mal mit dem vtuner/satip client probiert?


    Nein.


    Das IPTV-Plugin wäre evtl. noch eine Variante. ich habe hier http://www.vdr-portal.de/board…ptv-plugin-mit-octopusnet mal einen Thread dazu gestartet, da mich das auch interessieren würde.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • erweiterte Version mit DVB-C und DVB-T des vtuner/satip clients, die auf dem Google Code basiert


    Das steht aber das der Fritz!Wlan repeater noch nicht geht...
    Zitat: Fritz!WLAN Repeater DVB-C funktioniert aktuell noch nicht. Keine Ahnung warum. Vermutlich Abweichungen im RTSP Protokoll.


    Summasummarum:


    Wireshark anschmeißen und Netzwerktraffic vom Verbindungsaufbau mitschneiden und dann Rolf Ahrenberg aka rofafor zur Verfügungstellen.


    lg,
    joe

  • So. Ich habe den VDR-2.1.6 jetzt erstmal mit dem vtuner/satip client und dem Dummydevice Plugin auf meinem Notebook (Debian Wheezy) laufen.
    EPG-Daten kommen rein.


    Sniffen mit tcpdump ergab leider, dass AVM den RTCP Pakettyp 204 nicht implementiert hat. (Siehe Seite 54 in der SAT>IP Spez. V1.2)
    Es kommen nur Pakete vom Typ 200 (Sender report SR). Damit gibt es schonmal für den Client keine Möglichkeit zu prüfen, ob der Tuner einen LOCK hat.
    Das VDR SATIP-Plugin wertet das nämlich aus. Der vtuner/satip client wertet das nicht aus.


    Ich habe eine Support-Anfrage an AVM geschrieben mit der Bitte, diesen Pakettyp doch einzubauen.

  • The real mystery here is actually the channel 1 in your channels.conf.

    channels.conf


    sources.conf

  • Kleiner Nachtrag.


    Ich habe auf dem RPi jetzt nochmal die Kombi vtuner/satip mit VDR-2.1.6 und dem rpihdoutput-Plugin getestet.
    Leider funktioniert an meinem Monitor die Auflösung 1920x1200 mit dem rpihdoutput-Plugin nicht. Wenn ich auf 1920x1080 festsetze, erhalte ich ein flüssiges Bild und kann zwischen den ersten Kanälen umschalten.
    Geht sogar erstaunlich fix.


    -> Die Kombi läuft also. Ich habe den vtuner/satip Client auf dem VU+ Forum genommen und im Makefile den vtuner Typ auf "original" gesetzt. Dazu dann den "vtuner_tweak" von dem ursprünglichen satip Client Projekt von Google Code.


    Der erste Eintrag in der Channels.conf funktioniert also.


    Ich habe dann den RPi nochmal neu gebootet, um das vtunerc.ko Modul loszuwerden. "rmmod" ging nicht.
    Dann habe ich den VDR nochmals mit dem SATIP>Plugin gestartet. Ich habe die Methode "hasLock" in tuner.c des Plugins angepasst, so dass sie nicht mehr auf das Feedback aus dem RTCP-Paket 204 angewiesen ist.


    Wenn ich jetzt mit tcpdump lausche, sehe ich nur den Request und die Response bzgl. Abfrage der XML-Datei. Anonsten bleibt alles ruhig. Kein RTSP-Request, keine RTP/RTCP Pakete.


    UPDATE:
    Achso, eine wichtige und merkwürdige Beobachtung noch.
    Bei der vtuner/satip fällt auf, dass VDR ca. jede Sekunde neben dem Tuner-Status auch jedesmal die PIDs neu setzt. Dabei sehe ich dann, dass sich die letzte PID in der Tabelle jedesmal ändert. Warum ist das so? Ich habe in den VDR-Einstellungen den EPG-Scan ausgemacht und das Update der Kanäle auch.

  • Ich denke, dass ich den Fehler im satip-Plugin gefunden habe.
    Den Hinweis gab der folgende Log-Eintrag:

    Code
    cSatipDevice::SetChannelDevice(0): no suitable server found


    Die Variable modelTypeM wird in

    Code
    cSatipServer::cSatipServer()

    zunächst auf eSatipModelTypeNone gesetzt.
    Hier wird anhand der Modellbezeichnungen geprüft, wie modelTypeM gesetzt werden muss.


    Für DVB-C ist bisher nur eine Sonderlösung bzgl. Octopus net enthalten, die aber den AVM Fritz!WLAN Repeater DVB-C nicht erkennt.
    Daher bleibt die Variable modelTypeM auf

    Code
    eSatipModelTypeNone

    .


    Später, wenn dann innerhalb von

    Code
    cSatipDevice::SetChannelDevice

    ein passender SAT>IP Server gesucht werden soll, liefert die Methode

    Code
    cSatipServers::Find()

    immer NULL zurück, da
    DVB-C angefordert ist, aber kein Server mit DVB-C in der Liste mit erkannten SAT>IP Servern vermerkt ist.


    Habe jetzt folgendes eingefügt:


    server.c:

    Code
    enum eSatipModule {
    	eSatipModuleDVBS2 = 0,
    	eSatipModuleDVBT,
    	eSatipModuleDVBT2,
    	eSatipModuleDVBC,
    	eSatipModuleCount
      };


    Code
    if (strstr(r, "DVBC")) {
           	modelTypeM |= cSatipServer::eSatipModelTypeDVBC;
           	if (char *c = strstr(r, "-"))
              	modelCountM[eSatipModuleDVBC] = atoi(++c);
           	else
              	modelCountM[eSatipModuleDVBC] = 1;



    server.h

    Code
    //  int Cable()           	{ return Match(eSatipModelTypeDVBC)  ? (Match(eSatipModelTypeDVBT2) ? modelCountM[eSatipModuleDVBT2] : modelCountM[eSatipModuleDVBT]) : 0; } // an ugly hack
      int Cable()           	{ return Match(eSatipModelTypeDVBC)  ? modelCountM[eSatipModuleDVBC]  : 0; }



    Jetzt wird endlich der RTSP-Request ausgelöst. Dieser sieht laut tcpdump auch gut aus. Aber es bleibt nur beim RTSP SETUP. Ein RTSP PLAY kommt nicht.

  • Noch was. Das Plugin generiert ja zunächst einen SETUP request ohne PIDs:



    Dieser wird korrekt beantwortet:


    Dann folgt später nach zwei OPTION requests der PLAY request:

    Code
    0x0030:  0f66 519b 504c 4159 2072 7473 703a 2f2f  .fQ.PLAY.rtsp://
    	0x0040:  3139 322e 3136 382e 3130 2e34 2f73 7472  192.168.10.4/str
    	0x0050:  6561 6d3d 3332 353f 6164 6470 6964 733d  eam=325?addpids=
    	0x0060:  3131 302c 3132 302c 3132 312c 3132 3520  110,120,121,125.
    	0x0070:  5254 5350 2f31 2e30 0d0a 4353 6571 3a20  RTSP/1.0..CSeq:.
    	0x0080:  350d 0a53 6573 7369 6f6e 3a20 3332 350d  5..Session:.325.
    	0x0090:  0a55 7365 722d 4167 656e 743a 2076 6472  .User-Agent:.vdr
    	0x00a0:  2d73 6174 6970 2f30 2e33 2e33 2028 6465  -satip/0.3.3.(de
    	0x00b0:  7669 6365 2030 290d 0a0d 0a          	vice.0)....


    Hier gibt es dann das Problem:


    Code
    0x0030:  0076 0a13 5254 5350 2f31 2e30 2035 3030  .v..RTSP/1.0.500
    	0x0040:  2049 6e74 6572 6e61 6c20 5365 7276 6572  .Internal.Server
    	0x0050:  2045 7272 6f72 0d0a 4353 6571 3a20 350d  .Error..CSeq:.5.
    	0x0060:  0a53 6573 7369 6f6e 3a20 3332 350d 0a52  .Session:.325..R
    	0x0070:  5450 2d49 6e66 6f3a 2075 726c 3d72 7473  TP-Info:.url=rts
    	0x0080:  703a 2f2f 3139 322e 3136 382e 3130 2e34  p://192.168.10.4
    	0x0090:  2f73 7472 6561 6d3d 3332 353f 6164 6470  /stream=325?addp
    	0x00a0:  6964 733d 3131 302c 3132 302c 3132 312c  ids=110,120,121,
    	0x00b0:  3132 350d 0a0d 0a                    	125....


    Ich befürchte, dass der SAT>IP Server auf dem Fritz-DVBC wirklich kaum etwas vom Standard vernünftig unterstützt.
    Hier vermute ich, dass er schlichtweg addpids und delpids nicht unterstützt. :(


    Das muss ich noch überprüfen.

Jetzt mitmachen!

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