Posts by Fourty2

  • [epg2vdr] Database version 0, insert into vdrs

    Habe so einen ähnlichen Fehler.


    Ab und an zerlegt es die Datenbank, MariaDB startet dann neu und mit etwas Glück gibt es nur epg2vdr: SQL-Error in 'execute(stmt_execute)' ohne, daß es den VDR (wiederholt) mitreißt.


    Habe allerdings von den letzten 7 Tagen Datenbank Backups, die ich dann einfach wieder zurückkopiere, bis die DB wieder ok ist. Automatische Datenbankreparatur konnte den ursächlichen Fehler nie beseitigen.


    Hatte bisher allerdings eher den Verdacht, daß das auftrat, wenn ein VDR ungünstig abstürzte (CI Hänger, ö.ä.) oder ich beim Umbau auf "Non-Blocking API" was übersehen habe.


    Grüße,

    Stefan

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    Quote from HelmutB

    Ich würde hier eher ein schwaches Signal vermuten.

    Das habe ich als erstes geprüft. Da sich das Verhalten zwischen Sonne und Regen nicht unterschied, habe ich es auf den CAM-Zweig eingegrenzt. FTA ging ja auch immer.

    Quote from HelmutB

    Wenn es das aber nicht ist und du ein DD-CI verwendest, versuche es einmal mit einer kleineren Buffergröße beim ddci2-Plugin - z.B. mit --bufsz 500 statt dem Default von 1500.

    Das mit dem Buffer interessiert mich. Warum? Ich hätte ihn größer gemacht.


    Tatsächlich nutze ich am J3160-ITX Board eine Octopus-Mini V2 (Mini-PCIe) und das zugehörige DuoFlex-CI. Und da lag auch das Problem.


    Die Octopus paßte 2017 nicht wirklich in den Mini-PCIe-Slot, Tastaturanschluß im Weg (ausgelötet) einziges Befestigungloch genau am TAB1 Stecker - naja, lief irgendwie. :saint:


    Später eine Mini-PCIe-Verlängerung aufgetrieben und die Octopus ins Gehäuse geklebt. Dabei muß ich wohl die Kabel TAB1<->TAB2 vertauscht haben. Das CAM in CI-Port 1 störte das aber wohl nicht. Nach dem TV Test hatte ich dann CI-Port 2 erwischt, nur noch JuSchu-Pin Abfrage alle 2 Sek im Log ... also das Kistchen geöffnet, Kabel korrigert und anders verlegt und dabei gemerkt, das einer der CI-Slot-Anschlußpins zur Leiterplatte des Duoflex zum Nachbarn verbogen war. Das war es wohl wirklich. :wow


    Muß vor ein paar Monaten passiert sein, als die Stromversorgung einer Platte wackelig war und ich Kabel getauscht habe.

    :doof


    Geht also seit heute wieder.


    Stefan

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    Quote from HelmutB

    Fourty2 Solche Meldungen habe ich vor längerer Zeit auch einmal im syslog gefunden, die Ursache war damals Datenmüll aus dem Modul.

    Was sagt denn die Info-Datei - gibt es Fehler in der Aufnahme?


    10k+ Fehler.


    Hatte MTD dann kurz deaktiviert, da waren es dann TS-Cont-Fehler. Bei Empfangsfehlern wolkiger Art hätte/habe ich aber FEC-Fehler dabei - sollte es also nicht sein.


    Edit:

    Im TV tut das Modul. Also wohl was im DDCi2/Ciplus System struppig. Kernel war es nicht, versuchen wir mal einen VDR-2.6.1.



    Stefan

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    Hallo zusammen,


    ich hab aus heiterem Himmel sowas hier:

    Code
    Feb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF)
