Log Meldungen - Analyse

  • Mär 05 08:13:40 server01 vdr[8439]: [8445] tp 211229 (18/FF) read incomplete section - len = 4098, r = 4096

    Das deuted im Zusammenhang mit deinem 386er auf einen zu kleinen Buffer für die EIT-Section hin. Du kannst den Buffer mit dem Patch im Anhang vergrößern.

    Obwohl du vermutlich leichte Signalprobleme hast, sollten alle SDT und EIT Sections die im VDR ankommen trotzdem fehlerfrei sein, da sie vorher vom dvb-core Linux-Treiber geprüft werden.

    Mär 05 08:14:09 server01 vdr[8439]: [8445] SDT: channel 62 NID/TID (1/1010) not found, got 1/1006

    Da du kein Unicable oder sonstige diseqc Kommandos verwendest, können das nur alte Daten des zuvor getunten Transponder sein - das habe ich bei mir auch schon bei PAT und SDT bemerkt.

    Im Sectionhandler::Action() sollten zwar solche alten Daten verworfen werden, da ist aber meiner Meinung nach ein Logikfehler bei einer Prüfung mit !DeviceHasLockenthalten.

    Ich habe diesen Teil für mich etwas abgeändert und es werden jetzt erst 200ms nach einem SetStatus(true) die Daten an die Filter weitergegeben.

    Du kannst ja diesen 2. Patch ja auch testen, vielleicht liegt es daran.

    Helmut

  • HelmutB Danke. Die retune Geschichte scheint gelöst, das 4098/4096 Problem ist nach wie vor da. Noch eine Idee? Ich schau selber auch mal in den Code um das zu verstehen, zumindest es zu versuchen.

    Wegen der Empfangsqualität weiß ich nicht, ob die wirklich schlecht ist.

    Der BER Wert z.B. geht nur beim Frequenzwechsel kurzzeitig hoch, sonst sehen alle Werte unverfächtig aus. Ist das normal?

    Wo wäre anzusetzen auf dem Weg von LNB - Kabel - Multischalter - Kabel - Sundtek - USB - Kabel - Server? Wobei ich nicht glaube, da viel verbessern zu können/müssen.

    Gruß Andreas

  • Du könntest mal gucken, wo die checkts Fehler sind. Falls die alle kurz nach dem Umschalten wären, wäre es dir wohl egal. Kannst ja mal die erste Minute der Aufnahme abtrennen und prüfen, ob alle darin sind.

    Praktischer wäre ein Programm, das dir gleich anzeigt, wo die Fehler sind. Vielleicht TS-Doctor?

  • HelmutB Danke. Die retune Geschichte scheint gelöst, das 4098/4096 Problem ist nach wie vor da. Noch eine Idee? Ich schau selber auch mal in den Code um das zu verstehen, zumindest es zu versuchen.

    Wegen der Empfangsqualität weiß ich nicht, ob die wirklich schlecht ist.

    Der BER Wert z.B. geht nur beim Frequenzwechsel kurzzeitig hoch, sonst sehen alle Werte unverfächtig aus. Ist das normal?

    Wo wäre anzusetzen auf dem Weg von LNB - Kabel - Multischalter - Kabel - Sundtek - USB - Kabel - Server? Wobei ich nicht glaube, da viel verbessern zu können/müssen.

    Gruß Andreas

    Sind das passiv-Switches? bzw. der Tuner versorgt das Switch und den LNB mit Strom?

    Die SkyTV 4rer könnten bei so einer Nutzung eventuell Hitzeprobleme bekommen.

    Erst ab SkyTV 5 wurden andere LNB Spannungsversorgungen verwendet die mehr Strom liefern können.


    Andererseits könnte der LNB eventuell auch die Frequenzen shiften (je nachdem wie alt er ist), ich würde das Switch erst mal weglassen und den LNB direkt ansteuern.

  • Der MS ist ein Kathrein EXR 1512, und da er ein Netzkabel hat, aktiv schätze ich :)

    Das LNB wird ein Kathrein Quattro sein und beides sollte ca. 6 Jahre alt sein.

    Muss ich bei den Treiber Einstellungen auf etwas achten? Iso/bulk, hwpidfilters, etc... ?

  • Muss ich bei den Treiber Einstellungen auf etwas achten? Iso/bulk, hwpidfilters, etc... ?

    Ich hatte transfermode auf iso, da war die cpu bei beiden mediaclient bei 80%. hwpidfilters waren auch an. Ich hab jetzt wieder auf bulk gestellt und die Filter aus. Mal sehen, ob das was ändert.

  • Die CPU Auslastung ist immer etwas relativ, 80% von einem runtergetakteten System wäre jetzt nicht viel.


    Ansosnten einfach die Signalstatistiken mitlaufen lassen (die sind pro Transponder/Frequenz und nicht für den gesamten Satelliten):

    /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal

  • Sundtek Mit transfermode=bulk habe ich eine Last von < 2% ... In der Statistik sieht für mich alles ganz gut aus, ausser dass der BER Wert beim Frequenzwechsel kurzzeitig hochgeht (siehe Log oben). Ist das normal?


    HelmutB Dein flush patch löst die SDT Meldungen aber die "tp" Meldungen habe ich nachwievor. Auch ein Hochsetzen auf 32 löst es nicht. Wenn ich hier auf

    Code
    unsigned char buf[8192]; // max. allowed size for any EIT section

    gehe, sind die Meldungen weg. Aufgrund des Kommentars weiß ich aber nicht, ob das im Sinne des Erfinders ist. Das Log taucht auch nur auf, wenn VDR len mit 4098 ermittelt wird. r ist dann nach ReadDevice 4096.


    EDIT: Habe mir mal https://www.etsi.org/deliver/e…_60/en_300468v011501p.pdf angesehen. Korrigier mich, wenn ich es falsch lese: Die PID 18 ist EIT und die table_id FF ist als "reserved" definiert. Weiter heißt es "The section_length shall not exceed 4 093 bytes so that the entire section has a maximum length of 4 096 bytes". Soll "shall" jetzt "soll" oder "muss" bedeuten? Jedenfalls ergeben die 12bit bei mir wohl 4095.

    Wenn man die Daten aber eh nicht benötigt, ist zwar die Meldung im Log, aber es sollte keine Auswirkungen haben!? Irgendwer sendet da einen "falschen" Stream? Wenn aber mehr als 4096 bytes zulässig sein können, dürfte man wohl auch buf[8196] hochsetzen?


    Ein paar lost und regained Locks habe ich auf, die kommen immer bei diversen Sky Sendern. Ich denke aber das kann ich ignorieren, Sky habe ich eh nicht.


    jrie Danke, schaue ich mir an.


    Gruß

    Andreas

    2 Mal editiert, zuletzt von rell ()

  • D hast recht - 18. == 0x12 ist die EIT-Pid. Jede Section hat einen 3 Byte Header - 1. Byte = Table-Id, 2+3Byte (nur 12 Bit) die Länge der nachfolgenden Daten. Deshalb das Maximum vom 4093+3=4096 Bytes.

    Bei dir sind aber die ersten 3. Bytes alle 0xFF (4095. == 0xFFF) und wahrscheinlich der Rest auch. Da sind normalerweise die Füllbytes nach der Section (Len) bis zum Ende eines 188 Byte TS-Pakets. Also stimmt irgendetwas mit dem Buffer nicht. Auch wenn du 8192 Byte liest, werden die Daten trotzdem nicht richtiger sein.


    Siehst du im Log irgenwo eine Fehlermeldung mit 'DMX_SET_BUFFER_LEN", bzw. ist das nur bei diesem Transponder ("NHK World")?

    LG Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Die Fehlermeldung finde ich nirgends, der ioctl sollte also zumindest funktionieren. Es handelt sich um folgende Transponder/Frequenzen


    Code
    Mär 08 08:27:04 server01 vdr[17399]: [17405] tp 112343 (18/FF) read incomplete section - len = 4098, r = 4096
    Mär 08 08:29:50 server01 vdr[17399]: [17403] tp 112603 (18/FF) read incomplete section - len = 4098, r = 4096
    Mär 08 08:32:50 server01 vdr[17399]: [17403] tp 211229 (18/FF) read incomplete section - len = 4098, r = 4096
    Mär 08 08:34:38 server01 vdr[17399]: [17405] tp 211626 (18/FF) read incomplete section - len = 4098, r = 4096
    Mär 08 08:38:44 server01 vdr[17399]: [17403] tp 212551 (18/FF) read incomplete section - len = 4098, r = 4096
    Mär 08 08:53:56 server01 vdr[17399]: [17405] tp 211778 (18/FF) read incomplete section - len = 4098, r = 4096

    Andere hat er seit heute vormittag nicht angemeckert.

  • Sundtek :

    Ich habe mal kurz beobachtet und bei folgenden Senderfrequenzen steigt der BER Wert beim Umschalten (nicht abschließend!):

    Code
    10729
    10906
    11258
    11260
    11317
    11376
    12343
    12574

    Da ist viel spanisches Zeug dabei. Keine Ahnung ob man das was ableiten kann - falls überhaupt nötig.

  • Code
    ir_disabled=1
    loglevel=min
    enablenetwork=off
    use_hwpidfilter=off
    bulk_notification=on

Jetzt mitmachen!

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