Eine hatte 39
Das sieht nach Empfangsproblemen aus. Nicht oft, aber auch nicht vernachlässigbar.
Eine hatte 39
Das sieht nach Empfangsproblemen aus. Nicht oft, aber auch nicht vernachlässigbar.
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
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
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
Die Fehlermeldung finde ich nirgends, der ioctl sollte also zumindest funktionieren. Es handelt sich um folgende Transponder/Frequenzen
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.
Wie sieht deine sundtek.conf aus?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!