Meinst Du die Hauppauge WinTV-Starburst?
Hauppauge WinTV-Starburst2 - LinuxTVWiki
Da scheint es eine v1 und v2 zu geben. Gibt es da einen Unterschied?
Weiß ich nicht genau, vermutlich ist aber der Tuner oder irgend was anderes in der Peripherie anders.
Unterstützt sind anscheinend aber beide, zumindest tauchen beide im Sourcecode auf:
Die DVB-Sky S952 Version 1 und 2 wird übrigens vom gleichen Treiber unterstützt.
Eigentlich müßte er ja proportional skaliert werden, um die Stecker Impedanz von 75Ohm zu erhalten.
Den Gedanken hatte ich auch, nur passte das optisch irgendwie nicht mit den Bilder zusammen, daher die Frage.
Hmm, ich komme damit beim Rechnen auf < 60 Ohm, wenn ich davon ausgehe, dass nur noch Luft zwischen Innenleiter und Außenleiter ist. Mit jedem anderen Material wird es noch näher Richtung 50Ohm.
Ich komme da sogar auf noch weniger.
Innen am Stift kommen ja noch ~0,5mm im Durchmesser für die Buchse dazu und außen kann man aus dem gleichen Grund auch etwa so viel abziehen.
Sofern ich nicht völlig daneben liege, würde sich daraus etwas im Bereich 35-45 Ohm ergeben.
Danach ist der Außendurchmesser des inneren Stiftes 2,4 mm dick.
Das ist der bei den IEC-Steckern auch, nur ist da der Innendurchmesser des Außenrings ~8,5mm.
Den IEC-Stecker müsste man also in die Samsung-Buchse stecken können, wenn Außen nichts im Weg ist. Der Innenleiter sollte auch direkt passen, nur an der Abschirmung wird ringsum eine Lücke von ~1mm sein.
Wen es schnell gehen muss, würde ich den IEC-Stecker einfach etwas zusammen quetschen, bis er außen Kontakt hat.
Ganz schön geht das in einem Bohrfutter von einer Bohrmaschine, damit entsteht ein sauberes Dreieck, was guten Kontakt haben sollte.
Man könnte aber auch mal versuchen den Spalt mit einem aufgewickelten Weißblech-Streifen aufzufüllen.
Das Zeug ist gut zu verarbeiten, lötbar und zudem billig (Konservendose). Nur die Beschichtung muss man vorher irgendwie ablösen.
Wie sieht es aber mit dem Pin in der Mitte aus bzw. welchen Durchmesser hat der?
Das würde mich auch mal interessieren.
Anscheinend ist der Markt aber mittlerweile so klein, dass es hier kein entsprechendes Angebot mehr gibt.
Riesig war der Markt ja nie, verglichen mit den Receivern.
Dann gibt es halt auch keinen wirklichen Grund eine neue DVB-Karte zu kaufen, sofern die Alte nicht kaputt geht. Die allermeisten DVB-S2 Karten haben schon PCIe und werden noch mindestens 10 Jahre uneingeschränkt nutzbar sein.
Es gibt AFAIK noch eine DVB-S2 Karte mit Kernelsupport neu von Hauppauge.
Allerdings nur ein Tuner, was bei deinem Anwendungsfall aber reichen könnte.
Alternativ mal nach gebrauchten DVBSky 952 in der Bucht fischen, die laufen recht problemlos und sind mit etwas Geduld günstig zu bekommen.
Wobei ich nicht sicher bin, ob es mit einer anderen Karte geht, da scheint wirklich was größeres im Argen zu liegen.
Die Fehlermeldung scheint seit ungefähr Kernel 6.7 auch sehr verbreitet zu sein, wie meine heutige Suche zeigte. Unter Umständen liegt das Problem ganz wo anders und ein Kernelupdate löst das Problem in einem halben Jahr einfach so.
Es wäre schön, wenn Du bei Gelegenheit noch das eine hier probieren könntest:
pci=nocrs
Die Empfehlung stammt aus deinem Syslog, ich hatte es nur wegen der komischen Zeilenumbrüche übersehen.
[ 0.267745] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
O.k., das erklärt einiges, da muss wohl noch irgendwo anders ein Fehler sein.
EDIT:
Nicht zwingend. Wenn die falsch eingetragene 1 verhindert, dass der Transponder getunt wird, kann der Eintrag nicht korrigiert werden.
Evtl. klappt es, wenn man beim Ersten die 1 einträgt und dann auf ein drittes Programm schaltet?
An der geänderten Stelle werden lediglich die T2-Parameter vom bisherigen Kanaleintrag "gerettet" (erste Zeile in meinem Patch) und dann erneut gesetzt. Das verhindert, dass die Werte mit den Default-Werten überschrieben werden.
Die T2-Parameter werden direkt darunter im Block mit T2DeliverySystemDescriptorTag ermittelt und gesetzt. Das ist auch die einzige Stelle im Code, wo der T2DeliverySystemDescriptorTag auftaucht.
Warum jetzt das Update nicht funktioniert, aber die Kanäle korrekt neu erkannt werden, ist mir momentan aber auch unklar.
Also, der VDR hat die Informationen wohl aus dem T2DeliverySystemDescriptor.
EN 300 468 - V1.11.1 - Digital Video Broadcasting (DVB) - ETSI
Der ist, wenn ich das beim Überfliegen nicht völlig falsch verstanden habe, Teil der NIT.
D.h. er wird genau wie bei DVB-S im TS geliefert.
Also von da her alles wie bisher, bis auf, dass man die stream-id braucht, um überhaupt an den TS zu kommen.
Warum es bei älteren VDR-Versionen funktioniert, liegt vermutlich an diesem Patch:
Wobei, ich glaube, ich habe eben zumindest mal einen Fehler gesehen:
Fehlt in der einen Zeile nicht ein "c"???
--- a/nit.c
+++ b/nit.c
@@ -257,6 +257,6 @@ void cNitFilter::Process(u_short Pid, u_char Tid, const u_char *Data, int Length
cDvbTransponderParameters dtpc(Channel->Parameters());
dtp.SetSystem(dtpc.System());
dtp.SetStreamId(dtpc.StreamId());
- dtp.SetT2SystemId(dtp.T2SystemId());
+ dtp.SetT2SystemId(dtpc.T2SystemId());
dtp.SetSisoMiso(dtpc.SisoMiso());
dtp.SetBandwidth(dtpc.Bandwidth());
dtp.SetGuard(dtpc.Guard());Kurioser Weise aber bei der T2SystemId nicht StreamId.
Ob es daran liegt, müsstet ihr mal probieren.
Danke für die Ergänzungen, ich hatte mich bislang erst 2 Stunden mit dem Thema beschäftigt und das mit dem Fokus auf die Bestimmung der Frontend-Parameter.
Da sind die physikalischen Details zur Übertragung erstmal nicht wirklich relevant, daher hatte ich das etwas vereinfacht dargestellt.
Von Seiten des Empfängers muss ich eigentlich nur die richtige stream_id setzen (neben den anderen Daten) und bekommen dann einen normalen Transportstrom geliefert. Aktuell sehe ich da nicht wirklich einen Unterschied zB. zur Polarisation bei SAT.
Bis auf, dass hier der Wert nicht im Transportstrom geliefert wird.
Na eher zeitversetzt mit jeweils eigenen physikalischen Parametern.
So kann man es auch ausdrücken.
Wer es genau wissen will, im folgenden Link ist das unter "frame structure" schön grafisch dargestellt:
(Zu dem Artikel war ich gestern nicht mehr gekommen.)
Weiter unten sieht man, dass die TS-Pakete in "BaseBand frames" verpackt sind. Irgendwo in deren Header müsste dann wohl die stream_id sitzen.
Meine Frage, ob man bei setzen von "NO_STREAM_ID_FILTER" die ganzen Rohdaten bekommt, konnte ich aber noch immer nicht klären.
Im VDR bin ich auch nur bedingt weiter gekommen.
Die stream_id wird hier im Frontend gesetzt.
D.h. gespeichert ist die in cDvbTransponderParameters und wird mit SetStreamId() gesetzt.
Wenn man jetzt danach sucht bekommt man mehrere Treffer in der nit.c 
.
Dieses Multistream-Zeug ist saukompliziert.
Prinzipiell ist es erstmal gar nicht so kompliziert.
Eigentlich werden nur mehrere TS verschachtelt auf einem Transponder ausgestrahlt.
Das Frontend extrahiert daraus den gewählten TS und das dann geht es weiter wie gehabt .
(Die weiteren Details zur Übertagung sind eigentlich nicht relevant, da das Frontend die ganze Arbeit erledigt. Auch die Probleme, die theoretisch auftreten könnten, weil der TS jetzt in größeren Blöcken und nicht mehr kontinuierlich kommt, kann erstmal ignorieren, denke ich.)
Gemacht wird das Ganze um Programme mehrerer Anbieter auf einem Transponder unter zu bringen, ohne die ganzen Programme in einen neuen TS muxen zu müssen. Und mit dieser Sparlösung fangen jetzt für uns die Probleme an.
Da der/die TS nicht neu erstellt werden, kann die stream_id nicht in der NIT übertragen werden.
(Die stream_id kann theoretisch, je nach Übertrgungsweg/Sender unterschiedlich sein und außerdem ist sie beim muxes des TS nicht zwingend bekannt.)
Ob man man die Rohdaten aller Streams überhaupt gleichzeitig ran kommt, wenn man NO_STREAM_ID_FILTER setzt, bin ich nicht sicher. So wie ich es verstanden habe, können sich die Modulationsparameter der einzelnen (Multi-)Streams eines Transponders unterscheiden.
Wenn es geht müsste man alle gültigen stream_ids eines Transponders eigentlich irgendwie extrahieren können, wenn nicht, ist raten angesagt.
PLS hat mit Multistream(PLP) nichts zu tun, das ist wohl eher eine Modulations-Geschichte bei DVB_S2. Das ist nur überall in den Patches, da es dort praktisch alle Multistream-Transponder verwenden. Den PLS-Code wohl vorher wissen, da man ohne gar nicht erst an den Datenstrom kommt. (Die Codes durch probieren ginge natürlich, aber das dauert.)
Ein Teil der Patches sieht mir aber so aus, als ob es auch für DVB-T2 sinnvoll wäre. Die streamId in der channels.c zB., da müsste man mal schauen, was da bislang übernommen wurde.
Die Problemantik an der Multistream-Geschichte ist wohl primär das scannen. Wenn man den Kanaleintrag hat, sollte das Frontend den Rest erledigen.
Wo die stream_id 1 her kommt die der VDR beharrlich setzt, konnte ich heute aber immer noch nicht raus finden. Da muss ich die Tage mal weiter suchen.
Zum Abschluss noch etwas Literatur zum Thema:
In den letzten Tagen habe ich allerdings immer wieder zum Baum geschaut und ich denke, er wird im Herbst weichen müssen. Die momentane Position der Schüssel ist einfach zu praktisch. Das muss allerdings eine Firma machen, sonst ist das Nachbarhaus in Gefahr.
Macht doch nichts, dann kommt das gleich mit weg, wenn man schon dabei ist 
.
Spass beiseite, Laubbäume lassen sich recht gut beschneiden und wenn schon der Profi da ist. Ein halbieren der Kronen Größe ist normalerweise problemlos machbar und dann hat man wieder 10 Jahre Ruhe.
Hier liegt aber der Schnee auch oft auf dem Ausleger und auf/vor dem LNB
Das ist mir auch schon aufgefallen. So hoch, dass es den LNB blockiert hat ist es aber bislang nicht geworden. Darauf sollte man bei der Wahl der Schüssel mehr achten, die Ausleger von Gilbertini sind in dem Punkt wirklich nicht Ideal. Da gibt es bessere Konstruktionen, zB. mit zwei schmalen Auslegern.
Für's LNB gibt es Wettersschutzhauben, die helfen recht zuverlässig.
Wenn man zu geizig ist, kann man sowas auch selber basteln.
Hier haben unkundige Architekten bei Neubauten auch Sat-Schüsseln auf Rohren auf dem Dach geplant. Wenn über Nacht ein halber Meter Schnee fällt, siehst du von den Rohren schnell nicht mehr viel
Ich meinte ein Rohr senkrecht im Garten ein betonieren und daran die Schüssel befestigen.
Natürlich mit ausreichend Abstand zum Boden, so dass sie nicht zu wächst/schneit aber man trotzdem noch gut dran kommt. Am besten an einem unauffälligen Platz zB. mit Busch im Rücken.
Das Setup haben hier einige so, es scheint also recht brauchbar zu sein.
Denke auch nicht, dass es Heizungen für die Flachantennen gibt.
Für "normale" Schüsseln habe ich sowas schon mal irgendwo im Angebot gesehen.
Der dritte wäre das angeblich schnell versprödende Plastik.
Guter Punkt.
Das hatte ich tatsächlich mal bei einem LNB (war dann voll gelaufen), das war, zum Glück recht schnell und preiswert zu tauschen.
Bei so einer Flachantenne wäre das aber echt ärgerlich, allein wegen des Ausrichtens.
Bzgl. des Antennenstandortes gäbe es auch die Möglichkeit einfach ein Rohr ein zu betonieren.
Das haben hier im Tal einige so gemacht weil am Haus der Berg im Weg ist.
Bei SAT bin ich relativ sicher, dass die Kanal-Informationen ausschließlich aus dem TS selber stammen. AFAIK ist das ganze auch Transponder übergreifend.
Sofern das bei DVB-T2 nicht anders ist, müsste der Fehler irgendwo im NIT-Scanner vom VDR liegen. Oder die ARD oder ein anderer Transponder senden defekte Kanaldaten.
Edit:
Könnte das die Ursache sein?
Liegt das evtl. daran, daß ich den heutigen Scan nicht als root gemacht habe?
Eher nein.
Ich habe also höchstens eine Mauer mit 1,2 m Höhe und einer Tiefe bis zur Regenrinne von 50 cm zur Verfügung.
Deswegen die Idee mit der Flachantenne.
Das könnte evtl. schon eng werden.
Bevor man was beschafft, sollte man noch mal genau messen, ob da nicht doch die Regenrinne im Weg ist.
Der Elevationswinkel liegt bei etwa 30-35°.
Und dort bist du wirklich froh, wenn du bei Schneefall mit dem Besen an die Schüssel kommst. Das macht man zum Teil mehrfach am Abend, besonders wenn der Schnee mal wieder horizontal fällt.
Die Flachantennen liegen aber "flacher" als die üblichen Offset-Spiegel.
Theoretisch sollten die deutlich anfälliger bei Schneefall sein, Erfahrungen habe ich da aber keine.
Ich selber habe eine 1m Gilbertini, da passiert es regelmäßig, dass etwa das untere Drittel zu schneit. Am Empfang macht das aber nichts, da genug Reserven da sind.
Der Spiegel meiner Gilbertini ist dazu auch relativ "schräg". Offset-Spiegel anderer Hersteller sind da teilweise deutlich "steiler". Das sollte das Zuschneien noch mal erschweren.
Dann gibt es noch diverse Tools gegen das Zuschneien, Planen, Heizfolien, ...
Evtl. ist dabei ja was taugliches zu finden?
Unter 16.04 habe ich noch die alte VDR-Version von 2018, vermutlich eine 2.4er Version.
Sollte sich eigentlich raus finden lassen: VDR aus fnu-repository
Viel interessanter wäre, was da zur Kanalaktualisierung eingestellt ist.
Das löst das eigentliche Problem aber ja nicht. Warum finden t2scan und vdr anhand der Transponderinfo den Parameter P1, wenn damit kein Empfang möglich ist? Wenn die ARD ihre Transponderdaten falsch deklariert, müssten ja auch andere Empfänger Probleme haben. Ich vermute eher, dass hier entweder vdr oder der Treiber die Hardware nicht richtig ansprechen und die plp autodetection deshalb nicht richtig funktioniert.
Irgendwie ist es schon merkwürdig, was passiert, zumal es anscheinend ja auch t2scan betrifft.
Das mit t2scan sollte man bitte noch mal verifizieren.
Man könnte es mal mit einem anderen Scan-Tool versuchen, aber da kenne ich mich nicht aus. (Als SAT-User habe ich noch nie scannen müssen.)
Ich würde aktuell am ehesten auf einen Bug im VDR tippen.
Da die channels.conf-Zeile jetzt anders aufgebaut ist, muss in dem Bereich was geändert worden sein.
Dem Problem sollte man jedenfalls mal nach gehen.
Daran wollte ich so lange nichts ändern, bis der neue läuft.
Dazu würde ich auch dringend raten 
!
Das war, was ich in Erinnerung hatte.
Aber keine Ahnung ob es hier was bringt, bzw. überhaupt anwendbar ist.
Mir war es nur zufällig aufgefallen, als ich mal was zu den Puffern nachgeschlagen hatte.
Ich habe es noch nicht verwendet, aber man kann, wenn ich das noch recht erinnere, den Timeout beeinflussen oder sogar abschalten.
Das muss, irgendwo bei den socket-Optionen gewesen sein, wenn ich nicht ganz falsch liege.
Der Code ist an der möglicherweise entscheidenden Stelle genauso wie aktuell
Ausgerechnet an der Stelle scheint schon ewig nichts geändert worden zu sein.
Anscheinend ist irgendwann DTV_DVBT2_PLP_ID_LEGACY durch DTV_STREAM_ID ersetzt worden.
Da könnte unbeabsichtigt auch eine Änderung im Verhalten rein gekommen sein.
Wenn man es aber irgendwie schafft, dass 0 oder -1 im Log auftaucht, sollte das egal sein.
Das blöde ist, dass ich nicht mal sicher bin, ob nun P1 oder P0 richtig wäre.
Bei falschem Wert sollte es jedenfalls keinen Empfang geben, wenn alles korrekt funktioniert.
Interessant ist, dass der VDR bei ARD-Transponder P0 in P1 umschreibt, beim ZDF aber nicht.
Das ist etwas merkwürdig, weil die neuen Daten zum ARD-Transponder ja irgendwo her gekommen müssen.
Unter Umständen tunt der VDR den ARD-Transponder genau ein mal ganz kurz, zerstört die channels.conf und das was's dann. Das wäre echt ein blöder Fehler.
schalte mal in Einstellungen - DVB - Kanäle aktualisieren auf 'nein'.
Das sollte man wirklich mal machen und dann mit der alten channels.conf versuchen.
fhg Nur zur Sicherheit und weil das Problem noch immer so merkwürdig ist:
Bitte schau bei Ubuntu 22.04 noch mal nach, ob da wirklich keine Reste vom TBS-Treiber mehr vorhanden sind.
ls /lib/modules/$(uname -r)/updates/extra/media/dvb-frontends sollte nichts anzeigen, oder eine Fehlermeldung, dann ist alles o.k..
Wenn da eine lange Liste mit .ko Dateien kommt, ist der TBS-Treiber noch drauf.
Dann bitte den Kernel erneut installieren sudo apt install --reinstall linux-image-....
(evtl. ist vorher ein purge notwendig, falls die Module nach dem --reinstall noch immer nicht weg sind.)
Vielleicht kann SHF nochmal erläutern, wie sein Vorschlag
zu verstehen ist.
Einfach P0 oder P1 (was halt drin steht) in der channels.conf in P-1 ändern.
Dann muss man im Log schauen, ob es auch im Treiber ankommt.
(Erklärung:
Das könnte gehen, weil NO_STREAM_ID_FILTER als (~0U) definiert ist.
~0U und entspricht Binär 11111111111111111111111111111111 (bitweise Negation von 0).
Unsigned entspricht das 4294967295 Dezimal, bei einem int mit Vorzeichen, und das verwendet der VDR hier, aber -1.)
Hiernach[...] ist in der in #23 geposteten channels.conf für Das Erste bereits 0:
Da hatte ich gestern wohl Tomaten auf den Augen.
Es gab da 2015 ein möglicherweise ähnliches Problem mit dem Vorschlag des Treiberentwicklers, testweise mit einem Hack die stream_id fix auf 0 zu setzen.
Ich denke eher, dass der Filter ganz abgeschaltet wird.
Das Register cmd.args[1] enthält die stream_id.
Das Nächste cmd.args[2] scheint den Filter zu aktivieren, da es nur auf "0" gesetzt wird, wenn die stream_id "NO_STREAM_ID_FILTER" ist.
Der Hack setzt cmd.args[2] fest auf "0", damit müsste der Filter abgeschaltet sein.
Die Idee das notfalls genau so mal zu versuchen, war mir auch schon gekommen. Ich wollte nur erstmal versuchen, ob man es auch einfacher hin bekommt.
Ich bin dann noch auf einen Post von HelmutB (R.I.P.) gestoßen, der eine Modifikation des vdr-Codes in dvbdevice.c vorschlägt. Das passt auch für vdr-2.6.7 noch.
Man könnte es auch einfach mal so probieren P-1 zu setzen.
Anhand der Definition könnte das jetzt schon gehen, falls das nirgendwo abgefangen wird.
(#define NO_STREAM_ID_FILTER (~0U) entspricht int -1.)
Im Logfile wird man dann ja sehen, was ankommt.
Das Erste HD;ARD:538000:B8D0G19128M2P1Q1S1T16X0Y0:T:27500:4369=36:4370=deu@17,4371=mis@17,4373=qks@17:4372:0:769:8468:2562:0Die Kanäle sind sowieso etwas merkwürdig, wenn man es mit diesen (offiziellen ?) Angaben vergleicht:
Parameter ARD_NDR und NDR_NDS
16k extended, 19/128 Guard-Intervall, PP2
64-QAM, Coderate 1/2 (Datenrate 18,2 Mbit/s)
Ich hätte da eher sowas wie "B8D0G19128M64P1Q1S1T16X0Y0" erwartet.
"M2" steht für QPSK, das kann eigentlich nicht passen.
Die Werte werden vom Treiber anscheinend aber eh nicht ausgewertet.
Verwendet werden, soweit ich das sehen konnte, nur:
delivery_system, bandwidth_hz, frequency beim Tuner und
delivery_system, bandwidth_hz, stream_id (symbol_rate nur bei DVB-C) beim Demod .
Welchen Kernel verwendest Du unter Ubuntu 16.04.? Stammen die dvb-Treiber darin aus einem TBS-Paket? Hast Du dazu noch die Sourcen? Ich würde mir da gerne mal eine Stelle anschauen, ob die da schon so wie im aktuellen si2168-Treiber war.
Das müsste auch damals schon ein Treiberpaket von TBS gewesen sein.
Ein paar Infos dazu könnten aber nicht schaden, falls man da noch ran kommt.
Wenn es auch schon aus dem Git kam, reicht die letzte commit-id.
Also das, was bei git log direkt rechts nach dem obersten commit kommt.
Man könnte es mal mit make -d versuchen.
Vielleicht bekommt man dann ja eine Fehlermeldung, mit der man was anfangen kann.
Bis der Lock auf dem ARD-Transponder kommt, dauert es wirklich etwas:
09:28:47 : [ 4224.880807] si2168 4-0064: delivery_system=16 modulation=0 frequency=538000000 bandwidth_hz=8000000 symbol_rate=0 inversion=0 stream_id=0
09:28:47 : [ 4224.880809] si2157 9-0060: delivery_system=16 frequency=538000000 bandwidth_hz=8000000
09:28:47 : [ 4224.914882] si2168 4-0064: si2168_ts_bus_ctrl acquire: 1
09:28:47 : [ 4224.993975] si2168 4-0064: status=00
09:28:47 : [ 4225.107202] si2168 4-0064: status=00
09:28:47 : [ 4225.220374] si2168 4-0064: status=03
09:28:48 : [ 4225.333538] si2168 4-0064: status=03
09:28:48 : [ 4225.446713] si2168 4-0064: status=1f
09:28:48 : [ 4225.564216] si2168 4-0064: status=1f
09:28:48 : [ 4225.843202] si2168 4-0064: status=1f4225,446713 − 4224,880807 = 0,565906s
Da zwischen den Tunig-Versuchen aber etwa eine Sekunde vergeht, sollte das trotzdem passen.
Der einzige wirklich auffällige Unterschied ist, dass bei altern Treiber stream_id=0 ist und bei Neuen stream_id=1.
Das macht jedenfalls eine Änderung in der Konfiguration den ICs aus.
Mit falsch gesetzter stream_id wird man jedenfalls wohl keinen Empfang auf dem Kanal haben. Ob das auch verhindern kann, dass ein Lock kommt, bin ich nicht sicher. Möglich wäre es aber zumindest.
Ich würde mal versuchen die stream_id auf 0 zu setzen. Das müsste eigentlich im Channels-Menü vom VDR gehen. (Ich kann das leider nicht probieren, ich habe hier nur SAT.)
Und dann mal schauen, ob das auch im Logfile ankommt.
Irgendwie ist das Ganze mit der stream_id sowieso etwas merkwürdig, zumal sie in dem channels.conf gar nicht gesetzt wurde.
Aber vielleicht weiß da einer der DVB-T-Experten mehr?
Also, die Masse an Meldungen scheint zumindest teilweise daher zu rühren, dass dauernd versucht wird den ARD-Transponder neu zu tunen.
Man sieht eigentlich recht schön, was da passiert. Die einzelnen Tuner/Frontends kann man anhand der Ziffer (Busadresse) nach dem si21.. unterscheiden, wobei immer ein Tuner und ein Frontend fest zusammen gehören. Tuner 12 gehört zu Frontend 10, zw.B 11 zu 8.
Das Tunen läuft immer wie folgt ab und ist anscheinend auch erfolgreich:
si2168 8-0064: delivery_system=16 modulation=0 frequency=538000000 bandwidth_hz=8000000 symbol_rate=0 inversion=0 stream_id=1
si2157 11-0060: delivery_system=16 frequency=538000000 bandwidth_hz=8000000
[...]
si2157 11-0060: tuning took 24 ms, status=0x85
si2157 11-0060: tuning+lock took 24 ms, status=0x85In der ersten Zeile bekommt das Frontend den Tuning-Befehl.
In der Zweiten wird das notwendige an den eigentlichen Tuner weitergeleitet.
Der tunt dann die Frequenz und bekommt auch sofort einen lock.
Das sieht für mich auch soweit alles korrekt aus. delivery_system=16 steht für DVB-T2 und frequency und bandwidth_hz passen.
Auch geht das tunen schnell und die Zeiten sind recht konstant 20-28ms. Das spricht dafür, dass der Tuner mit dem Signal keine Probleme hat.
Jetzt zum Frontend(Demodulator):
Bei der 0 bei modulation und symbol_rate muss ich noch mal nach schauen, AFAIK steht 0 aber meist für auto.
Bei der inversion wird sowohl 0 als auch 1 probiert, das ist auch normal, falls das tunen mit 0 scheitert.
Und das tut es anscheinend auf Ebene des Demodulators:
si2168 8-0064: si2168_ts_bus_ctrl acquire: 1
[...]
si2168 8-0064: status=00 args=80 00 08 dc 00 00 42 ff 43 1b 00 00 01 01Die erste Meldung kommt nach dem der Demod nach dem Tunen aktiviert wurde.
Die mit status, wenn der Zustand des Demod. abgefragt wird. (0b das jetzt durch den VDR oder DVB-core passiert, bin ich momentan nicht sicher, das ist aber erstmal egal.)
Die Werte, die status haben kann, sind hier definiert: frontend.h
Wobei der si2168 nur 3 Werte kann:
00 -> kein Signal
03 -> Signal aber kein Lock
1f -> Signal und Lock
Und die Werte werden vom Frontend/Demod si2168 geholt, nicht vom Tuner.
Der Fehler müsste also doch im si2168-Treiber liegen.
Nach dem Tunen fängt es immer mit 00 an und springt dann gleich auf 03.
Es entspricht also genau den, was der VDR/femon anzeigt.
Da der Lock ausbleibt, wird dann (von irgendwo her) ein erneutes tunen des Kanals angestoßen und der Vorgang wiederholt sich.
Das geht auch recht schnell, bis das passiert, nicht mal eine Sekunde wird gewartet. Das Problem könnte also der Timeout irgendwo anders (vermutlich dvb-core) sein.
Weiter oben im Log sind noch Meldungen mit status 1f. Die kommen immer von einem Frontend, dass muss da erfolgreich auf einem anderen Kanal getunt haben.
Da wäre es hilfreich mal den Log vom erfolgreichen tunen des ARD-Transponders mit dem alten Treiber/Karte zu sehen. (Aktivieren der Log-Funktionen sollte auch da genau so funktionieren.)