Fehler bei: 1. Aufnahme auf ZDF HD, danach 2. Aufnahme auf rbb Berlin HD (während die 1. Aufnahme noch aufnimmt)

  • Hi,


    Ich kann den Fehler reproduzieren:

    1. Aufnahme auf ZDF HD starten
    2. Aufnahme auf rbb Berlin HD starten (die 1. Aufnahme nimmt noch auf)

    VDR verwendet für die 2 Aufnahme das gleiche Device wie für die 1. Aufnahme. Die 1. Aufnahme ist "kaput". (ev. vorher dafür sorgen, dass andere Devices nicht verwendet werden können, z.B. wegen anderer Aufnahmen).

    Aus der channels.conf:

    Zitat

    ZDF HD;ZDFvision:11361:HC23M5O35P0S1:S19.2E:22000:6110=27:6120=deu@3,6121=mis@3,6123=mul@3;6122=deu@106:6130;6131=deu:0:11110:1:1011:0

    rbb Berlin HD;ARD:10891:HC23M5O35P0S1:S19.2E:22000:5311=27:5312=deu@3,5313=mis@3,5317=qks@3;5316=deu@106:5314;5315=deu:0:10351:1:1061:0


    Hier noch zur Dokumentation:


    "Normalerweise" funktioniert mein System recht gut, und ich habe 0 oder 1 TS Fehler bei Aufnahme.

    Manchmal gibt es aber Ausreißer, letzte Nacht wurde Gladiator mit 346501 TS Fehlern aufgenommen.


    Also, was hat VDR letzte Nacht so angestellt:

    • 20:11 - 23:43: Harry Potter auf SAT.1 , kein TS Fehler
    • 00:15 - 02:40: Gladiator auf ZDF HD, 346501 TS Fehler bei Aufnahme
    • 00:45 - 02:37: Only Lovers Left Alive auf rbb Berlin HD, kein TS Fehler

    Liegt es an ZDF HD? Gleich noch eine Testaufnahme auf ZDF HD gestartet, kein Fehler.

    Im Syslog:


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Schalte die Logfile des Treibers ein

    /etc/sundtek.conf

    loglevel=max


    Das zeigt mal an ob die Daten die via USB übertragen wurden in Ordnung sind

    /var/log/mediasrv.log wäre der Output


    Was nicht schaden würde wäre eine Statistik wie der RPI4 zu dem Zeitpunkt getaktet war (wie viel MHz).

    Die Frage wäre auch was dort alles via USB dranhängt?


    Eventuell auch einfach nur mal /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal (adapterX wobei X für den Tuner steht) im Hintergrund mitlaufen lassen.

  • Ich möchte erst mal verstehen, warum VDR für "ZDF HD" und "rbb Berlin HD" das gleiche Device verwendet.

    Das kann doch nicht funktionieren (?).

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Wenn die Sender auf dem selben Transponder liegen, dann geht das in der Regel schon...


    Ich hatte schon 7 aufnahmen mit meinen 4 Tunern

  • Die Frage war sicher rhetorisch, aber trotzdem:

    ZDF HD -> Frequenz: 11362 (Transponder 11)

    RBB Berlin HD ->Frequenz: 10891 (Transponder 61)

    Also darf hier der VDR nicht versuchen, das gleiche Device zu verwenden.

  • Laut deiner Logdatei wird für ZDF device 2 und für rbb device 1 verwendet. Wenn der USB-Durchsatz das erlaubt, sollte alles funktionieren

    vdr-2.6.4

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

  • Zitat

    Jan 22 00:18:27 rpi4s vdr: [1234567] switching device 2 to channel 2 S19.2E-1-1011-11110 (ZDF HD)

    Zitat

    Jan 22 00:43:32 rpi4s vdr: [1234567] switching device 2 to channel 30 S19.2E-1-1061-10351 (rbb Berlin HD)

    Ich sehe da zweimal device 2.


    Zwischendurch hat er mal device 1 vermutlich zum VPS checken benutzt, aber aufgenommen wurde beide Male auf device 2.

  • Hi Tom Joad,


    Danke Für den Hinweis. Ich habe noch mal in's Log geschaut, und


    Gefunden. Das bestätigt Deine Analyse.

    Aber:

    Wenn für ZDF device 2 verwendet wird, warum schaltet dann VDR device 2 auf rbb?

    Zitat

    Jan 22 00:43:32 rpi4s vdr: [1234567] switching device 2 to channel 30 S19.2E-1-1061-10351 (rbb Berlin HD)

    ~Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Merkwürdiger ist

    Zitat

    Jan 22 00:43:31 rpi4s vdr: [1234567] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD)

    vdr-2.6.4

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

  • Hi,


    Ich kann den Fehler inzwischen nicht mehr reproduzieren.

    Meine Analyse:

    Jan 22 00:43:32 cDevice->Receiving() hat "false" für device 2 zurückgegeben.

    Andernfalls hätte "Jan 22 00:43:32 rpi4s vdr: [1234567] switching device 2 to channel 30 S19.2E-1-1061-10351 (rbb Berlin HD)" nicht passiren dürfen, zumindest hätte vorher der reciever thread gestoppt werden müssen.


    Warum "Jan 22 00:43:32 cDevice->Receiving() hat "false" für device 2 zurückgegeben."?

    Das habe ich nicht verstanden, nach log lief da der "device 2 receiver thread" noch.


    Da ich den Fehler nicht mehr reproduzieren kann, werde ich weiter beobachten, ob der Fehler wieder auftritt, und dann weiter machen.

    Code
    Jan 22 00:18:27 rpi4s vdr: [1234567] switching device 2 to channel 2 S19.2E-1-1011-11110 (ZDF HD)
    Jan 22 00:18:27 rpi4s vdr: [1234567] timer 6 (2 0100-0325 VPS 'Gladiator') start
    Jan 22 00:18:41 rpi4s vdr: [1252670] device 2 receiver thread started (pid=1234567, tid=1252670, prio=high)
    Jan 22 00:18:41 rpi4s vdr: [1252671] device 2 TS buffer thread started (pid=1234567, tid=1252671, prio=high)
    Jan 22 00:43:32 rpi4s vdr: [1234567] switching device 2 to channel 30 S19.2E-1-1061-10351 (rbb Berlin HD)
    Jan 22 02:40:00 rpi4s vdr: [1252671] device 2 TS buffer thread ended (pid=1234567, tid=1252671)
    Jan 22 02:40:00 rpi4s vdr: [1252670] buffer stats: 279368 (1%) used
    Jan 22 02:40:00 rpi4s vdr: [1252670] device 2 receiver thread ended (pid=1234567, tid=1252670

    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hi,


    Der Fehler ist wieder aufgetreten. Hier der Syslog. Sieht recht ähnlich aus.



    Der Fehler sist wohl "Feb 11 20:15:00 rpi4s vdr: [2085641] menu.c switching device 2 to channel 25 S19.2E-1-1007-4914 (ServusTV HD Deutschland)".

    Anmerkung: Ich habe VDR zur Fehlersuche gepatched, um zu sehen, wo diese Meldung herkommt. Ohne Patch wäre es "Feb 11 20:15:00 rpi4s vdr: [2085641] switching device 2 to channel 25 S19.2E-1-1007-4914 (ServusTV HD Deutschland)"


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Für mich sieht es eher so aus, als ob das dauernde switching to channel 1 das Problem ist.

    Das scheint eine Karte zu beanspruchen.


    Das kommt auch exakt alle 11 Sekunden.

    Keine Ahnung was da los ist, so was hab ich noch nicht gesehen.

    Gruss
    SHF


  • Das ist normales Verhalten, wenn eine VPS-Aufnahme in Kürze fällig ist und Live-TV auf einem anderen Transponder läuft, aber kein weiteres Device mehr frei ist. Das geht solange, bis VPS Aufnahmebereitschaft signalisiert. Es gibt ein schwarzes Bild mit "Aufnahme beginnt in Kürze", dann wieder Live-TV. Ist normalerweise auch kein Problem. Beginnt die Aunahme, wird der Aufnahmekanal auf Live gelegt.

    vdr-2.6.4

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

  • Gut zu wissen. VPS verwende ich nach anfänglichen, schlechten Erfahrungen schon ewig nicht mehr.


    Priorität von der Aufnahme niedriger als vom Live-TV?

    (Ich wüsste jetzt aber nicht, wie man das hinbekommt.)

    Dann dürfte das Problem nicht auftreten, wenn man das Live-Bild auf den Kanal der 2. Aufnahme stellt.

    Gruss
    SHF


Jetzt mitmachen!

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