Beiträge von mighty-p

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.

Nochmal GTC und HelmutB nach meinem Dafürhalten müssten die so eingescannten Programme eigentlich auch laufen ohne den VDR zu patchen, wenn man die automatische Kanalaktualisierung ausschaltet (Einstellungen > DVB > Kanäle aktualisieren = nein).

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.

Na ja, das mag aber vielleicht auch an der genauen Hard- und Softwarekombination liegen. Bei mir gibt es keine Probleme mit der Audio/Video-Synchronisierung beim vaapidevice.

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

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

ändert in

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.

Zitat von M-Reimer

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:

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.

Ich dachte, es ist mal wieder Zeit für ein neues Release und da in letzter Zeit auch keine (ungelösten) Probleme mit dem aktuellen GIT-Stand gemeldet wurden, habe ich selbigen jetzt als Version 0.4 released: https://github.com/mighty-p/t2scan/releases

Nochmal danke, localhosthack0r. Die Frage ist halt, ob vdr überhaupt in der Lage ist, solche Internetkanäle abzuspielen.

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...).

Das müssten wirbel bzw. die Paket maintainer entscheiden. Hier ist der entsprechende Commit:

https://github.com/mighty-p/t2…34ef1dce802801e3caab8bf8f

Hast du mal irgendwelche DVB-Treiber manuell installiert (also z.B. den media_build oder irgendwelche proprietäre Treiber direkt vom Kartenhersteller) und dann wieder ein Kernel-Paket der Distribution installiert? Ich kann mir nämlich eigentlich nicht vorstellen, dass eine Distribution mit einem so kaputten Kernel daher kommt. wirbel hat Recht, dass man das aufräumen sollte/muss. Order du kannst mal versuchen, besagten media_build einfach drüber zu installieren (ist evtl. Pfusch, aber vielleicht klappt es auch).

Ich hab die Version 2.4 seit heute auch am Laufen. Vielen Dank an kls und alle Beteiligten! Bin auch bereits seit 2004 dabei und auch heute ist VDR noch immer die beste Software zum Fernsehen auf meinem PC

Neue Version 0.3 ist soeben released worden. Enthält die Markierung von doppelten Multiplexen und Services (Parameter "-d"), automatisches Entfernen solcher Duplikate (Expertenoption "-D"), sowie den Fix für das Problem dass im VDR>=2.1-Format bei manchem Services die Audio-PID fehlte (das war ein "alter" Bug noch aus w_scan).

Da mir keine wirklichen Probleme mit den letzten Git-Ständen berichtet wurden, habe ich nun t2scan 0.2 released (https://github.com/mighty-p/t2scan/releases). Vielen Dank an alle, die getestet und mir im Thread oder per Direktnachricht Rückmeldung gegeben haben!

Ein Problem von t2scan derzeit ist, dass bei mehrfachem Empfang eines Programmes dieses dann auch doppelt (oder ggfs. noch öfters) in der ausgegebenen channels.conf steht. Der optionale Schalter "-d" kann zwar helfen, aber hier will ich in Zukunft etwas Besseres bauen und idealerweise das ioctl der DVB API nutzen, um das Programm nur vom am besten zu empfangenden Kanal zu nehmen. Entsprechende Änderungen werdet ihr bald im GIT sehen. Kann durchaus sein, dass v.a. der Schalter "-d" dann bei euch gar nicht geht oder instabil läuft. Das nur zur Info

localhosthack0r , danke für's Testen. In t2scan.log.txt sieht es in der Tat so aus, als hätte die Karte ab 634000 kHz bei DVB-T2 gar keinen Lock mehr gekriegt, warum auch immer. Ich denke aber eher nicht, dass das am t2scan-Code liegt, zumal du ja sagst, dass es nach einem Neustart der Treiber dann geklappt hat.

Im Prinzip sollte es kein Problem sein, eine ältere ffmpeg-Version selbst zu kompilieren und nach /opt zu installieren. Dann halt PKG_CONFIG_PATH und LD_LIBRARY_PATH für vdr entsprechend setzen. Ich hab das bei mir im Prinzip so laufen, nur dass ich halte eine neuere ffmpeg-Version als die bei Mint mitgelieferte benutze für vdr.