[epgsearch] conflict check - Fehlalarm bei verschlüsselten Sendern

    Es ist nur 1 Timer auf ORF programmiert. Dem BM2LTS NUC10i3 sind 3 DVB-S2 zugeteilt.

    Zuvor habe ich den epgsearch Ordner und timer.conf gelöscht. Mir ist das bisher nie aufgefallen, weil wir den check aufgrund früherer Abstürze abgeschalten hatten.

    Ins Blaue hinein geraten vermute ich, dass der conflictcheck nicht weis, dass über das mcli Plugin und die im Netceiver steckende ORF Karte die Verschlüsselung möglich ist ?

    channels.conf

    Code
    ORF1 HD;ORF:11302:hC23M5O35S1:S19.2E:22000:1920=27:0;1921=deu@106,1922=mis@106:1925:648,650,D95,D98,6E2,500,98D,9C4,98C:4911:1:1007:0
ORF2O HD;ORF:11273:hC23M5O35S1:S19.2E:22000:3000=27:0;3001=deu@106,3002=mis@106:3005:D98,650,D95,648,6E2,98C,9C4,98D,500:13304:1:1005:0

    Hier das epgsearch Log: mit -v 3

    So. 04.04.2021 18:02:01: timer 'Oberösterreich heute Service' (So. 04.04. 18:57, channel ORF2O HD) failed

    - Was ist der Grund für den fail ?


    - woher nimmt es die Info ob encrypted channels entschlüsselt werden können ?

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Edited 3 times, last by gggggg ().

    Passiert das beim vdr-Start? Ist die neueste epgsearch-Version installiert, wo man die Checks verzögert loslaufen lassen kann?

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    TomJoad

    Danke dass du dich drum annimmst... die Version sieht man oben im epgsearchlog Zeile 2


    Das passiert nicht nur beim Hochlauf, sondern auch beim manuellen Start (und nat. wenn konfiguriert nach jeder Timer Prog.) des checks.

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    epgsearch benutzt die gleiche Routine wie der vdr in device.c, um festzustellen, ob ein verschlüsselter Sender entschlüsselt werden kann. Mittlerweile gibt es minimale Abweichungen zu dort, deren Bedeutung ich nicht verifizieren kann, weil ich nur unverschlüsselte Sender sehen kann.

    Kann es möglich sein, das zu dem Zeitpunkt, wo der Konfliktcheck losläuft, der Kanal nicht verfügbar ist?

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Verfügbar sind die Kanäle sicherlich ... aber die Entschlüsselung des netceiver und mcli brauchen schon mal 5s.


    Das check Problem besteht aber reproduzierbar bei allen verschlüsselten (orf, atv, servusTv,puls4) auch wenn man gerade auf dem Sender empfängt ....

    HelmutB, cinfo kann der vdr-2.4.6.mcli5.patch da mit rein spielen ?

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Bei SKY gab es bisher auch keine Meldungen oder HD Plus, die sind ja auch verschlüsselt.

    Gruß utiltiy



    VDR Projects

    Ich bin ganz unbedarft beim CAM-Handling, aber epgsearch bildet den Mechanismus mit HasInternalCam() noch nicht nach, kann das eine Rolle spielen?

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Quote from gggggg

    Das können nur die Profis sagen ... ich erwähne noch pbrb

    da kann ich leider nicht helfen, habe hier keine CAM im Einsatz und kann mich deshalb auch nur sehr bedingt um den CAM-bezogenen Code im "mcli" kümmern...sorry.

    Ich habe mal des Handling von devices mit "HasInternalCam" vom vdr in epgsearch nachgezogen. Bevor ich das auf die Allgemeinheit loslasse, sollte der Patch aber ausgiebig getestet werden - und ich selber habe keine Cams und keine Entschlüsselungsmöglichkeiten.

    Ich kann auch nichts bauen für BM2LTS

    HI TomJoad ,

    danke schaut gut aus ... ich habe das mit den ORFs, mit mcli (und Netceiver + Alphacypt+ORF-Karte) getestet.

    Was mir aufgefallen ist:

    - Wenn man bereits existente Timer (die deaktiviert sind) aktiviert, erfolgt keine Konfliktprüfung.

    - Prüfe nur die nächsten x Tage kann ich max. auf 14 stellen ?!

    - nach manuellem "Suchtimer aktualisieren", wird die Meldung "Suchtimer-Update durchgeführt" nicht autom. v. Schirm gelöscht

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Edited once, last by gggggg ().

    "die nächsten X Tage" ... da macht längere Zeit keinen Sinn, da das EPG nicht soweit in die Zukunft reicht. Im Gegenteil, eine zu lange Vorlaufzeit ergibt unvollständige Datensätze. Wenn z.B. einer der Provider, der üblicherweise den besten Datensatz mit Subtitel usw. liefert, sind die Daten für einen Vergleich ob Serie oder Wiederholung noch ungeeignet. Kann ja sein, daß ohne Subtitel eine Wiederholung angenommen wird und der Timer vorerst nicht erstellt wird.

    Hallo,

    vor einiger Zeit habe ich die neue Version 2.4.1 installiert. Danach kamen mehrmals unerklärliche Konfliktmeldungen, ich hatte aber keine Zeit das näher zu untersuchen.


    Inzwischen konnte ich den Fehler reproduzieren. Die Fehlalarme betreffen unverschlüsselte Sender.

    Im System sind drei DVB-Karten vorhanden. Es werden vier Timer auf drei Transpondern angelegt. Mit der Version 2.4.0 werden keine Konflikte angezeigt (VDR-Version ist 2.4.7.). Mit der neueen Version wird der erste Timer auf Karte 2 gestartet. DIe zweite Aufnahme auf dem gleichen Transponder wird vom epgsearch der Karte 3 zugeordnet, vom VDR aber wie erwartet ebenfalls auf Karte 2 gestartet. Die letzten beiden Timer brauchen dann jeweils eine eigene Karte.

    channels.conf

    Das Erste:338000:C0M256:C:6900:101=2:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28106:1:1101:0

    ZDF:450000:C0M256:C:6900:110=2:120=deu@3,121=mis@3,122=mul@3;125=deu@106:130;131=deu:0:28006:1:1079:0

    rbb Berlin;ARD:458000:C0M256:C:6900:601=2:602=deu@3,603=mis@3:604:0:28206:1:1073:0

    3sat:450000:C0M256:C:6900:210=2:220=deu@3,221=mis@3,222=mul@3;225=deu@106:230;231=deu:0:28007:1:1079:0


    timers.conf

    1:C-1-1079-28007:2021-12-06:1755:1800:50:99:3sat:<epgd><timerid>2415</timerid></epgd>

    1:C-1-1079-28006:2021-12-06:1756:1800:50:99:ZDF:<epgd><timerid>2416</timerid></epgd>

    1:C-1-1073-28206:2021-12-06:1757:1800:50:99:rbb Berlin:<epgd><timerid>2417</timerid></epgd>

    1:C-1-1101-28106:2021-12-06:1758:1800:50:99:Das Erste:<epgd><timerid>2418</timerid></epgd>


    epgsearch.log

    Gruß Zimuland

    Wieso ist das bisher niemandem aufgefallen? Ich kann es reproduzieren, sollte auch schon vor 2.4.1 ein Problem gewesen sein.

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Mit der Version 2.4.0. war es noch ok. Das hatte ich schon getestet.


    Ich habe mir jetzt noch den Stand aus dem GIT geholt. Dort muss man nur den Commit "improved conflictcheck for encrypted channels" zurücknehmen und dann geht es wieder.


    Gruß Zimuland

    Ich habe den Fehler gefunden, wird im git korrigiert

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Like 1

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login