Beiträge von mighty-p

Zitat

Ist der Test mit dem alten w_scan wichtig?

Nur, wenn wir gucken sollen, ob da die Transport ID falsch war und deshalb da der EPG nicht ging. Ansonsten ist es aber egal.

Also in einem meiner Rechner (der sich aber leider gerade nicht in meiner Nähe befindet) ist noch ne alte AMD-Karte drin (müsste ne Radeon HD 6670) und dort geht VDR und softhddevice mit VDPAU recht problemlos. Auch die Lösung mit vnsi-Plugin und Kodi als Frontend funktioniert auf dem Rechner.

Welcher Deinterlacer und Scaler da benutzt wird, weiß ich jetzt gar nicht, kann gut sein dass es Bob ist, denn die Qualität kommt tatsächlich nicht an die auf dem anderen Rechner (an dem ich gerade sitze) mit Intel Kaby Lake onboard-Lösung, vaapidevice und VAAPI ran. Aber trotzdem hat es mir immer gereicht, um direkt auf dem PC-Monitor sowohl im Fenster als auch im Vollbild ohne Probleme Fernsehen zu schauen. Also nutzen kann man das definitiv, auch wenn es sicherlich v.a. für reine VDR-Rechner nicht die beste Option ist.

Mein Tipp an dich cupressus wäre, den xineoutput hinter dir zu lassen (ist meines Wissens eh veraltet) und stattdessen softhddevice (evtl. die Version von lnj) oder halt wirklich kodi (mit dem dafür nötigen vnsiserver-Plugin in VDR) als Ausgabe zu nehmen.

paul_astronaut Also nach nochmaliger Durchsicht der Scanergebnisse und Logs tippe ich zumindest für t2scan und w_scan_cpp auf folgende Option

Zitat von paul_astronaut

2. Die Scans haben immer schon funktionert, aber VDR hat die funktionierende channels.conf durch eine fehlerhafte ersetzt

Wenn ich einfach mal auf "Das Erste HD" schaue sieht sowohl die Zeile von w_scan_cpp:

Das Erste HD;ARD:490000000:B8S1P0Q0X0:T:0:4369=36:4370=deu@17,4371=mis@17:4372:0:769:8468:2562:0

als auch die Zeile von t2scan (dürfte anhand des Logs wie folgt sein):

Das Erste HD;ARD:490000:B8D0G19128P0S1T16Y0:T:27500:4369=36:4370=deu@17,4371=mis@17:4372:0:769:8468:2562:0

gut aus.

Problem ist, dass laut T2 Delivery System Descriptor die PLP 1 ist, was aber natürlich falsch ist. Aber dadurch wird vermutlich VDR mit UpdateChannels=5die PLP auf 1 ändern und dann geht der Sender nicht mehr. (Ergänzung: Die meisten Parameter des Strings hinter dem zweiten Doppelpunkt bringen die Karten-Frontends nicht wirklich aus dem Takt, selbst wenn sie falsch sind; aber ne falsche PLP ist normalerweise schon ein Problem. Auf den EPG hat dieser String meines Wissens aber kein Einfluss. Dafür müssen eher die Service-ID, Stream ID und Network-ID korrekt sein).

Beim alten w_scan kann je nach Version durchaus auch zusätzlich das Problem mit fehlerhaften IDs vorgekommen sein, das dann den EPG kaputt macht. Um das zu sehen müsste man auch mal w_scan -vvv laufen lassen.

Seltsam ist aber schon, dass das PLP1 im Descriptor gesendet wird. Eigentlich sollte man annehmen, dass das auch andere Endgeräte aus dem Takt bringen oder zumindest einen erfolgreichen Scan auf anderen Endgeräten verhindern kann.

Danke für den Log. Interessant. Auf den ersten Blick sieht es so aus, als wenn da eine falsche PLP (Stream ID) im T2 Delivery System Descriptor gesendet würde. Das muss ich mir morgen noch genauer anschauen. Aber mit falscher PLP können die Kanäle eigentlich nicht funktionieren.

Für t2scan wäre ich auch an einem Log des Scans (am besten mit -vvv) interessiert, damit ich mir mal anschauen kann, was da passiert. Auch würde mich interessieren, ob der Parameter -U in diesem Fall helfen würde, eine channels.conf-Zeile zu kriegen, bei der EPG funktioniert.

Zitat von Lindemann

@Setup:

1.) EXR904 - Astra (Pos. A)/Eutelsat (Pos. B) - Kathrein 90cm mit 2x Kathrein LNBs -> easyvdr01 mit zwei Sat-Karten.