Feb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF)
Feb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF)
Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 512 (0200)
Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (5) in PID 1360 (0550)
Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 732 (02DC)
Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (28) in PID 7170 (1C02)
Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 594 (0252)


    Kommt und geht. Es läuft keine Aufnahme. Passierte aber heute morgen auch mit Aufnahmen.


    Was könnte das sein?


    Stefan

  • und Intel hat doch eine schlechtere Bildqualität als Nvidia!

    villeneuve :

    Das kommt halt darauf an, welche Quellen man wo wiedergibt und ob der angeschlossene Fernseher das zielsicher automatisch umschalten kann.


    Den VDR nutzen wir für Fernsehen und Aufnahmen. Insbesondere per "Himmel" kamen bisweilen (also zumindest zur NVidia-Zeit bis etwa 2017) Daten mit sehr "hellem" Schwarz. Steht die Kette komplett auf Limited-RGB, ist das "helle" Schwarz auch dann schwarz. Daher dort Limited-RGB.


    Kodi nutzen wir nur für Bilder, Musik und Musikvideos, nicht als VDR-Backend, da paßt Full-RGB hier besser.

    Das ist aber vermutlich auch sehr vom TV abhängig.


    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Also bisher funktioniert Dein letzter Patch ... Danke :)


    Das 2 minütige Hin- und Herschalten macht das "VPS" schon immer.

    Bei "normalen" Timer-Aufnahmen passiert das nur unsichtbar auf freien Karten.


    VPS ist bei mir wegen epg2vdr aus, sonst brechen die Aufnahmen ab, sobald sie in der Datenbank sind.

    Muß dem Plugin mal abgewöhnen, an aktiven VPS Timern rumzutogglen.


    Stefan

  • und Intel hat doch eine schlechtere Bildqualität als Nvidia!

    Also wenn man Farbwiedergabe vergleichen will, sollte man das Bild vielleicht zuvor Farbkalibrieren. 8)


    Unser (Intel J3160) Bild wird immer bewundert. War mit NVidia nicht wirklich anders. Ist allerdings erst seit ungefähr libva2 so, zuvor war das Bild z.B. vom Radio-Plugin ... dürftig.


    VDR ist auf RGB-Limited, Kodi Full. Kalibriert.


    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Hatte angenommen, fehlende ECM (hier NDS alle 7 sec, ~ 300 ms vor Gültigkeit - falls das noch aktuell ist), würden als Scrambled im Log ankommen, aber stimmt, dann kommt nix, nur Modul abschießen macht "scrambled"-Fehler.


    Backref: dies hier

    Ich stopfe das ins VDR-Log, und gucke bei Fehlern schon mal nach, was Ursache war.


    Stefan

  • [SkinNopacity] Aktuelle Probleme

    kamel5 :

    Habe jetzt Deinen letzten Commit in Master gepacht. Bisher kein Lock Error.


    Danke,

    Stefan


    PS:

    Hatte auch die Fehleranzeige (aus 4c4cdb98e662c69d..) probiert, leider sieht man die Fehler nicht, weil die zwei Zeitdauern bereits zuviel Platz brauchen, wenn man das Menü nach goldenem Schnitt teilt.

    Habe mir dies daher zur Aufnahmezeit (wie im Original) verschoben, da paßt es besser.

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Mit der auskommentierten Zeile habe ich es jetzt noch nicht geschafft, einen Deadlock zu erzeugen.

    Einmal hat das Modul in die bereits laufende Aufnahme ein paar Backref-Fehler gemacht, einmal die neue Aufnahme mit #750 TS-Fehler begonnen, bevor Bild kam. Aber kein Hänger mehr.


    Seiteneffekt bisher (Kurztest, klar) nicht zu endecken. Habe aber auch nur zwei Tuner.


    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Der der VDR um 20:00 mit Umschalttimer (ohne VDR-2.5 Patch, abgesehen TS-Errors, mit original LOCK_THREAD) an seiner neuen Lieblingsstelle pausierte, hab ich den Patch oben kurz eingespielt:

    Beim Retune hat es dann das CAM abgeschossen, aber der VDR hing nicht.

    Im Debugger sah man so nichts. Mit "c" nach automatischem Modulreset ging es dann weiter.

    Debugger ist noch attached, gucke gegen 22:00, was bei einem Umschalttimer regulär passiert...


    Edit:

    CAM mag das gar nicht, VDR läuft weiter.


    Am MTD (0x4) sollte es eigentlich nicht liegen, da ich den Deadlock auch mit FTA Programmen erzeugen kann. Aber wird probiert:


    Edit 2:

    Mit 6 Umschaltaufnahmen (FTA <-> FTA, 1x laufend über CAM) kam der Fehler nicht (LOCK_THREAD original), aber immer tut er das auch nicht (CAMTweaks = 0x827 statt 0x823).


    Edit 3:

    Bin erst einmal wieder auf

    und CAM-Tweaks 0x823 zurück.


    Bisher führte zu häufiges Umschlten auf CAM-Programmen dazu, daß irgendwann nur noch eine von zwei möglichen Entschlüsselungen verfügbar war. Jetzt machte das CAM nach 24x schnellem Umschalten während einer Aufnahme (über das CAM) einen Reset (CI+ Auth) und weiter geht's.



    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    HelmutB


    Hier nochmal der Deadlock mit -ggdb -O0, wegen Größe komplett als Textdatei anbei.


    Format dann jeweils Sourceausschnitt (soweit vorhanden), lokale Variablen, mutex:

    Code
    (gdb) up
