vdr 2.6.4: svdrp: falsche Kanalangabe nach Kanalumschaltung

    Ich habe ein merkwürdiges Phänomen bei der Kanalumschaltung mit svdrp.


    Setup: vdr: 2.6.4 als headless server in container mit plugin satip an Selfsat IP22, als clients diverse Geräte mit Kodi via vnsi.


    Die Kanalumschaltung mit svdrp gibt nach Umschaltung den falschen Kanal zurück (immer Kanal 1), tuned aber korrekt auf den gewählten neuen Kanal.

    Dies ist auch im webinterface des satip-servers zu sehen, der neue Transponder wird korrekt verwendet.

    Auch "plugin satip info" zeigt, dass auf den richtigen transponder getuned ist, gibt aber ebenfalls die falsche channelinfo zurück.



    Beispiel: switching to channel 19 mit svdrpsend


    command and output:

    $ svdrpsend chan 19 <-- das ist bei mir der RTL Transponder

    220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:33 2023; UTF-8

    250 1 Das Erste HD

    221 vdr closing connection


    syslog:

    2023-11-13T10:28:57.896974+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 client connection accepted

    2023-11-13T10:28:57.897033+01:00 vdr vdr: [174] SVDRP vdr > 127.0.0.1:41932 server created

    2023-11-13T10:28:57.897246+01:00 vdr vdr: [174] switching to channel 19 S19.2E-1-1089-12003 (RTL Television)

    2023-11-13T10:28:58.162810+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 connection closed

    2023-11-13T10:28:58.162918+01:00 vdr vdr: [174] SVDRP vdr < 127.0.0.1:41932 server destroyed

    2023-11-13T10:29:29.256481+01:00 vdr vdr: [142] SATIP: Idle timeout - releasing [device 0]


    checking satip plugin stat and info:


    root@vdr:/build/vdr-2.6.4# svdrpsend plug satip stat

    220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:46 2023; UTF-8

    900-Device: SAT>IP 0

    900-CardIndex: 0 HasLock: yes Strength: 61 Quality: 100 Live: yes

    900-Transponder: 112188

    900-

    900-Device: SAT>IP 1

    900-CardIndex: 1 HasLock: no

    900-Transponder: 212363

    900-

    900-Device: SAT>IP 2

    900-CardIndex: 2 HasLock: no

    900-Transponder: 212480

    900-

    900-Device: SAT>IP 3

    900-CardIndex: 3 HasLock: no

    900-Transponder: 212522

    900

    221 vdr closing connection



    root@vdr:/build/vdr-2.6.4# svdrpsend plug satip info

    220 vdr SVDRP VideoDiskRecorder 2.6.4; Mon Nov 13 10:29:48 2023; UTF-8

    900-SAT>IP device: 0

    900-CardIndex: 0

    900-Stream: rtsp://192.168.1.159/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34 (Unicast) [stream=130]

    900-Signal: lock=1 strength=61 quality=100 frontend=1

    900-Stream bitrate: 840 kbit/s

    900-Buffer bitrate: 0 kbit/s

    900-Buffer usage: 0/16384 kbit (0,0%)

    900-Channel: Das Erste HD;ARD:11494:HC23M5O35P0S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0

    900-Active pids:

    900-Active section filters:

    900-Filter 0: 1028 ( 552 kbit/s) Pid=0x12 (EIT)

    900-Filter 1: 14 ( 0 kbit/s) Pid=0x14 (TDT)

    900-Filter 2: 29 ( 0 kbit/s) Pid=0x00 (PAT)

    900-Filter 3: 7 ( 0 kbit/s) Pid=0x11 (SDT)

    900 Filter 4: 2 ( 0 kbit/s) Pid=0x10 (NIT)

    221 vdr closing connection

    root@vdr:/build/vdr-2.6.4#

    Ist bei mir mit einer OctopusNet genau so. Ist wohl ein Bug im VDR oder im satip Plugin.

    Kann ich nicht bestätigen. Hier ist mit 2.6.4 und satip alles korrekt. Habe einen Kathrein EXIP 418.

    Oh, nein. Aber ich schau dann mal am headless Server.

    Hast recht. Stimmt am Server hier auch nicht.

    ja, dummydevice ist klar, doch soll vdr ja auch ohne dieses laufen (und tut es auch).

    Mal sehen, was kls sagt, er will sich das ansehen. Wäre schön, wenn es auch ohne dummydevice gehen würde.

    Sorry, hat jetzt doch etwas länger gedauert, bis ich mir das näher anschauen konnte.

    Was in diesem Zusammenhang noch interessant wäre ist das Log vom Start des VDR. Insbesondere die Zeilen, wo es um das "primary device" geht.

    Der "current channel" ist ja der "live" Kanal, der direkt auf dem VDR wiedergegeben wird. Bei einem "headless" System macht das schon mal gar keinen Sinn, denn dort kann ja nichts wiedergegeben werden. Man könnte also entweder den CHAN-Befehl so ändern, dass er prüft, ob das primary device wiedergeben kann, und wenn nicht, eine Fehlermeldung liefert. Oder dafür sorgen, dass CHAN am Ende einfach den Kanal zurückgibt, der gefordert wurde (falls es keine andere Fehlermeldung gegeben hat, z.B. dass der Kanal nicht existiert). Letzteres wäre aber eigentlich nur Augenauswischerei, denn der CHAN-Befehl ist auf einem headless System eigentlich sinnlos.

    Danke für das feedback. Ein aktuelles log habe ich leider nicht, der letzte start war vor 27 Tagen.

    Auch wenn CHAN auf einem headless eigentlich sinnlos ist, so nutze ich es doch, um einen EIT-scan anzustossen. Daher wäre die Rückgabe des gewählten Kanals in meinen Auge die konsistente Lösung. Den automatischen EIT-scan kann ich in meinem Setup leider nicht verwenden, dann hängt sich meine Selfsat IP22 (mit SATIP-Plugin) permanent auf und muss neu gestartet werden. Anscheinend sind die Kanalwechsel zu schnell für das arme Ding.

    Ich mache jetzt den EIT scan über ein nächtliches shell script, dass alle 40s den Kanal wechselt. Das klappt ohne Probleme. Es wäre nur schön, als feedback für das script den gewählten Kanal zurück zu bekommen. Alternativ könnte der EIT-scan vlt. da mit einem Delay-Parameter künstlich langsam gemacht werden? Letztendlich liegt das Problem hier nicht im vdr, sondern in der IP22.

    Zitat von clh27

    Alternativ könnte der EIT-scan vlt. da mit einem Delay-Parameter künstlich langsam gemacht werden?

    Du könntest in eitscan.h

    ScanTimeout = 40

    setzen.

    Zitat von clh27

    Letztendlich liegt das Problem hier nicht im vdr, sondern in der IP22.

    Sehe ich auch so. Umschalten sollte immer beliebig schnell möglich sein, ohne dass sich was aufhängt.

    Zitat von clh27

    Es wäre nur schön, als feedback für das script den gewählten Kanal zurück zu bekommen.

    Wenn du den Kanal explizit mit "CHAN nn" wechselst, dann kennst du doch den Kanal ("nn") bereits?


    BZW: Der EIT-Scan schaltet nicht durch "Kanäle", sondern durch "Transponder" (auf denen typischerweise meherere Kanäle liegen).

    Zitat von kls
    ...

    "headless" System macht das schon mal gar keinen Sinn, denn dort kann ja nichts wiedergegeben werden. Man könnte also entweder den CHAN-Befehl so ändern, dass er prüft, ob das primary device wiedergeben kann, und wenn nicht, eine Fehlermeldung liefert. Oder dafür sorgen, dass CHAN am Ende einfach den Kanal zurückgibt, der gefordert wurde (falls es keine andere Fehlermeldung gegeben hat, z.B. dass der Kanal nicht existiert).

    Letzteres wäre aber eigentlich nur Augenauswischerei, denn der CHAN-Befehl ist auf einem headless System eigentlich sinnlos.

    Hi


    Ich nutze svdrp viel und headless. CHAN sollte nicht einen Fehler melden. Denn es würde Scripten die falsche Rückmeldung liefern. Kanal Nummer fände ich OK

    Community Doks: https://vdr-projects.github.io/


Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden