Posts by mighty-p

    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.

    GTC Danke für den Patch. Der Code, den du gefixt hast, kommt noch vom guten alten w_scan. Ich werde den Patch ausprobieren und testen (v.a. ob er nicht die Scan-Geschwindigkeit negativ beeinflusst). Vermutlich werde ich aber erst am Wochenende dazu kommen. Wenn's gut läuft, kommt er dann ins GIT.


    HelmutB Ist das überall in Österreich so, dass man "-p 1" benutzen muss? Dann könnte ich das nämlich zum Default machen, wenn t2scan auf einem System mit österreichischen Settings läuft.

    Also den Effekt, dass sich VDR mit vaapidevice beendet, wenn es kein Profil "VAProfileNone" mit EntryPoint "VAEntrypointVideoProc" gibt, kann man verhindern, indem man in der video.c vom vaapidevice-Plugin die Zeile 2654 von

    Code
    1. Fatal("video/vaapi: can't create config '%s'", vaErrorStr(status));

    ändert in

    Code
    1. Error("video/vaapi: can't create config '%s'", vaErrorStr(status));

    Dann müsste es jedenfalls ein Bild geben. In wieweit das Bild (vor allem bei interlaced und fehlendem De-Interlacer) qualitativ akzeptabel ist, muss man dann sehen.


    Die andere Frage ist: Warum fehlt hier überhaupt der VAEntrypointVideoProc? Der Haswell müsste das doch eigentlich haben, oder doch nicht?

    Also es wird dran liegen, dass es bei dir das "VAProfileNone" nicht gibt, warum auch immer das so ist. Ich habe bei mir nämlich die video.c so gepatched, dass er immer den Pfad läuft, als wäre dieses Profil nicht da, und dann kommt es zu genau dem von dir beschriebenen Verhalten, dass sich vdr beendet. Ich denke, das ist ein Bug und schaue mir das gerade etwas genauer an.

    M-Reimer wrote:

    Ein zentrales, großes, modulares Projekt allgemein für "Ausgabe über Grafikkarte" wäre sinnvoll gewesen. Schon weil z.B. die Tonausgabe ja über alle möglichen Optionen immer gleich ist. Wenn man Audio auch "modular" hätte, könnte man da auch mal direkte pulseaudio-Ausgabe reinbauen...


    [...]

    Kodi bekommt mit Version 18 sogar Amazon Prime und Netflix (natürlich inklusive DRM). Wenn man einen reinen Receiver will, dann ist VDR nach wie vor gut.


    Ich frage mich auch immer mehr, ob das ganze Gewurschtel mit verschiedenen Forks von softhddevice, die zwar alle mehr oder weniger funktionieren, aber bei denen man nicht mehr durchsteigt und die alle das Problem haben von nur sehr wenigen (oft nur einem?) Entwickler abhängig zu sein, noch Sinn macht.


    Vielleicht ist es an der Zeit, vdr einfach als Server zu sehen (vielleicht ihn in Zukuft sogar irgendwann dazu "zurückzubauen") und auf Kodi als Frontend zu setzen. Ich schrecke davor immer noch ein bisschen zurück, da ich Kodi als überladen empfinde. Andererseits muss man sagen, dass Kodi konstant weiterentwickelt wird und alle Grafikkarten und zugehörigen APIs wirklich optimal (im Sinne von: so optimal wie es hard- und softwaremäßig unter Linux geht) unterstützt.

    Mir ist noch etwas eingefallen, was du testen könntest. Interessant wäre zu wissen, ob den vaapi noch mit anderen Programmen funktioniert. Gut zum Test eignet sich der Video Player "mpv", da er vaapi exzellent unterstützt. Daher wäre es interessant, ob (bei installiertem mpv) folgendes Kommando ein Video korrekt abspielt:

    Code
    1. mpv --hwdec=vaapi --vo=opengl /path/to/my/video.mpg

    Also ich wundere mich in der Ausgabe von vainfo über das fehlende VAProfileNone. Das braucht man nämlich für das VAAPI-Postprocessing. Ich gehe mal davon aus, dass daher auch diese Meldung "can't query entrypoints: the requested VAProfile is not supported" her rührt.


    Du könntest mal versuchen, ob du ein Bild kriegst, wenn du in den Plugin-Einstellungen alle Postprocessing-Filter ausschaltest (Color Balance aus, Skin Tone Enhancement 0 [oder 50, bin nicht sicher], für alle Auflösungen Deinterlace aus, Denoise und Schärfen 0 [oder 50, bin nicht sicher]). Evtl. fordert vaapi dann das VAProfileNone nicht an. Aber ich bin mir da nicht sicher (muss gleich mal im Source-Code gucken) und außerdem wäre das Bild sicher deutlich schlechter als gewohnt.


    Die eigentliche Frage ist halt: Warum fehlt das VAProfileNone hier? Kann die Karte eventuell wirklich kein Postprocessing weil sie zu alt ist?


    [Edit]: Kurz mal in den Source-Code vom vaapidevice geschaut (video.c): Eigentlich sollte bei nicht vorhandenem Postprocessing auf der Hardware einfach das Postprocessing ausgeschaltet und das Bild halt unprocessed angezeigt werden. Ich habe bei mir mal einfach in der video.c die Variable VaapiVideoProcessing hart auf 0 gesetzt und kriege immer noch ein Bild.

    Andere Frage: Um welche Empfangsart geht es und ist es SD oder HD? Davon hängt nämlich auch der Codec ab.

    localhosthack0r Danke für's Log. Das -F erhöht eigentlich nur den Timeout beim Auslesen der Kanalinfos. Es kann natürlich sein, dass ohne -F der Default Timeout hier wirklich zu kurz ist, daher nicht alles gelesen ist (es sind ja recht viele Programme da auf einem Kanal) und daher die Programme nicht in der Kanalliste landen. Kann VDR denn die connect Kanäle bei dir abspielen?
    Was mich auch noch wundert ist, dass auf 498000 auch Programme gefunden werden (Pro Sieben HD usw). Die sollten eigentlich nicht auf PLP 1 liegen.

    Ich habe gerade mal eine Änderung ins GIT übernommen, um mit dem Parameter "-p" die PLP ID für DVB-T2 setzen zu können. Damit kann man jetzt z. B. auch die "connect"-Kanäle bei DVB-T2 finden (PLP 1 auf dem ZDF-Kanal) sowie ein zusätzlichen Standbild/Info-Kanal (PLP 1 im dritten freenet-Mux).


    t2scan -t2 -p1 -F


    Das "-F" braucht man eigentlich nicht, aber meine DVB-T2-Karte scheint Probleme zu haben, auf der zweiten PLP im ZDF-Kanal (wo die "connect"-Sender zu finden sind) sauber zu tunen.


    Mich würde interessieren, ob bei euch mit dem o.g. Befehl die "connect"-Kanäle gefunden werden und ob "-F" bei euch auch nötig ist. Bei mir braucht es manchmal auch trotz des "-F" mehrere Versuche (falls das passiert, kann man mit "-l<kanalnummer>" ja auf den ZDF-Kanal einschränken, damit nicht alle Kanäle immer durchgelaufen werden müssen).


    Außerdem würde ich mich interessieren, ob VDR die "connect"-Kanäle überhaupt abspielen kann!? Bei mir scheint es nicht zu klappen, evtl. liegt das aber man Tuning-Problem meiner Karte. Der zusätzliche Standbild-Kanal dagegen wird bei mir abgespielt, wenn auch manchmal mit Unterbrechungen (auch da geht wohl der Lock verloren...).