Posts by mighty-p

    Also 19.2°+28.2° ist zumindest hier im Raum Saarbrücken mit ner normalen 80cm-Schüssel (in meinem Falle von Gibertini, aber eigentlich sollte es jede einigermaßen vernünftige Schüssel tun) als Multifeed kein Problem, egal welchen der beiden Astras man schielen lässt. Laut der Karte von Andreas Beitinger liegt Münster für den Astra 2 etwas ungünstiger als Saarbrücken, aber auch noch im 60cm-Bereich. Da müsste man dann ausprobieren, ob das Signal noch genügend Regenreserve hat, wenn man schielen lässt. Oder halt (auch wenn es vom Ausrichten schwieriger ist) die Schüssel erstmal auf nen Satelliten zwischen 19.2° und 28.2° ausrichten, und dann beide schielen lassen. Oder auf 28.2° ausrichten und den 19.2° schielen lassen (der hat dann zwar etwas weniger Regenreserve, aber meiner Meinung nach ist das bei genauer Ausrichtung verschmerzbar). Das sind die Optionen.


    Französisches Fernsehen kann ich hier bei uns über DVB-T unverschlüsselt empfangen, daher hab ich mich mit dem Satellitenempfang dafür nicht so im Detail befasst. Ich glaube aber, mich zu erinnern, dass die auch über den Astra1 senden, aber man dafür einen speziellen Receiver (mit spezieller Karte) braucht, den man in Frankreich kaufen kann/muss (ob man dafür nen Wohnsitz dort angeben muss, bin ich mir nicht sicher). Mit VDR wird das vermutlich aber eher nix mit dem Empfang.

    Die Verbesserungen an t2scan gehen weiter und es gibt mehrere Updates im GIT. Das Problem mit clausmuus' Karte "TurboSight TBS 5520SE DVB-T/T2/C/C2/ISDB-T" sollte behoben sein ( clausmuus falls es doch nochmal Probleme gibt, melde dich einfach).


    Das Problem hat mir wieder gezeigt, dass es nicht ganz unwichtig ist, mit verschiedener Hardware zu testen. Daher würde mich schon interessieren, mit welcher Hardware/Frontends t2scan bereits getestet wurde und ob es zuverlässig damit läuft oder nicht. Das benutzte Frontend wird ja von t2scan am Anfang angezeigt:

    /dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Silicon Labs Si2168": very good :-))


    Bis jetzt wissen wir, dass (inzwischen) folgende Frontends erfolgreich getestet wurden:

    - Silicon Labs Si2168 (wird z.B. in der von mir benutzten "DVBSky T9580 V3" verwendet, aber wohl auch in vielen anderen Karten)

    - TurboSight TBS 5520SE DVB-T/T2/C/C2/ISDB-T (Karte "TBS 5520 SE")


    Bitte gerne mit weiteren Karten testen und mir Rückmeldung geben (auch gerne über die Funktion "Konversationen"/PM, um diesen Thread nicht zu sehr zuzumüllen). Ich dokumentiere die Ergebnisse in der Datei TESTED_HARDWARE, die seit heute auch im GIT drin ist. Gerne auch melden, wenn es mit einer bestimmten Karte eben NICHT klappt.



    Dann noch ein Thema zu den erzeugten channel.conf Einträgen. Im Moment tuned t2scan ja mit fast allen Einstellungen auf AUTO (z. B. FEC_AUTO, TRANSMISSION_AUTO, QAM_AUTO, ...) und liest dann die genauen Kanal-Parameter aus der NIT. Das ergibt dann solche Ergebnisse wie


    Das Erste HD;ARD:562000:B8D0G19128S1T32Y0P0:T:27500:101=36:102=deu@17,103=mis@17:106:0:769:8468:21250:0


    Dieser channels.conf-Eintrag funktioniert bei mir auch einwandfrei in VDR, mit EPG und allem, was man so braucht :)


    Mein Gedanke ist allerdings, dass theoretisch ja in der NIT auch Blödsinn stehen kann. Damit hatten wir ja auch praktisch schon genug Probleme und es hat dazu geführt, dass Sender nicht gefunden wurden, und daher ignoriert ja t2scan auch schon vieles aus der NIT. Die Frage ist natürlich, ob die Kanalparameter in der NIT immer korrekt sind und ob inkorrekte Daten hier zu Tuning-Problemen führen würden. Und außerdem tunen die Frontends ja sowieso auch, wenn da fast alles im AUTO-Mode ist, sonst würde t2scan ja gar nichts finden.


    Daher hab ich jetzt zum Test einen undokumentierten Parameter -U drin, der dafür sorgt, dass die Kanaldaten nicht mit den Daten aus der NIT ausgelesen werden. t2scan -U ergibt demnach folgende Kanalzeile:


    Das Erste HD;ARD:562000:B8S1P0:T:27500:101=36:102=deu@17,103=mis@17:106:0:769:8468:21250:0


    Funktionieren tut die im VDR auch, auch EPG geht damit einwandfrei und ich kann keinen praktischen Unterschied im VDR sehen.


    Die Frage ist jetzt halt, "was besser ist". Also ob ich besser diese reduzierten Zeilen zum Standard von t2scan mache (und einen Parameter "-u" einführe, um das alte Verhalten zu aktivieren) oder es besser - auch auf die Gefahr dass die Daten in der NIT bei manchen Providern falsch sind - es so lasse wie es ist (weil entweder die Gefahr falsche Daten einzulesen gering ist, oder dies in der Praxis das Tuning sowieso nicht negativ beeinflussen würde).


    Wer kennt sich hierzu aus und was meint ihr?


    Ich konnte mir das Problem von clausmuus heute genauer ansehen.


    Folgendes passiert: Nach Öffnen des Frontends ist dieses manchmal in einem komischen Status. Tunen scheint zwar zu klappen, tut es aber nicht. Wenn man den Status per ioctl FE_READ_STATUS abruft, kriegt man dann auch immer schön ein -1 zurück, also den Fehlerstatus. Das wurde bis jetzt allerdings im Code komplett ignoriert :D

    Woran das Problem liegt, weiß ich nicht. Workaround in der aktuellen Fassung im GIT ist, dass ich jetzt ganz am Anfang schon einmal teste, ob FE_READ_STATUS erfolgreich ist. Wenn dies nicht ist, wird folgende Fehlermeldung ausgegeben und das Programm beendet (der Scan läuft also gar nicht erst los):

    Code
    1. main:2913: FATAL: FE_READ_STATUS failed: 11 Resource temporarily unavailable

    Man kann es dann nochmal probieren, bis es klappt.


    Wenn irgendjemand ne Idee hat, was da initial schief geht und wie man das Problem verhindert, dann lasst es mich wissen.


    Noch ganz interessant: Wenn man parallel (auf ner weiteren Konsole) femon laufen lässt - was interessanterweise immer funktioniert, also nicht diesen Fehler triggert - dann danach t2scan startet, dann scheint auch t2scan nie dieses Problem zu haben. Vielleicht hilft das ja beim Verstehen des Problems.


    Edit/Update: Ich glaub, ich hab den "root cause" gefunden. Wenn das so ist, dann erhält der aktuelle GIT-Stand auch schon ein Fix. Das Schließen und Wieder-Öffnen des Frontends im Autodetection.Code, bei dem getestet wird, welches Frontend denn zu benutzen ist, ging wohl zu schnell. Ich hab 500ms Pause dazwischen eingebaut und kann seither auf clausmuus' System das Problem nicht mehr reproduzieren.

    Mache ich. Inzwischen mach ich mir ein paar Gedanken, wo das Problem sein könnte. Ich hab auch schon den ersten neuen Ansatz und vermute, dass möglicherweise deine Karte mit den ganzen AUTO-Settings beim Tunen nicht klar kommt (Inversion, Coderate/FEC, Modulation, Transmission, Guard und Hierarchy werden ja beim Tunen alle auf AUTO gesetzt). Beim VDR hat es der Tuner natürlich dann leichter weil in der erzeugten channel.conf dann ja die gefundenen Werte (z.B. Modulation=Qam64, Guard=1/4 usw.) drin stehen. Ob es das ist, muss ich dann aber wirklich am Wochenende ausprobieren.

    Die -S Option steht nur in der Expertenhilfe ("-H").


    Danke für die Logs. Der Unterschied zwischen dem erfolgreichen und dem nicht erfolgreichen Durchlauf ist, dass beim nicht erfolgreichen Durchlauf innerhalb des Carrier-Timeouts kein Carrier (also kein Signal) gefunden wird. Das Default-Timeout ist hierfür ja 2 Sekunden, d.h. innerhalb dieser wurde kein Carrier gefunden. Man kann den Timeout jetzt mal mit "-S 2" zum Beispiel verdoppelt werden (oder mit "-S 3" gar verdreifacht). Nur ob das hilft? Gerne mal probieren, aber was auffällt ist, dass beim erfolgreichen Durchlauf bereits nach 150ms der Carrier gefunden und nach 410ms gelockt war.Trotzdem bitte mal "-S2" und "-S3" probieren, ob das verlässlich hilft. Allerdings befürchte ich hier ein irgendwie geartetes anderes Tuning-Problem, wo ich noch gar keine Idee habe, was das sein könnte. Bei allen Testläufen bitte "-v 1" als Parameter drin lassen.

    Das hört sich sehr gut an. Danke für's Testen. Hast du jetzt eigentlich den Parameter "-S" benutzt (wenn ja, mit welchem Wert?), oder geht es ohne?

    Ganz interessant für mich wäre noch, wenn du ein Log mit der *alten* Version von t2scan (also 0.4) machen könntest, dann kann ich besser verstehen, welche Änderung die Probleme beseitigt hat. Es reicht dabei, wenn der Log auf die Kanäle beschränkt wird, die du empfangen kannst, also etwa "t2scan -vv -l <kanalliste> 2>debuglog.txt". Das Debug-Log dann bitte per PM an mich. Danke!

    Danke. Das sieht doch gut aus. Die 17 Sekunden längere Scan-Dauer liegt an dem 2 sec vs. 11 sec PAT-Timeout (also der Veränderung des Filter-Timeouts). Das Szenario ist hier, dass etwas empfangen wird, aber dann der Empfang doch nicht gut genug ist, um die Sender wirklich einzulesen. Da dieses Szenario normalerweise nur einige wenige Kanäle betrifft, kann man mit dem längeren Timeout, glaube ich, leben.

    Achso, clausmuus : Falls die neue GIT-Version bei dir immer noch nicht zuverlässig klappt, schick mir bitte mal ein Scan mit Debug-Ausgabe zu (ein "-v" müsste hier schon reichen, da sieht schon ob überhaupt ein Carrier gefunden wird, ob es ein Lock gibt, und ob er die NIT scannt). Am besten beschänkst du den Scan mit "-l" auf die Kanäle, auf denen auch Services drauf sind. Sonst wird das Log doch arg lang.

    GTC   clausmuus   HelmutB und @ alle die es interessiert


    Ich habe jetzt drei weitere Commits ins GIT geschoben:

    1) Für Österreich ist die Default PLP ID bei DVB-T2 jetzt 1. Natürlich kann weiterhin mit "-p" eine andere PLP ID gescannt werden.

    2) Ich habe den Filter-Timeout (das ist der Timeout, der benutzt wird um die Programme/Services von einem bereits gelockten Kanal einzulesen; d.h. ein anderer Timeout als der mit -S beeinflussbare Tuning-Timeout) deutlich erhöht. Daher wurde dann auch der Parameter -F redundant. Mit dieser Änderung werden bei mir z.B. die Connect-Kanäle auf PLP 1 des ZDF-Muxes verlässlich eingelesen. Vorher war anscheinend manchmal der Timeout zu klein, um diesen Kanal vollständig einzulesen (da sind recht viele Services drauf)

    3) Last but not least hab ich den Versionsnummer-String auf 20190106 erhöht.


    Ich würde euch bitten, die neue Version mal gut durchzutesten. Insbesondere interessiert mich folgendes:

    1. Hat sich die Scan-Zeit (für einen vollständigen Scan) gegenüber der alten Version aus dem August (v0.4, String 20180818) in irgendeiner Weise geändert (schneller, langsamer)?

    2. Werden jetzt alle Programme verlässlich gefunden (Frage geht besonders an @clausmuss)? Wenn es da noch Probleme gibt, will ich das gerne vor einem v0.5-Release in den Griff kriegen... würde dafür ggfs. auch den Default-Tuning-Timeout ändern, wenn das etwas bringt (Verlässlichkeit geht hier schon über Schnelligkeit)

    3. Werden für Österreich jetzt die Programme gefunden, ohne dass man weitere Parameter angeben muss (also mit einem einfachen "t2scan"-Aufruf ohne Parameter)? (Frage geht besonders an GTC und HelmutB )?


    Wenn alles soweit OK ist, würde ich das ganze bald als v0.5 releasen. Danach für 0.6 würde ich gerne einbauen, dass man alle relevanten PLPs in einem Rutsch (oder zumindest einem Programm-Aufruf) scannen kann, damit wirklich alle Services gefunden werden können, ohne t2scan mehrmals aufrufen zu müssen. Danke an alle, die hier durch Testen, Patches oder generelles Feedback mithelfen!

    GTC Ich hab mir das mit den Timeouts mal angeschaut. Der Default für den Carrier-Timeout ist 2 Sekunden und der Default für den Lock-Timeout ist 4 Sekunden. Mit dem Parameter "-S x" kann man die Timeouts um Faktor x multiplizieren (also mit z. B. "-S 3" wäre der Carrier-Timeout dann 6 Sekunden und der Lock-Timeout 12 Sekunden).


    Du hast aber vollkommen Recht, dass der bisherige Code bei Timeouts von über 4 Sekunden nicht funktioniert hat. Bei den Defaults hat man das nicht gemerkt, aber bei angegebenem "-S x" mit x>=2 schon. Daher ist dein Patch jetzt auch im GIT drin. :tup


    Ich schaue mir gerade noch an, ob ich irgendwie den Default für die PLP für Österreich auf 1 gesetzt kriege. Wenn mir das gelingt, gibt es gleich noch nen weiteren Commit ins GIT. @all Weiß zufällig jemand, ob es außer Österreich noch andere Länder gibt, für die plp nicht defaultmäßig auf 0 stehen sollte?

    Die Frage ist halt, ob der Scan dadurch insgesamt länger dauern würde (da ja im Normalfall alle Kanäle von 21 bis 59 gescannt werden, auch die auf denen keine Programme sind). Da dies durchaus der Fall sein könnte, muss ich mir das genauer anschauen. Versteh mich nicht falsch, wenn es da einen Überlauf gibt, dann werde ich den auf jeden Fall fixen. Aber evtl. muss ich dann auch den Default für das Lock Timeout anpassen, so dass das mehr arbeit wird.