Zitat
switch a, case 1, if a = 1 then...? Ist das so richtig?
Kommentare dazu überlasse ich lieber anderen ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Ich habe mal einen Quick'nDirty-Vergleich mit tvheadend gemacht. Bislang habe ich noch keine Fehler oder Probleme im Log erkennen können. Noch ist es aber auch ziemlich mit'm Scannen beschäftigt. Allgemein ein sehr redseliger Geselle, das tvheadend.
Ich sehe im vdr-code keinen bug:
Wenn ich mir den Status tsLocked gemerkt habe, aber der neu vom Frontend geholte Status weder FE_REINIT noch FE_HAS_LOCK gesetzt hat, habe ich den Lock verloren.
Frag' mich halt, woher das kommen soll bzw. wie VDR darauf kommt, dass kein Lock mehr da sein soll. "lost lock" heisst normalerweise soviel wie "Stream/Empfang/Frequenz weg oder gestört", ist bei Pontus aber ganz klar nicht der Fall... Das zusätzliche "if" sieht halt insofern merkwürdig aus, als dass diese Condition niemals "false" ergeben kann...
Sich könnte man auf das if verzichten, entscheidend ist doch aber, warum der Treiber FE_HAS_LOCK nicht (mehr?) gesetzt hat.
@Pontus: Kannst Du das mal mit dvb-fe-tool auf der CLI gegenprüfen?
# dvb-fe-tool -m -a <Adapter>
und dann schauen, was nebenher im VDR so protokolliert wird.
ZitatAlles anzeigen
Pontus: Kannst Du das mal mit dvb-fe-tool auf der CLI gegenprüfen?
Quellcode
1
# dvb-fe-tool -m -a <Adapter>
und dann schauen, was nebenher im VDR so protokolliert wird.
Das kann ich natürlich machen.
Wenn ich mich richtig erinnere, müssten die Werte eigentlich ganz gut sein, oder? Sie rangieren stetig zwischen -36 und -25 dBm.
# dvb-fe-tool -m -a /dev/adapter0
ock (0x1f) Signal= -25.49dBm C/N= 36.76dB UCB= 0 postBER= 5.39x10^-6
Lock (0x1f) Signal= -25.55dBm C/N= 37.23dB UCB= 0 postBER= 8.38x10^-6
Lock (0x1f) Signal= -25.75dBm C/N= 36.66dB UCB= 0 postBER= 6.28x10^-6
Lock (0x1f) Signal= -24.84dBm C/N= 36.57dB UCB= 0 postBER= 3.89x10^-6
Lock (0x1f) Signal= -25.49dBm C/N= 37.33dB UCB= 0 postBER= 7.18x10^-6
Lock (0x1f) Signal= -25.55dBm C/N= 37.33dB UCB= 0 postBER= 7.18x10^-6
Lock (0x1f) Signal= -25.88dBm C/N= 37.42dB UCB= 0 postBER= 6.88x10^-6
Lock (0x1f) Signal= -25.29dBm C/N= 37.42dB UCB= 0 postBER= 6.28x10^-6
Lock (0x1f) Signal= -25.75dBm C/N= 37.42dB UCB= 0 postBER= 5.09x10^-6
Lock (0x1f) Signal= -24.97dBm C/N= 37.04dB UCB= 0 postBER= 5.98x10^-6
Lock (0x1f) Signal= -25.49dBm C/N= 37.33dB UCB= 0 postBER= 8.68x10^-6
Lock (0x1f) Signal= -25.36dBm C/N= 37.14dB UCB= 0 postBER= 3.59x10^-6
Lock (0x1f) Signal= -25.49dBm C/N= 36.66dB UCB= 0 postBER= 5.68x10^-6
Lock (0x1f) Signal= -25.49dBm C/N= 37.14dB UCB= 0 postBER= 5.98x10^-6
Lock (0x1f) Signal= -25.81dBm C/N= 37.23dB UCB= 0 postBER= 4.19x10^-6
Lock (0x1f) Signal= -25.94dBm C/N= 37.61dB UCB= 0 postBER= 5.39x10^-6
Lock (0x1f) Signal= -34.23dBm C/N= 36.57dB UCB= 0 postBER= 6.28x10^-6
Lock (0x1f) Signal= -34.10dBm C/N= 37.04dB UCB= 0 postBER= 8.08x10^-6
Lock (0x1f) Signal= -34.29dBm C/N= 36.85dB UCB= 0 postBER= 7.18x10^-6# dvb-fe-tool -m -a /dev/dvb/adapter1
Lock (0x1f) Signal= -25.16dBm C/N= 37.04dB UCB= 0 postBER= 5.68x10^-6
Lock (0x1f) Signal= -25.16dBm C/N= 37.04dB UCB= 0 postBER= 5.09x10^-6
Lock (0x1f) Signal= -25.55dBm C/N= 37.14dB UCB= 0 postBER= 4.19x10^-6
Lock (0x1f) Signal= -24.91dBm C/N= 37.33dB UCB= 0 postBER= 7.78x10^-6
Lock (0x1f) Signal= -25.81dBm C/N= 37.14dB UCB= 0 postBER= 6.88x10^-6
Lock (0x1f) Signal= -25.62dBm C/N= 37.04dB UCB= 0 postBER= 7.48x10^-6
Lock (0x1f) Signal= -25.42dBm C/N= 37.33dB UCB= 0 postBER= 7.78x10^-6
Lock (0x1f) Signal= -25.42dBm C/N= 37.23dB UCB= 0 postBER= 6.28x10^-6
Lock (0x1f) Signal= -25.16dBm C/N= 37.14dB UCB= 0 postBER= 6.28x10^-6
Lock (0x1f) Signal= -25.36dBm C/N= 37.14dB UCB= 0 postBER= 5.98x10^-6
Lock (0x1f) Signal= -25.55dBm C/N= 37.04dB UCB= 0 postBER= 5.09x10^-6Meist loggt der vdr währenddessen nichts. Es treten zwar einige Meldungen zum verlorenen Lock auf, allerdings sind die nicht unbedingt die von dem Tuner, den ich blockiere.
Bei dvb-fe-tool -m -a /dev/dvb/adapter0 trat fast sofort dies auf:
vdr[4683]: [4689] frontend 0/0 lost lock on channel 14 (SAT.1 Gold), tp 538
Mär 18 15:24:19 openmediavault vdr[4683]: [4689] frontend 0/0 regained lock on channel 14 (SAT.1 Gold), tp 538Aber bei dvb-fe-tool -m -a /dev/dvb/adapter1, beschwerte sich der vdr zuerst über adapter0.
ZitatAlles anzeigen
Mär 18 15:27:12 openmediavault vdr[4683]: [4689] frontend 0/0 lost lock on channel 6 (RTL II), tp 394
Mär 18 15:27:12 openmediavault vdr[4683]: [4689] frontend 0/0 regained lock on channel 6 (RTL II), tp 394
[…]
Mär 18 15:29:14 openmediavault vdr[4683]: [4692] frontend 1/0 lost lock on channel 2 (ZDF HD), tp 450
Mär 18 15:29:14 openmediavault vdr[4683]: [4692] frontend 1/0 regained lock on channel 2 (ZDF HD), tp 450
Habe das Ganze beim Schreiben dieser Zeilen nochmal wiederholt (nur auf adapter0) und der Output hierzu lautete:
Mär 18 15:37:05 openmediavault vdr[1518]: [1821] frontend 0/0 lost lock on channel 14 (SAT.1 Gold), tp 538
Mär 18 15:37:05 openmediavault vdr[1518]: [1821] frontend 0/0 regained lock on channel 14 (SAT.1 Gold), tp 538
Mär 18 15:37:56 openmediavault vdr[1518]: [1836] frontend 1/0 lost lock on channel 4 (RTL), tp 122
Mär 18 15:37:56 openmediavault vdr[1518]: [1836] frontend 1/0 regained lock on channel 4 (RTL), tp 122
Mär 18 15:39:17 openmediavault vdr[1518]: [1821] frontend 0/0 lost lock on channel 49 (1-2-3.tv HD), tp 826
Mär 18 15:39:17 openmediavault vdr[1518]: [1821] frontend 0/0 regained lock on channel 49 (1-2-3.tv HD), tp 826Sollte vdr nicht währenddessen den lock permanent verlieren oder bin ich hier schief gewickelt?
Grüße
Chris
Wenn ich mich richtig erinnere, müssten die Werte eigentlich ganz gut sein, oder? Sie rangieren stetig zwischen -36 und -25 dBm.
Code# dvb-fe-tool -m -a /dev/adapter0 Lock (0x1f) Signal= -25.55dBm C/N= 37.23dB UCB= 0 postBER= 8.38x10^-6
Unauffällig (am wichtigsten ist eh C/N bzw. SNR, und rund 37dB SNR sind "sorglos"). Die Negativwerte bei der Signalstärke halte ich für falsch, sehen bei mir aber auch so aus. Spannender rund um das "Problem" ist, dass "Lock" stehen bleibt.
Bei dvb-fe-tool -m -a /dev/dvb/adapter0 trat fast sofort dies auf:
Dürfte unter "Zufall" einzusortieren sein.
Habe das Ganze beim Schreiben dieser Zeilen nochmal wiederholt (nur auf adapter0) und der Output hierzu lautete:
CodeMär 18 15:37:05 openmediavault vdr[1518]: [1821] frontend 0/0 lost lock on channel 14 (SAT.1 Gold), tp 538 Mär 18 15:37:05 openmediavault vdr[1518]: [1821] frontend 0/0 regained lock on channel 14 (SAT.1 Gold), tp 538
Erschliesst sich mir absolut nicht, warum das so "random" (im Sinne von Channel, Frequenz und zeitlicher Abstand) passiert bzw. passieren soll... Alles ganz sicher immernoch ohne Bild/Tonfehler?
Sollte vdr nicht währenddessen den lock permanent verlieren oder bin ich hier schief gewickelt?
Beim Statistiken lesen wird ja eben nur "gelesen" 
Also das, was der Demod Richtung Userspace schon bereit gestellt hat, wird nochmal weitergegeben. Das dürfen durchaus auch mehrere Clients, nur Dinge wie Umschalten werden unterbunden.
Ich bastel' mir mal 'ne VDR-Installation auf der Dev-Büchse zurecht und versuch' mal rauszufinden, was da rumspinnt...
Ich bastel' mir mal 'ne VDR-Installation auf der Dev-Büchse zurecht und versuch' mal rauszufinden, was da rumspinnt...
Hmmm....
Bild/Ton durchgängig störungsfrei. Glaub' das eskalier' ich mal RIchtung NetUp (die haben den Demod-Treiber ursprünglich für ihre UniDVB Hardware geschrieben) und frag' ggf. Klaus. Sieht mir zwar stark nach kosmetischem Defekt aus - nichtsdestotrotz.
nst
Nein, die Meldungen besagen eigentlich nur, dass der Demodulator keine "read_signal_strength"-Operation zur Verfügung stellt. Wenn MythTV das kann, stell's mal auf "DVBv5"-Statistiken um.
Ich hab vergeblich DVBv5 in MythTV gesucht - gibt anscheinend keine solche Option 
Das sieht schon eher nach dem Übeltäter aus, weshalb Du nichts zu sehen bekommst. Kannst Du testweise zumindest mal einen Mux fix auf 8Mhz (bei DVB-C) einstellen, und mit den betroffenen Channels nochmal probieren?
Was soll ich auf 8MHz stellen - die Bandbreite? Die Transponderfrequenzen gehen meines Wissens erst bei 48MHz los. MythTV findet bei einem Scan keine Signale, egal was ich probiere und im Log spuckt's mir immer wieder obige Fehlermeldung aus.
Interessanterweise, wenn ich mit den Treibern einen w_scan laufen lasse, werden Kanäle (insgesamt 393) gefunden:
w_scan -f c -c DE
w_scan version 20141122 (compiled for DVB API 5.10)
using settings for GERMANY
DVB cable
DVB-C
scan type CABLE, channellist 7
output format vdr-2.0
WARNING: could not guess your codepage. Falling back to 'UTF-8'
output charset 'UTF-8', use -C <charset> to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> CABLE "Sony CXD2843ER DVB-T/T2/C/C2 demodulator": very good :-))
Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.10
frontend 'Sony CXD2843ER DVB-T/T2/C/C2 demodulator' supports
INVERSION_AUTO
QAM_AUTO
FEC_AUTO
FREQ (48.00MHz ... 864.00MHz)
This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
<viel viel viel Text>Könnte also durchaus sein, dass MythTV etwas pingeliger ist bei den Treibern. Bei einem w_scan für DVB-T taucht diese letzt Zeile nicht auf:
Die Treiber scheinen also fast zu funktionieren, aber halt nur so, dass MythTV damit nicht klarkommt 
Wo werden die "symbol rate limits" definiert?
Ich hab vergeblich DVBv5 in MythTV gesucht - gibt anscheinend keine solche Option
Ok. Sollte aber nicht mehr als ein kosmetisches Problem sein. Dürfte auch mit anderer Hardware auftreten.
Was soll ich auf 8MHz stellen - die Bandbreite? Die Transponderfrequenzen gehen meines Wissens erst bei 48MHz los. MythTV findet bei einem Scan keine Signale, egal was ich probiere und im Log spuckt's mir immer wieder obige Fehlermeldung aus.
Die Kanal/Frequenzbandbreite auf 8MHz setzen, sofern MythTV das zulässt.
Codew_scan -f c -c DE w_scan version 20141122 (compiled for DVB API 5.10) ... /dev/dvb/adapter0/frontend0 -> CABLE "Sony CXD2843ER DVB-T/T2/C/C2 demodulator": very good :-)) ... This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org)
Könnte also durchaus sein, dass MythTV etwas pingeliger ist bei den Treibern. Bei einem w_scan für DVB-T taucht diese letzt Zeile nicht auf:
Och...?
Die Treiber scheinen also fast zu funktionieren, aber halt nur so, dass MythTV damit nicht klarkommt
Wo werden die "symbol rate limits" definiert?
Die Limits stehen in den dvb_frontend_ops, die der Demod-Treiber bereitstellt
Kannst Du mal testweise diesen Patch OnTop auf media_build (oder als Zusatzpatch für gentoo-sources, jenachdem was Du einsetzt) gentoo-sources testen? Zumindest das w_scan-Problem verschwindet damit bei mir, evtl. hilft das MythTV auf die Sprünge.
EDIT: Gentoo in Deiner Sig gefunden
EDIT2: Hinweis: Wenn Du den Patch nicht direkt auf die Source in /usr/src/linux anwendest, sondern in /etc/portage/patches ablegst, bitte unbedingt an anschliessendes "emerge gentoo-sources" denken!
EDIT3: (semi-unrelated) Oh, der ST STV0367 DDB hat noch dasselbe Problem...
Hallo,
wenn ich die Kerneltreiber baue und installiert setze ich damit mein yavdr LIRC außer Funktion.
(mein serieller ATRIC nimmt keinen Tastendruck mehr an - Empfangs-LED leuchtet nicht)
Hat jemand eine Idee wie man das nach der Installation des Treibers wieder fixen kann?
Gilbert
Kannst Du mal testweise diesen Patch OnTop aufmedia_build (oder als Zusatzpatch für gentoo-sources, jenachdem was Du einsetzt)gentoo-sources testen? Zumindest das w_scan-Problem verschwindet damit bei mir, evtl. hilft das MythTV auf die Sprünge.
EDIT: Gentoo in Deiner Sig gefunden
EDIT2: Hinweis: Wenn Du den Patch nicht direkt auf die Source in /usr/src/linux anwendest, sondern in /etc/portage/patches ablegst, bitte unbedingt an anschliessendes "emerge gentoo-sources" denken!
EDIT3: (semi-unrelated) Oh, der ST STV0367 DDB hat noch dasselbe Problem...
Hab den Patch angewandt - danke für die Hinweise. Die Fehlermeldung von w_scan ist bei mir nun auch weg, aber die Ursache für fehlenden Bild und Ton in MythTV war's nicht.
Aber es funktioniert nun - Bild und Ton sind beide da für DVB-C! Dazu musste ich via
$ dvb-fe-tool -a1 --set-delsys=DVBC/ANNEX_Aden zweiten Adapter manuell von DVB-T auf DVB-C umstellen. Danach funktioniert das DVB-C Fernsehen via MythTV und Kodi. Im Log tauchen nun die Fehlermeldungen nicht mehr auf.
Das kann wohl dran liegen, dass MythTV 0.27 die Frontends nicht automatisch umschaltet, siehe [mythtv-users] DVB delivery systems, und dann das auf DVB-T eingestellte Frontend als DVB-C anspricht.
DVB-T hab ich noch nicht am Laufen, da kümmere ich mich aber ein andern Mal drum. Dort liefert mir w_scan Kanäle, aber MythTV nicht.
Hab den Patch angewandt - danke für die Hinweise. Die Fehlermeldung von w_scan ist bei mir nun auch weg, aber die Ursache für fehlenden Bild und Ton in MythTV war's nicht.
Hm, Ok. Dürfte trotzdem nicht schaden, daher in der Zwischenzeit: https://patchwork.linuxtv.org/patch/40145/ 
Aber es funktioniert nun - Bild und Ton sind beide da für DVB-C!
Code$ dvb-fe-tool -a1 --set-delsys=DVBC/ANNEX_Aden zweiten Adapter manuell von DVB-T auf DVB-C umstellen.
Ui, also da hätt' ich das Problem offen gesagt jetzt nicht vermutet Dann funktioniert der offizielle DD/dddvb-Stack für Dich wohl auch nur, weil DD's cxd2843 die Reihenfolge DVB-C/T/T2 anstatt T/T2/C (cxd2841er) vorgibt und das erste System "voreingestellt" wird. Den "set-delsys"-Hack müsstest Du dann genau genommen für alle Frontends ausführen, damit alles läuft.
Wäre sehr cool, wenn Du in ein paar Tagen mal berichten könntest, wie dieser Treiberstack bei Dir läuft! Danke fürs Testen!
Hm, Ok. Dürfte trotzdem nicht schaden, daher in der Zwischenzeit: https://patchwork.linuxtv.org/patch/40145/
Ui, also da hätt' ich das Problem offen gesagt jetzt nicht vermutet
Wäre sehr cool, wenn Du in ein paar Tagen mal berichten könntest, wie dieser Treiberstack bei Dir läuft! Danke fürs Testen!
Ja, da scheinen einige Zufälle zusammen funktioniert zu haben Ich melde mich in ein paar Tagen wieder mit einem Testresultat.
Moin,
FYI (kleinere Änderungen): stv0367/ddbridge: support CTv6/FlexCT hardware (v2)
@djpearman: Wie geht's Deinem MythTV mit den CXD28xx-Patches?
@Pontus: Ist es bei dem kosmetischen Effekt ("lost lock/regained lock") geblieben, oder haben sich ggf. doch noch andere Problemchen eingeschlichen?
Sodele.
EDIT: Ääh... Kann es sein, dass die "lost lock" Zeilen ein VDR-Problem/Bug sind?
Um das direkt klar- und richtig zu stellen: Auch wenn das select/if im VDR-Code "seltsam" aussieht - VDR hat hier ganz klar KEIN(!) Problem, ist aber wesentlich gesprächiger und genauer. Ein bisschen Debug im cxd2841er hat gezeigt, dass durch die Art und Weise, wie Dinge dort gehandhabt werden, der Status quasi im <100ms-Intervall aus den Demods "herausgehämmert" wurde, und das wird bei mehr als einem Tuner auf dem I2C-Bus dann mal mit "0" (kein Lock mehr) quittiert. Das dürfte auch der Grund sein, warum bei einigen wenigen Auslesevorgängen der SIgnalstatistiken ebenfalls "0" zurückgeliefert wurde. Ich habe dazu einen Patch in die passenden Branches gepusht, der das Verhalten reguliert - die Meldungen sind zumindest bei mir weg. Die Mutmaßungen rund um mögliches Fehlverhalten in VDR bitte ich zu ignorieren
@Pontus: Bitte zieh' Dir doch nochmal den mediatree/master-stv0367-cxd28xx Branch komplett neu (Achtung! Rebase/Commit-History umgeschrieben!) und schau' mal, ob dadurch jetzt komplett Ruhe einkehrt - Danke!
@djpearman: Falls MythTV ebenfalls mit ähnlichen Meldungen um sich geworfen hat, bitte auch nochmals testen - Danke!
@all: In dem Branch ist mittlerweile ebenfalls Support für die MaxA8-Serie (CT2, C2T2, C2T2I usw.) von Digital Devices eingeflossen - Falls jemand eine derartige Karte hat, wäre es richtig toll, wenn die Treiber/Patches gegen diesen Kartentyp getestet werden würden! Je nachdem, was es mit den Patches auf linux-media so wird, wäre dann die gesamte C(2)/T(2) Serie abgedeckt und durch Mainline unterstützt.
Grüße,
nst
Zitat
Ein bisschen Debug im cxd2841er hat gezeigt, dass durch die Art und Weise, wie Dinge dort gehandhabt werden, der Status quasi im <100ms-Intervall aus den Demods "herausgehämmert" wurde, und das wird bei mehr als einem Tuner auf dem I2C-Bus dann mal mit "0" (kein Lock mehr) quittiert. Das dürfte auch der Grund sein, warum bei einigen wenigen Auslesevorgängen der SIgnalstatistiken ebenfalls "0" zurückgeliefert wurde. Ich habe dazu einen Patch in die passenden Branches gepusht, der das Verhalten reguliert - die Meldungen sind zumindest bei mir weg. Die Mutmaßungen rund um mögliches Fehlverhalten in VDR bitte ich zu ignorieren
Interessant. Vielleicht sollte ich beizeiten doch mal mein Interesse stillen und mir genauer ansehen, wie die Technik genau funktioniert. 
Ich werde deine Updates in den nächsten Tagen testen. Sollte voraussichtlich morgen oder so sein. Fehler oder Bildaussetzer hatte ich bislang immer noch keine, die mir aufgefallen wären. Aber jede kleine Verbesserung sollten die Chancen, auf eine Integration ein klein wenig verbessern.
Gruß
Chris
nst,
die Meldungen über den verlorenen Lock-State treten bei mir noch immer auf. Ich habe wie instruiert, den Branch neugezogen.
Das Verhalten von dvb-fe-tool besteht auch noch:
dvb-fe-tool -m -a /dev/dvb/adapter0 liefert
Gibt es irgendetwas, das ich machen kann/soll, um hier weiter zu debuggen?
PS: Danke für das build_all.sh-Script aus deinem media_build git bzw. dem Hinweis in dem anderen Thread. Ich hatte auch schon überlegt, dass ich diese Schritte etwas automatisieren sollte.
die Meldungen über den verlorenen Lock-State treten bei mir noch immer auf. Ich habe wie instruiert, den Branch neugezogen.
Uh... Nur um sicher zu gehen - in den Sourcen, aus denen Du compiliert hast: Steht in drivers/media/dvb-frontends/cxd2841er.c in Zeile 3633 was von "if (*status & FE_HAS_LOCK) return 0;" vor "return read_status_tc();"?
Das Verhalten von dvb-fe-tool besteht auch noch:
Da seh' ich ausser gutem Empfang nix aussergewöhnliches.
Gibt es irgendetwas, das ich machen kann/soll, um hier weiter zu debuggen?
Wie genau hast Du die neuen Sourcen/Treiber jetzt installiert? Immer noch per Patch in /etc/portage/patches/ oder über die media_build Schiene? Wenn Du ersten Weg nimmst, denk' daran, dass Du nochmal "emerge gentoo-sources" ausführen musst, um den Patch wirklich zu applien. Anschliessend Kernel neu compilen.
PS: Danke für das build_all.sh-Script aus deinem media_build git bzw. dem Hinweis in dem anderen Thread. Ich hatte auch schon überlegt, dass ich diese Schritte etwas automatisieren sollte.
Yep, das macht die Sache deutlich bequemer
EDIT/Nachtrag: Ich denke, ich werd' dem cxd2841er noch das aggressive Status-Polling unmittelbar beim Umschalten abgewöhnen. Nachdem ich jetzt noch ein bisschen getestet hab, ist VDR mir glatt ebenfalls wieder mit lost lock/regained lock entgegengekommen... Das passiert aber nur (noch) beim Umschalten, und mit großer Wahrscheinlichkeit, wenn auf eine Frequenz geschaltet wird, wo nichts drauf ist (also in "timed out" endet). Wenn beide Tuner dauerhaft streamen, oder nur einer aktiv ist, wird die Meldung eher nicht aufpoppen. Komplett vermeiden wird sich das aber nicht lassen (vermutlich greift dann hier noch das mutex_lock'ing in DD's cxd2843, aber DAS rüberzuportieren wird 'ne heftige Baustelle, da viel an der Arbeitsweise des Treibers umgebaut werden muss). Patch push' ich voraussichtlich morgen Abend ins Git.
Servus,
@Pontus: Magst Du nochmal alles neu Clonen bzw. vom Remote updaten und nochmal installieren und testen? Ich habe dieses und dieses hinzugefügt, das reduziert die Lock State inquiries speziell beim Umschalten auf das absolute Minimum. "lost lock"+"regained lock" kann immer noch auftreten, sollte dadurch aber jetzt weitestgehend reduziert werden.
Danke & Grüße,
nst
P.S.: @djpearman: Ping
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!