2.) EXR904 - Turksat42E (nur Pos. A, da ein Anschluss an Pos. B gebrochen, s. Pic) - Grundig 60cm (ex. Astrasat aus dem EG, jetzt auf dem Dach) - DUR-Line Quattro_LNB -> easyvdr02 mit einer Sat-Karte.

Hmm, komisch, dann sollte aber Turksat ja auf Position A, also F0 bis F3 in der diseqc.conf sein:

S42E 11700 V 9750 t v W99 [E0 10 38 F0] W99 t
S42E 99999 V 10600 t v W99 [E0 10 38 F1] W99 T
S42E 11700 H 9750 t V W99 [E0 10 38 F2] W99 t
S42E 99999 H 10600 t V W99 [E0 10 38 F3] W99 T

Der ganze Rest mit S19.2E sollte dann auch aus der diseqc.conf raus (falls du ihn noch drin hast). Und in der channels.conf dann noch alle Vorkommen von "S42.0E" nach "S42E" abändern, dann ist das auch konsistent!

Das "DiSEqC = 1" in der setup.conf schaltet DiSEqC einfach ein, mit der Version von DiSEqC hat das nichts zu tun soweit ich weiß.

w_scan hat ein anderes Format für die Satelliten, das NICHT über die sources.conf gesteuert wird. Daher heißt es dort in der Tat "-s S42E0".

Zitat von Lindemann

Sach mal bitte, wo in welchem Menue finde ich das:

// Du schaust das VDR auf 'neuen Transponder/Kanal hinzufügen steht! //

Das kannst du auch in der setup.conf über "UpdateChannels = 5" setzen (siehe hier)

Ich muss gerade sagen, dass ich diese Aussage nicht ganz verstehe:

Zitat von Lindemann

Wobei ich anmelren muss, dass ich einen fuer Satra/Eutelsat (alle SatEinganeg sind belegt) und einen explizit fuer den Tuerksat habe.

Kannst du nochmal genau erklären, wie genau die 3 Satelliten (Astra, Eutelsat, Türksat) an den Multischalter anschlossen sind, wie das weiter zur Sat-Karte läuft bzw. wo da genau Türksat eingeschleußt wird.

Je nachdem ist dann nämlich evtl. doch "F8","F9", "FA", "FB" in der diseqc.conf bei den Turksat-Zeilen richtig, und bei dem w_scan müsstest du dann auch mal "-D2c" und "-D3c" ausprobieren, ob einer davon geht.

Und noch ne Edit (sorry): Gerade ausprobiert mit meinem Astra2-Setup. "-D1c" ist wohl die richtige Option für w_scan:

w_scan -fs -s S42E0 -D1c

Lindemann sorry ich musste meinen Beitrag oben wegen Typos und einer Ergänzung (in Fettschrift) ein paar Mal editieren. So sollte es jetzt passen.

Wenn du selber mit w_scan scannen willst (auch wenn der Autor hier berechtigterweise davon abrät, da das Tool halt EOS ist), beachte dass hier die diseqc.conf nicht genutzt wird. Es gibt ne Kommandozeilen-Option, um den Multischalter auf "Position B" zu schalten, ich glaube es sollte "-D1u" sein. Ohne den wird immer Position A (also Astra) gescannt, egal was du hinter "-s" angibst, so dass dir das nicht hilft.

Also probiere mal

w_scan -fs -s S42E0 -D1u
// falsch, muss -D1c am Ende sein!!!

Aber der Autor (wirbel) kann dazu sicher mehr sagen.

Also ich glaube nicht, dass die Sat-Karte grundsätzlich die Programme nicht empfangen kann, wenn der normale Receiver es wirklich problemlos (also nicht schon an der Empfangsgrenze mit häufigen Störungen oder so) hinkriegt.

Kurz gegoogled, der Kathrein EXR904 ist ein ganz normaler 9/4 Multischalter, der per DiSEqC gesteuert wird, und bei dem der erste Satellit (bei dir wohl Astra) auf Position A, Option A und der zweite (bei dir dann Türksat) auf Position B, Option A liegt. Daher müsste die diseqc.conf von VDR wie folgt aussehen:

S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 [E1 10 38 F0] W15 t
S19.2E  99999 V 10600  t v W15 [E0 10 38 F1] W15 [E1 10 38 F1] W15 T
S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 [E1 10 38 F2] W15 t
S19.2E  99999 H 10600  t V W15 [E0 10 38 F3] W15 [E1 10 38 F3] W15 T

