Posts by x_v

  • DVBSky S952 / T9580: Kein Sat-Empfang bis Kernel-Modul neu geladen

    Hallo,

    ich habe zwei DVB-Karten, eine S952 DVB-S Doppeltuner und eine T9580 DVB-C/T + DVB-S Kombikarte. Beides erste Generation mit cx23885 Chipsatz.

    Zunächst hatte ich nur die S952 in meinem VDR mit Ubuntu 14.04 und es lief problemlos (Treiber von DVBsky runtergeladen/kompiliert). Nun habe ich den Rechner neu aufgesetzt mit Ubuntu 18.04, der Kernel 4.15 bringt den Treiber direkt mit. Nur leider hängen sich die Karten (ich hab auch je nur eine zur Zeit probiert) nach beim Sat-Empfang nach einiger Zeit auf (kann Minuten, Stunden oder manchmal auch Tage nach Start des VDRs passieren), nicht während des Empfangs, sondern bei Kanalwechsel. Neustart der VDR-Anwendung bringt nichts, erst neuladen der Kernelmodule, wobei es da auch zu Problemen kommen kann (Kernelmodul kann nicht entfernt werden und bleibt fehlerhaft geladen) und dann nur noch ein Neustart hilft. DVB-C Empfang bei T9580 scheint nicht betroffen zu sein.

    Ich hatte versucht den Treiber von der dvbsky-Seite zu kompilieren, aber der braucht wohl größere Änderungen, damit er mit Kernel 4.15 funktioniert.

    Ich weiß nicht ob es Ursache oder eine Folge des Problems ist, aber das steht im Syslog:

    Code
    vdr: [1122] ERROR: can't set filter (pid=65535, tid=02, mask=FF): Das Argument ist ungültig