#1  0x00007f2ce8ab9714 in __GI___pthread_mutex_lock (mutex=0x5652a3450870) at ../nptl/pthread_mutex_lock.c:80
(gdb) info locals
ignore1 = <optimized out>
ignore2 = <optimized out>
ignore3 = <optimized out>
type = <optimized out>
__PRETTY_FUNCTION__ = "__pthread_mutex_lock"
id = <optimized out>


    Und entsprechend für Thread 41:


    [..]


    HTH,

    Stefan

  • [SkinNopacity] Aktuelle Probleme

    kamel5

    Bisher ein Einzelfall, hab wegen des Deadlock-Problems aber noch nicht versucht, es zu reproduzieren.


    Aufzeichnungsmenü ist geteilt (links Aufnahme / rechts Beschreibung), denke also ja.


    Einstellungen (setup.conf):

    /var/lib/vdr/plugins/skinnopacity als Anlage


    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Das weiß ich auch nicht (hat Klaus aber 2014, VDR 2.1.x, so programmiert).


    Der VDR hing, nachdem der ListLock-Fehler im Markad Plugin (läuft im Hauptthread) beseitigt war, zuverlässig an dieser Stelle. Das tat er gelegentlich schon seit längerer Zeit (2.4.5 +/-). Bisher hatte ich das Modul in Verdacht, aber habe mal den Debuger angeklemmt.


    Der fand den VDR wartend, was erklärte, das alles, was im Haupthread mitlief (markad, Live, ...) hing, und anderes mit extra Thread halt weiter machte (vaapi - nur ohne Bild, epg2vdr, ..).


    Hab dann ermittelt, wer die Mutex besitzt - und etwas später, warum auch der Besitzer der Mutex wartete.

    Deadlock, klar. Hab dann geguckt, wo Thread 1 die Mutex holt und diese Warteposition von Thread 1 als erst einmal doppelten Mutexlock empfunden (und zunächst auskommentiert).


    Damit klappt dann natloses Umschalten zwischen Timern (A/B) und bei PID Update wieder. Allerdings scheint er mir jetzt gelegentlich beim Timerende zwei Gedenkminuten einzufügen - muß aber nicht zusammenhängen.


    (Reicht ja schon, das epg2vdr bei jeder Aufnahmeänderung (Neu, Ändern, Löschen) für ca 1,5 Minuten Channels und Recordings (und je Aufnahme kurz Schedules) readlockt, um alle 5000+ Aufnahmen durchzutackern und ein Plugin im Haupthread auf die Listen wartet.)


    Stefan

  • Deadlock bei Aufnahme auf letztverfügbarem Gerät mit Umschalten

    Hallo HelmutB ,


    ja sicher sind die Mutexe unterschiedlich:

    Thread 1 hat die Mutex A, auf die Thread 40 wartet.

    Thread 40 hat die Mutex B, auf die Thread 1 wartet.


    Wie beim Online-Neukundengeschäft:

    Der Verkäufer hat die Ware und will Vorkasse.

    Der Kunde das Geld und will erst nach Erhalt der Ware zahlen.Irgendwann schreitet dann eine Frau ein (VDR Watchdog) und will Geld und Ware, vorher tut sich nix.

    8)


    Die Optimierung (-march=native -O3, Quadcore) könnte man natürlich ausschalten, ob der Fehler dann noch auftritt, werde ich prüfen.


    Hab mal den Watchdog auf 10 Minuten gesetzt, damit ich per Zweitsystem den Debugger an laufen bekomme, sobald der VDR nicht mehr mag: immer diese Stelle bisher.


    Ohne LOCK_THREAD gab es bis jetzt (trotz der beiden VDR-2.5 Patche) keine Umschalt-Probleme mehr.


    Stefan