S42.0E  11700 V  9750  t v W15 [E0 10 38 F4] W15 [E1 10 38 F4] W15 t
S42.0E  99999 V 10600  t v W15 [E0 10 38 F5] W15 [E1 10 38 F5] W15 T
S42.0E  11700 H  9750  t V W15 [E0 10 38 F6] W15 [E1 10 38 F6] W15 t
S42.0E  99999 H 10600  t V W15 [E0 10 38 F7] W15 [E1 10 38 F7] W15 T

Ob es bei den letzten 4 Zeilen "S42.0E" oder nur "S42E" heißen muss hängt davon ab, wie der Satellit in der Datei sources.conf benannt ist. In der channels.conf muss dann natürlich auch konsistent die richtige Schreibweise benutzt werden. Wichtig: Bei deiner zuvor geposteten diseqc.conf stimmen die letzten 4 Zeilen nicht, weil du nicht F4-F7 in den Schaltsequenzen, sondern F8-FB benutzt hast. Das ist aber für diese Art von Multischalter falsch, sondern wäre für nen sogenannten Optionsschalter.

Zusätzlich muss in setup.conf noch folgender Setting gesetzt sein:

DiSEqC = 1

Dann noch passende channels.conf (evtl. kannst du die von Channelpedia nehmen - allerdings weiß ich nicht wie aktuell die wirklich ist und hab selbst kein Türksat sondern Astra2 auf der zweiten DiSEqC-Postion; jedenfalls auch hier wieder auf das "S42.0E"- vs. "S42E"-Problem achten und schauen, dass du in allen Config-Datei mit dem Namen für den Satelliten konsistent bist) und es sollte eigentlich klappen.

Maybe you just want to create yourself an initial tuning file for dvbv5_scan like this:

# freq sr fec mod
[CHANNEL]
        DELIVERY_SYSTEM = DVBC/ANNEX_A
        FREQUENCY = 506000000
        SYMBOL_RATE = 6900000
        INNER_FEC = NONE
        MODULATION = QAM/256
        INVERSION = AUTO

[CHANNEL]
        DELIVERY_SYSTEM = DVBC/ANNEX_A
        FREQUENCY = 514000000
        SYMBOL_RATE = 6900000
        INNER_FEC = NONE
        MODULATION = QAM/256
        INVERSION = AUTO

I added the first two frequencies that you listed (506 and 514) with the symbol_rate and modulation_parameter that you listed and DVBC. Just add all the other frequencies in the same way and give it a try.

Zitat von Marx2

I have Samsung TV, and from what I can see, it scans channels on MUXes with frequencies: 506,514,522,530,538,546,554,562,570,578,586,594,602,610,618,626,634,642,650,658,666. Technician said it starts with 506000, and jumps by 8000, modulation 256QAM, 6900 transmission speed. In TV everything works.

Another idea: 6900 transmission speed (I guess "symbol rate" is meant) sounds like a typical DVB-C symbol rate. Are you sure that your TV is really receiving DVB-T and not actually DVB-C? That could well explain these inconsistencies.

Ich hab jetzt den letzten Stand (letzte Änderung war am 28.06.2020) von t2scan als Version 0.7 released. Das Release und die Release Notes findet ihr hier: https://github.com/mighty-p/t2scan/releases/tag/v0.7

Ich habe in nächster Zeit nicht vor, t2scan weiterzuentwickeln, daher kann es gut sein dass dies das letzte Release war (außer ich finde meine Motivation wieder...). Falls jemand das Projekt forken bzw. übernehmen und weiterführen will, gerne. Es ist ja auf github, also sollte das kein Problem sein. Da ich auch selbst VDR kaum mehr verwende sage ich hier erstmal Tschüß.

Das sind aber eigentlich Top-Werte, an der Ausrichtung wird es daher eher nicht liegen, würde ich sagen. Interessant wäre noch, wie die Werte aussehen, wenn der Fehler auftritt. Ich tippe aber auch auf ein Problem mit dem LNB, berichte ob das Austausch-LNB hilft.

Benutz mal "dvb-fe-tool -m" anstatt femon zum Messen der Signalstärke. Bei meiner DVBSky-Karte wird da das Signal-Rausch-Verhältnis in dB angezeigt. Das ist eigentlich recht brauchbar. Beim ZDF hab ich etwas über 13 dB S/R und das ist eigentlich schon "unteres Ende" (der Signalweg ist nicht ganz frei), reicht aber für störungsfreien Empfang .

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.

Zitat von frosch

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:

Zitat von HelmutB

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.