kernel: [24495.034470] dmxdev: DVB (dvb_dmxdev_filter_start): could not set feed
kernel: [24495.034478] dvb_demux: dvb_demux_feed_del: feed not in list (type=1 state=0 pid=ffff)

    Was mich dabei irritiert, warum PID von 65535? PID ist im TS nur 13 Bit breit, das heißt maximal 8191. Soweit ich weiß bedeutet wenn man 8192 setzt, dass man alle PIDs möchte und nicht vom Treiber gefiltert werden soll nach PIDs. Kann es sein, dass hier zwei Fehler zusammenkommen? Der VDR setzt eine ungültige PID und der Treiber fängt den Fehler nicht ab sondern hängt sich auf?


    Jemand anderes das gleiche Problem oder einen Lösungsvorschlag oder Idee wie man das Problem weiter eingrenzt?


    Vielen Dank

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Ich habe ein Problem isoliert: Der VDR löscht die Events wieder. Ich habe vor ein paar Stunden durch die Kanäle gezappt, bis das Freesat EPG komplett war, alle Sender die ich in meiner Liste hatte (BBC, Channel 4, E4, Film4, More4, ITV1/2/3/4, Channel 5, 5 Star, 5 USA) hatten bis mindestens Sonntag abend volles EPG.

    Danach zu einem Sender auf 19.2° umgeschaltet und jetzt nach ein paar Stunden: Die Hälfte der Freesat Kanäle hat kein EPG mehr

    Hat da jemand eine Erklärung?

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Ja, das ist mir auch aufgefallen. Ich scheine vor allem Lücken zu haben: Ich habe die aktuelle und nächste Sendung, dann viele Stunden nichts und danach durchgängig.

    Ich habe jetzt zwei Änderungen vorgenommen:


    Ich habe in dem switch-Block in der Funktion cEitFilter:Process für die Freeview-PID einen eigenen Case gemacht:

    Code
    case 3842: {
         if (Tid >= 0x4E && Tid <= 0x6F)
            cEIT EIT(sectionSyncerHash, Source(), Tid, Data);
         }
         break;

    Damit werden noch auch tables mit den IDs 0x6? verarbeitet. Habe auch den Filter im Konstruktor geändert und die drei Zeilen durch eine ersetzt:

    Set(3842, 0x40, 0xC0);

    Mal schauen ob das einen Unterschied macht, ansonsten vergleiche ich nochmal die Funktion in der die Tabellen ausgewertet werden. Hatte es in der Vergangenheit auch mit EEPG manchmal Lücken im EPG, ich weiß nicht wie dein Empfang ist, aber ich wohne ziemlich an der Ausleuchtgrenze, die Transponder, die eng auf die britischen Inseln fokussiert sind (wie Channel 4 HD), bekomme ich nur bei gutem Wetter, vielleicht kommen daher mal Aussetzer (wobei im Moment der Empfang ziemlich gut ist).

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Ich habe mir das EEPG Plug-In angeschaut und festgestellt das ich Ewigkeiten brauchen werde um da durchzusteigen. Da fiel mir ein das ich vor vielen Jahren mal einen Freesat-Patch hatte, also habe ich danach gesucht in der Hoffnung der ist besser lesbar. Ergebnis: Ja, sehr viel besser.

    Doch noch viel besser, er funktioniert problemlos mit dem VDR 2.4 (er ist für VDR 2.2, ich hab ihn manuell einpflegt):

    http://www.rst38.org.uk/vdr/

    Insgesamt scheint ein Patch für Freesat sehr viel sinnvoller als ein Plug-In, weil effektiv nur wenige Zeilen Code hinzugefügt wird an Stellen an die kein Plug-In hinkommt (die Huffman-Dekodierung ist in eine eigene Datei ausgelagert). Für ein Plug-In muss man sehr viel Code vom VDR duplizieren (was EEPG getan hat).


    Daher empfehle ich statt EEPG einfach den Patch einzuspielen. Natürlich hilft das nur für Freesat, nicht für die anderen Formate die EEPG unterstützt.

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Meine ursprüngliche Aussage, das dort wieder die Funktion aufgerufen wird, war falsch, es wird eine Methode einer Klasse mit gleichem Namen aufgerufen. Dennoch ist das Problem nicht einfach lösbar, da hier alles in einer Klasse abläuft und auf die Objekte in der Klasse zugegriffen wird, das kann man nicht einfach in einen neuen Thread packen.

    Angesichts der Code-Qualität in allgemeinen wäre es wohl sinnvoll das mal komplett zu überarbeiten. Ich habe jedoch keine Ahnung von der internen VDR Struktur oder dem Plug-in-API. Auch scheint ein Großteil der Formate für 13° zu sein, ich hab nur 28.2° (Freesat).

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Das wird jetzt nicht mehr gehen, da die Funktion ja einen neuen Thread erzeugt, jetzt muss es ja im urprünglichen Thread, der den Lock hat, ausgeführt werden. Da die Funktion wenn man die ifdefs wegnimmt nur aus 5 Zeilen oder so besteht ist es wohl das einfachste das reinzukopieren in die andere Funktion.

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Dieses Problem scheint damit behoben zu sein, vielen Dank! Doch es kommt das nächste Problem: LOCK_CHANNELS_WRITE in der eit2.c verursacht jetzt die invalid lock sequence...


    Die gleiche Lösung wird hier wohl auch nicht funktionieren: Die Funktion selber ruft "GetChannelByID" auf, wenn ich in Thread A ein write lock hole, dann Thread B starte der auf ein read lock wartet aber Thread A das lock erst freigibt wenn Thread B fertig ist dann habe ich wohl ein dead lock.

    Ich denke die einfachste Lösung ist den Inhalt der Funktion GetChannelByID hier direkt einzufügen, das Lock ist ja schon da.

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Ich habe jetzt die 4 Patches in meinen VDR eingepflegt, als auch den für EEPG. Leider ohne Erfolg, aber ich denke ich habe das (eines von vielen?) Problem gefunden. EEPG hat eine Funktion "GetChannelByID" in der util.c die ein LOCK_CHANNELS_READ zu Beginn macht. Diese Funktion wird an diversen Stellen aufgerufen, auch von Funktionen die vorher schon andere Locks holen.

    Dummerweise kann man das LOCK_CHANNELS_READ nicht einfach verschieben, da es zusätzlich auch noch Variablen definiert...

    Insgesamt ist das EEPG Plugin meiner Ansicht nach ziemlich zusammengewürfelt. Zu diesem LOCK-Makros steht man braucht nicht unlocken, das passiert automatisch beim verlassen eines scopes, aber wann verlässt man einen scope?

  • [eepg] invalid lock sequence report ... mit vdr-2.4.0

    Hallo,

    ich kann das Problem bestätigen. Auch bei mir stürzt der VDR 2.4 regelmäßig ab mit EEPG (friert ein und wird vom watchdog beendet). Ich hab versucht den Fehler zu finden, nur zum einem habe ich keine Ahnung von der VDR Plug-In-API und zweitens ist der Code vom EEPG doch ziemlich zusammengewürfelt und nicht gut zu lesen.

    Wir das Plug-In überhaupt noch aktiv betreut?

  • VDR stürzt alle paar Stunden ab (VDR 2.4.0, Ubuntu 18.04)

    Habe die Plugins einzeln hinzugefügt: streamdev-server, epgsearch und live verursachen keine Probleme.

    EEPG dazu und der VDR stürzt gelegentlich ab, leider ohne besonders aussagekräftige Fehlermeldung:

    Code
    vdr[17429]: exception occured: pthread_mutex_lock failed: errno 22: Das Argument ist ungültig

    Da EEPG selber keine pthreads verwendet, provoziert es den Fehler wohl woanders, irgendeine Idee?

  • VDR stürzt alle paar Stunden ab (VDR 2.4.0, Ubuntu 18.04)

    Leider zu früh gefreut: Das Problem scheint nur aufzutreten, wenn ein Client verbunden ist. Er stürzt wiederholt ab, einmal gab es erfreulicherweise etwas mehr im Log:

    EEPG scheint irgendwie involviert zu sein. Nur vom Gefühl scheint das Problem zu sein, dass EasyStream regelmäßig die Kanäle abfragt und sich dabei mit EEPG stört. Ich kann dieses invalid lock sequence leider nicht interpretieren, kann es sein, dass auch wenn es nicht im log auftaucht, es auch in anderen Fällen für die Abstürze verantwortlich ist? Leider sind multithreading Probleme schwer zu reproduzieren und damit extrem schwer zu debuggen. Ideen wie ich weiter vorgehen soll? Ich werde jetzt erst nochmal den VDR mit aktivem Client laufen ohne EEPG laufen lassen und schauen ob das Problem weg ist.


    Nachtrag:

    EEPG ist nicht der (einzige?) Übeltäter, auch ohne EEPG gibts Abstürze wenn ein client verbunden ist. Nehme jetzt alles außer stremdev raus und schaue ob er bis morgen früh durchläuft

  • VDR stürzt alle paar Stunden ab (VDR 2.4.0, Ubuntu 18.04)

    Danke für die schnelle Hilfe: Es scheint in der tat das EEPG Plug-In gewesen zu sein. Ohne das ist er >12 Stunden problemlos gelaufen. Ich hab heute morgen jetzt wieder mit EEPG gestartet, jedoch EEPG dahingehend modifiziert, dass nur noch Fehler protokolliert werden und das syslog nicht durch jedes event vollgespammt wird (das war rund 60 MB und gefühlte 95% der Einträge waren EEPG). Ich vermute das könnte eine Fehlerursache gewesen sein, seit heute morgen auch durchgehend ohne Absturz.

  • VDR stürzt alle paar Stunden ab (VDR 2.4.0, Ubuntu 18.04)

    Hallo,

    ich hatte etwas Zeit und habe jetzt meinen VDR komplett neu eingerichtet:

    Ubuntu 18.04 Server

    VDR 2.4.0


    Ziel ist dann Kodi als frontend zu verwenden, aber soweit bin ich noch nicht: In unregelmäßigen Abständen (alle 1-3 Stunden) stürzt der VDR ab, hier die syslog Einträge dazu:

    Wie man sieht gibt es ein timeout vom watchdog (90 Sekunden), ich habe aber im VLC beim schauen auf einem anderen Rechner über streamdev nur eine Unterbrechung von wenigen Sekunden. Als SVDRP client kommt EasyStream zum Einsatz. Irgendeine was die Ursache sein könnte? Der VDR wird folgendem Kommando von systemd aufgerufen:

    /usr/local/bin/vdr -v /video -w 90 -c /home/vdruser/vdrconf -P "bösesplugin" -P "eepg" -P "epgsearch" -P "live" -P "streamdev-server"

    Es ist noch kein frontend installiert (geplant ist Kodi mit vsni).

    Vielen Dank

  • softhddevice video: 11:15:17.498+8888 0 0/\ms 80+2 v-buf

    Das kommt vor dem 8888:

    Code
    Feb  8 07:15:46 xvdr vdr: codec/video: ffmpeg/libav buggy: width or height zero
