Posts by mighty-p

    Hmm, also zur Technisat HD kann ich wenig sagen, die Karte kenne ich nicht. Du könntest allerdings auf dem bestehenden System in einer Konsole bzw. im Terminal mal "lspci -v -nn" eingeben und dort schauen, was zu der Karte ausgegeben wird. Es interessieren sowohl die IDs, die in der Zeile "Subsystem" stehen als auch die benutzten "Kernel modules". Mit den Angaben kann man dann weiter recherchieren, wie es bzgl. Linux-Support mit aktuellen Kernels bzw. Distributionen aussieht.

    frosch wrote:

    aber beispielsweise für die DVB Sky waren die letzten Treiber für den 4'er Kernel. Mit nem 5'er werden die wohl nicht mehr laufen.

    Die Treiber für die ganzen DVBSky 9xx-Karten sind doch schon seit ewig (ich glaub seit 3.19 oder so) im Kernel drin und man muss nur noch die Firmware nach /lib/firmware kopieren. Ich kann mir kauf vorstellen, dass die wieder aus dem Kernel rausgeflogen sind.

    Also bei den Legacy-Anschlüssen sollte sich nach meinem Dafürhalten an den Dosen nichts ändern. Den Digibit R1 willst du ja mit dem Unicable-Strang versorgen. Laut R1-Bedienungsanleitung muss man da einfach nur das Kabel an den ersten der vier LNB-Anschlüsse anschließen, die restlichen 3 bleiben leer. Bei dieser Konstellation würde ich behaupten, dass es egal ist, ob das Kabel vom LNB direkt angeschlossen oder die bereits bestehende Dose dazwischen ist.

    Zu dem Problem mit dem Umlauten:

    Das wird den gleichen Grund wie hier haben: epg-umlaute-falsch-nur-bei-hgtv . Die Texte definieren keine Codetable, daher wird die (falsche) Default-Table genommen. Es gibt doch bei t2scan die Option "-I" für z.B ISO-8859-15. Damit sollten die Umlaute richtig dargestellt werden.

    Das ist aber kein ernstes Problem, da VDR die Namen bei einem EPG-Scan später selbst richtigstellt.

    Das wurde jetzt dank eines anderen Users, der auf der Gitlab-Projektseite dafür ein Issue eröffnet hat, mal genauer analysiert.


    Problem ist, dass der ORF in seinen Strings in der SDT kein Character Encoding angibt (laut Norm [Appendix A.2, Seite 101] muss geschaut werden ob das erste Byte des Strings im Bereich 0x00 bis 0x19 ist - dann bestimmt es das Encoding; ist es 0x20-0XFF dann ist es bereits das erste Byte des Strings und man soll "ISO6937 with addition of the Euro symbol" annehmen). Bei ORF würde also das Default greifen. Da war aber auch noch ein Bug in t2scan und ISO6937 wurde nicht korrekt benutzt; den hab ich jetzt im GIT gefixt. Dummerweise klappt aber auch das für den ORF nicht, da er die Strings nicht wie vorgesehen in ISO6937, sondern in ISO8859-15 encodiert. Mit der korrigierten Version im GIT wird jetzt halt "Radio ¬sterreich 1" erkannt. Ein speziellen Handling für ORF oder einen Parameter zur Setzung des Default-Encodings muss also noch eingebaut werden. "-I" hilft hier nicht, weil er nur das Encoding des Ziel-Systems überschreibt.

    Hmm... guter Punkt, also einfach die Einträge mit "S28.2E" in der sources.conf nochmal duplizieren und auf "S28.5E" ändern.


    Wobei ich mich gerade frage, ob es überhaupt noch nen Satelliten auf 28.5° Ost gibt. Lyngsat listet den nicht mehr auf. In der Vergangenheit waren ja die Satelliten auf 28.2E von Astra und der auf 28.5E von Eutelsat betrieben worden, aber empfangstechnisch war es praktisch eine Position. Ich glaube, inzwischen hat da Astra alles übernommen und 28.5E ist daher wohl Geschichte.

    Also den 28.2er und 28.5er sollte man als einen Satelliten in der diseqc.conf (und auch channels.conf) eintragen, am besten als "S28.2E". Das macht vieles einfacher.


    Wenn du bei deinem Diseqc 2/1 Schalter S19.2E auf A hast und S28.2E auf B, dann passt folgende diseqc.conf:


    Code
    1. S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 t
    2. S19.2E 99999 V 10600 t v W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 T
    3. S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 t
    4. S19.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 T
    5. S28.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 [E1 10 38 F4] W15 t
    6. S28.2E 99999 V 10600 t v W15 [E0 10 38 F5] W15 [E1 10 38 F5] W15 T
    7. S28.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 [E1 10 38 F6] W15 t
    8. S28.2E 99999 H 10600 t V W15 [E0 10 38 F7] W15 [E1 10 38 F7] W15 T

    Falls du umgekehrt angeschlossen hast, sieht es entsprechend so aus:

    Code
    1. S28.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 t
    2. S28.2E 99999 V 10600 t v W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 T
    3. S28.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 t
    4. S28.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 T
    5. S19.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 [E1 10 38 F4] W15 t
    6. S19.2E 99999 V 10600 t v W15 [E0 10 38 F5] W15 [E1 10 38 F5] W15 T
    7. S19.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 [E1 10 38 F6] W15 t
    8. S19.2E 99999 H 10600 t V W15 [E0 10 38 F7] W15 [E1 10 38 F7] W15 T

    pbg4 Hab deinen Log erhalten. Nach erster Draufsicht sieht es so aus, dass der Tuner auf den Kanälen 35 (ZDF), 42, 48 und 22 (jeweils freenet) keinen Lock kriegt, also im Endeffekt kein gültiges Nutz-Signal findet. Dass "FE_HAS_SIGNAL" und "FE_HAS_CARRIER" angezeigt werden, bedeutet dass der Tuner schon merkt dass etwas da ist, aber er dann halt nichts da raus fischen, womit er dann wirklich etwas anfangen könnte (das wäre dass "FE_HAS_LOCK"). Und ohne ein Lock kann dann natürlich nichts gefunden werden (daher die Fehlermeldung "no data" von t2scan). Ob das fehlende Lock jetzt am Tuner selbst liegt oder am Empfang (zu stark, zu schwach*) kann ich nicht beurteilen.

    Falls es der Tuner ist, könnte es natürlich wirklich sein dass er mit den benutzten Sendeparametern aus irgendeinem Grund nicht kompatibel ist (wurde ja auch bereits hier im Thread vermutet) - oder dass die ganzen AUTO-Einstellungen (für Guardinterval, FEC, QAM, Transmission, Hierarchy) hier irgendwie nicht die richtigen Parameter finden. Bei letzterem könnte man noch schauen, ob dvbv5-scan mit einer geeigneten Anfangsdatei (wo man wirklich die Kanäle mit den genauen Parametern reinschreiben müsste) mehr Erfolg hat.


    (Hat zwar nichts mit dem obigen Problem zu tun, aber) Seltsam ist übrigens auch dass der NDR im T2-Delivery-Descriptor PLP ID 1 signalisiert, obwohl die Programme auf PLP ID 0 sind. t2scan korrigiert das dann zwar, aber eigentlich sollten solche falsche Daten in der NIT nicht sein.


    Edit/Ergänzung: * Die von ZDF und Freenet benutzten FECs von 3/5 bzw. 2/3 erfordern natürlich einen besseren Empfang als NDR und RB mit seinem FEC 1/2, da hier einfach weniger Korrektur-/Redundanz-Daten gesendet werden).

    Hi pbg4 kannst du das Log mit "-vvv" mal hier anhängen oder mir per PM zuschicken? Probier auch ruhig mal mit "-S2" bzw. "-S3" die Timeouts zu verdoppeln bzw. zu verdreifachen. Den "-p"-Parameter kannst du weglassen, die Standardeinstellung für Deutschland ist "-p-1,0,1" und die sollte passen ("-p-1" würde auch genügen, wenn du nicht die Connect-Kanäle auf den zusätzlichen PLPs finden willst).

    Der Tuner hat jedenfalls auf keiner einzigen Frequenz nen Lock gekriegt. Entweder kann er wie don-baba schreibt wirklich kein T2 (wobei ich jetzt aber nicht verstehe, wie da HEVC/H265 vs. H264 ein Problem sein kann, weil das ja nur der Codec ist und der eigentliche Standard zur Übertragung der gleiche ist) oder es fehlt die Firmware oder es gibt keinen Empfang.

    HelmutB Es war ganz gut, dass ich in die "is_already_scanned_transponder_t2_samefreq" nochmal reingeschaut habe, die hatte nämlich noch ein Bug (aus einem != Vergleich ist durch einen Typo eine Zuweisung nur mit = geworden). Das hab ich gefixt und dabei dann gleich auch eingebaut, dass der Edge Case von eben abgefangen wird. Es wäre hier sehr hilfreich, wenn du mal den aktuellen Stand nochmal durchlaufen lassen kannst. Ob sich der Edge Case wiederholen lässt weiß ich nicht, aber dann können wir schauen ob ich nichts beim Korrigieren der PLPs kaputt gemacht habe.


    Edit: Mist! Da hab ich doch in meinem letzten Posts die Network ID und die Transport Stream ID verwechselt. Dadurch war natürlich auch der Fix oben für den Edge Case falsch. Jetzt müsste es passen!

    HelmutB Vielen Dank fürs Testen nochmal!


    HelmutB wrote:

    Die T1-Parameter bei den beiden slowakischen T2 Transpondern (522 + 618 Mhz) werden nicht mehr übernommen.

    Danke für die Bestätigung. Dann hat der Fix da ja geklappt :)


    Quote

    Auf 722 Mhz ist das Signal heute nicht sehr stabil und da hat sich beim si2183 ein Fehler eingeschlichen - es wurden die Programme doppelt - einmal mit "P-1" und einmal mit "P1" - in die Kanalliste übernommen. Das ist aber nur einmal vorgekommen, bei einem 2.Testlauf waren die Programme nur mit "P1" eingetragen.Auf 722 Mhz ist das Signal heute nicht sehr stabil und da hat sich beim si2183 ein Fehler eingeschlichen - es wurden die Programme doppelt - einmal mit "P-1" und einmal mit "P1" - in die Kanalliste übernommen

    Das lässt sich in deinem Log gut nachvollziehen. Wegen dem unsauberen Empfang wurde beim Versuch mit PLP ID -1 keine NIT eingelesen ("Info: no data from NIT(actual )after 17 seconds"). Daher wurden auch Transport Stream ID und Original Network ID nicht eingelesen, so dass in der Funktion "is_already_scanned_transponder_t2_samefreq" nicht festgestellt wurde, dass diese Transpoder mit der auf PLP ID 1 identisch ist. Vielleicht sollte ich hier nur die Network-ID vergleichen!? Ist aber auch eher ein "edge case".


    Das andere, was ich mir anschauen musst, ist wie "char_coding 223: iconv failed."-Warnungen herkommen. Es scheint zwar nichts schlimmes da zu passieren, aber ganz richtig sieht das auch nicht aus :)

    HelmutB Ich hab mich gerade nochmal um die Filter-Timeouts gekümmert. Die sollten jetzt hoffentlich besser aussehen.


    Edit: Und mit dem neuesten Commit sollten eigentlich nur noch Daten aus der NIT übernommen werden, wenn sie zum Delivery System auch passen. Bitte auch mal testen mit den slowakischen Transpondern :)

    Nochmal Edit: Das mit dem Zurücksetzen des Frontend-Status ist jetzt auch drin. Dafür hab ich aber festgestellt, dass einer der (zugegebenermaßen nicht immer sauber zu empfangenden) französischen Kanäle mit dem auf 5 Sekunden reduzierten PAT-Timeout nicht mehr zuverlässig gefunden (mit doppeltem Timeout von 10 Sekunden scheint es schon problemlos zu klappen); ich hab das PAT-Timeout daher wieder leicht erhöht (8 Sekunden jetzt).

    Danke für das kurze Log-Schnippsel. Das ist ja mal interessant. Bei deinem Frontend gibt es auch auf nicht benutzten PLP-IDs ein Lock und dann wartet er natürlich die vollen 30 Sekunden, bis keine Daten kommen. Bei meinem Frontend (Si2168) gibt es da erst gar keinen Lock (sondern nur Signal und Carrier), so dass es zügig weiter geht ohne die halbe Minute Zwangspause. Da muss ich also nochmal nacharbeiten.


    An die Sache mit dem Status gehe ich auch nochmal dran (klingt ja recht trivial). Bei DVB-T2 die T1-DeliverySystemDescriptors zu ignorieren ist natürlich auch nicht schwer; sind denn in diesen Transpondern auch gültige T2-Delivery-Descriptors drin?


    Duplikate ausfiltern nach Signalstärke kann t2scan in der Tat nicht. Damit hab ich rumprobiert, aber hatte bei meinem Tests keine gute Ergebnisse gehabt, weil die Signalstärke-Infos sich da nicht als verlässlich erwiesen haben. Kann aber auch an der Hardware gelegen haben oder ich hab etwas falsch gemacht. Im Moment ist eine solche Automatik nicht meine oberste Prio. Du kannst entweder "-D" nehmen um nur den zuletzt gefundenen Eintrag für den Transponder zu nehmen oder "-d" (auch in Verbindung mit "-r") um die Duplikate zu markieren und selbst aufzulösen.

    Sooo... die erste Version der oben genannten Idee für das Scannen mehrerer PLP IDs in einem Scan-Lauf ist implementiert und im GIT. Gerne dürft ihr testen und mir berichten, ob mit den Default-Werten (diese sind im Moment "-1,0,1" für die meisten Länder, "-1,1,0" für AT und IT, "-1,0,1,2" für Russland) alle Services korrekt gefunden werden (sogar in den Regionen Österreichs, wo der falsche PLP-Wert in der NIT steht müsste es klappen). Und bitte testet auch ob das manuelle Definieren von PLP-Listen mittels "-p" klappt. Danke!


    (Edit: Falls schon jemand ausprobiert hat: Ich hatte einen dummen Fehler in der scan.c und die Version im GIT hat nicht kompiliert - ist jetzt behoben).


    HelmutB Deinen neuen Patch für den Scan in VDR direkt teste ich nachher noch!

    Sooo. t2scan v0.6 ist released. Alle, die ein tgz-Paket gegenüber dem git master vorziehen, können sich das Paket hier herunterladen: https://github.com/mighty-p/t2scan/releases


    Jetzt geht es dran, die oben genannten Änderungen zu implementieren.


    HelmutB

    HelmutB wrote:

    Welche Progarmme fehlen denn auf 602 Mhz,


    Die hier:

    HelmutB wrote:

    und kannst du die Zeilen im Syslog wo dieser Transponder gescanned wird posten?

    Reicht dir der Schnippsel? Ansonsten schick ich das ganze Log per PM.

    Wenn ich nach den Punkten oben noch Zeit habe, kommt vielleicht noch eine Option dazu, um zusätzliche Transponder aus der NIT zu finden und zu scannen. Im Moment wird die NIT ja nur genutzt, um aus dem Delivery Descriptor die genauen Parameter des aktuellen Transponders zu lesen (bzw. wird ignoriert wenn -U gesetzt ist).

    Gut :) Ich werde jetzt erstmal den aktuellen Stand von t2scan als Version 0.6 releasen und es danach umbauen.


    Folgendes hab ich dabei vor:

    1. Der Parameter "-p" wird (ähnlich zu -l für die Kanalliste) eine komma-getrennte Liste an PLP IDs aufnehmen können

    2. Defaultmäßig (also ohne -p) werde ich die PLPs NO_STREAM_ID_FILTER (nur wenn FE_CAN_MULTISTREAM gesetzt ist), 0 und 1 scannen. Andere PLP-IDs scheint ja bisher auch noch keiner hier im Portal gesehen zu haben, daher denke ich, reicht das. Wer höhere zusätzliche PLP IDs scannen will, kann -p benutzen.

    3. Ich werde etwas einbauen müssen, damit durch Punkt #2 keine Netzwerke doppelt auf derselben Frequenz gefunden werden (und idealerweise eine PLP auch gar nicht 2x gescannt wird nach NO_STREAM_ID_FILTER - ich kann hier evtl. die Daten aus dem T2-Delivery-Descriptor nutzen).

    4. Wenn es bei der als erstes gescannten PLP ID gar kein Signal auf der Frequenz gibt, werde ich abbrechen und zur nächsten Frequenz weiterspringen, um die Scan-Zeit nicht unnötig zu erhöhen (das mache ich evtl. ausschaltbar, aber ich hoffe das müsste für alle Frontends funktionieren).


    Ich denke, das wird für t2scan der beste Kompromiss sein, um möglichst alle Services (zumindest für die real in Europa genutzten DVB-T2-Ausstrahlungen) zu finden, ohne zu viel Zeit zu verbraten.

    Ich bin gerade am Überlegen, ob das mit dem NO_STREAM_ID_FILTER überhaupt von allen Frontends unterstützt wird. Ich hab mal ein bisschen durch den dvb-frontends-Source Code gebrowsed und und wenn ich z.B. den hier korrekt lese, wird bei NO_STREAM_ID_FILTER einfach nur die PLP auf 0 gesetzt (Zeile 372). Wenn ich das jetzt nicht gerade völlig falsch lese. Das wäre jedenfalls nicht unbedingt Sinn der Sache dann.