Feb  8 07:15:46 xvdr vdr: video: decoder buffer empty, duping frame (1/2) 0 v-buf
Feb  8 07:15:46 xvdr vdr: video: --:--:--.---   +0    0   0/\ms   0+0 v-buf
Feb  8 07:16:46 xvdr vdr: video: --:--:--.---+8888 1346   0/\ms  13+2 v-buf


    Ich hab ein bisschen rumgebastelt und das Problem gefunden: ffmpeg git ist das Problem, mit Version 2.1.3 geht es einwandfrei (kompilert mit --disable-debug --enable-shared --enable-gpl). Wobei die ffmpeg/libav buggy Meldung immer noch kommt.

  • softhddevice video: 11:15:17.498+8888 0 0/\ms 80+2 v-buf

    Hallo,
    ich habe das gleiche (oder ein ähnliches) Problem:

    Code
    Feb  8 03:32:40 xvdr vdr: video: decoder buffer empty, duping frame (1433/949) 0 v-buf
Feb  8 03:32:40 xvdr vdr: video: --:--:--.---+8888 1434   0/\ms   9+2 v-buf
Feb  8 03:33:40 xvdr vdr: video: decoder buffer empty, duping frame (1434/4665) 7 v-buf
Feb  8 03:33:40 xvdr vdr: video: --:--:--.---+8888 1468   0/\ms   8+2 v-buf
Feb  8 03:34:40 xvdr vdr: video: decoder buffer empty, duping frame (1436/8093) 0 v-buf
Feb  8 03:34:40 xvdr vdr: video: --:--:--.---+8888 1438   0/\ms   8+2 v-buf


    Die Ausgabe erfolgt über VDPAU mit 50Hz (Fernseher zeigt auch 50Hz an). Der Ton kommt mehrere Sekunden zu spät.
    Das Problem tritt jetzt auf nachdem mein VDR wieder läuft (DVB-Karte war kaputt, bis ich das gemerkt hatte, hatte ich schon diverse Updates etc. eingespielt). Hab softhddevice git aktuell mit ffmpeg git kompiliert. Hab sowohl den aktuellen als auch den Nvidia-Treiber den ich vorher hatte (319.60) ausprobiert, kein Unterschied.
    Woran kann das liegen? An ffmpeg, doch lieber libav? Hat sich an softhddevice was geändert was das Problem verursacht?
    Vielen Dank

  • yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

    Hallo,
    ich weiß nicht ob ich zu doof bin das zu finden: Irgendwo stand das es sich um Open-Source Hardware handelt, gibt es irgendwo den Schaltplan und den Firmware-Source zum Download? Ich möchte das Teil nicht nachbauen (das ist für 24€ wohl auch nicht machbar), aber ich hätte gerne eine externe Stromversorgung und eine Echtzeituhr, damit das Netzteil nicht immer laufen muss, sondern es von dem yaUsbIr mit Relais eingeschaltet wird. Da die restlichen Funktionen wirklich gut aussehen, würde ich die Funktionen lieber ergänzen statt das Rad neu zu erfinden (ich hoffe das ist mit einem AVR gemacht, sonst ist für mich das Rad neu zu erfinden vielleicht doch einfacher).
    Vielen Dank

  • [remote-plugin] Wie Fernbedieung konfigurieren?

    Hab Ubuntu 13.10, eine DVBSky S952, die Fernbedienung die ich hier hab ist von Technotrend (die hat die meisten Tasten), also nicht die Original.
    Werde mal schauen ob das mit dem keytable klappt. Ich dachte dafür wäre die remote.conf um bestimmten ir-codes eine Funktion zuzuordnen.