Posts by frr

    Daher dachte ich: OK, wenn's hier schief geht, breche ich halt ab. Werde dann also demnächst die beiden Zeilen in der GIT-Version so ändern, dass zwar noch ein Fehler ausgegeben wird, aber das Programm weiter läuft.

    Danke :) Scheint mir wie ein annehmbarer workaround.

    Die bisherige Motivation hinter dem Code ist mir natürlich klar, ich bin selbst auf diese Weise behutsam wann ich etwas gelegentlich schreibe...

    Ich habe diesen Fehler bei ioctl(FE_READ_STATUS) in linux-media kurz off-topic bemerkt, aber da kann ich auf keine schnelle Lösung hoffen, die Maintainers sind beschäftigt. Wenn ich das selbst lösen würde und als ein Patch übermitteln würde, hätte ich eine Chance.

    Der t2scan hat bei mir wirklich in aller Ordnung durchgelaufen und auf "stdout" habe ich endlich komplette Ergebnisse erhalten - vielleicht zum ersten Mal aus der "w_scan Familie" :) Ich verwende es jetzt als meinen channels.conf. Ich habe die Ergebnisse in meiner vorgangenen Nachricht nicht eingeschlossen, weil die Nachricht schon über 10k Buchstaben war (und das Forum hat darüber geklagt).

    mighty-p: danke für die sofortige Antwort :) das war ja unglaublich...

    Ja, nach der vorgeschlagenen Änderung arbeitet es ganz gut:

    Ohne weiterer Suche, denke ich daß der Fehler eigentlich von dem dvbsky Treiber zurückgekehrt wird, oder?

    mighty-p: danke für den t2scan :) es sollte manche grundsätzliche Probleme bei mir lösen.

    Ich habe die frische Version aus GIT kompiliert, gegen einem neuen 5.4.6 kernel.

    Ich habe 2 Stk. der Mygica "T230C v2" - frisch in 5.4 durch Treiber "dvbsky" unterstützt.

    Und, t2scan meldet einen Fehler schon im Anfang:

    Ich habe Ihren früheren Kommentar gelesen, daß "dieser Fehler in dem älteren w_scan ignoriert wurde". Das wahrscheinlich gilt noch. Trotzdem findet w_scan2 fast alle Kanäle. Also zum Vergleich:

    Ich habe alles aus Source Code übersetzt - ich wäre dankbar für jegliche Vorschläge, welche möglichen Änderungen zu testen.

    Das Country Code "CZ" macht keinen Unterschied, mit "DE" benehmen sich die beiden Programme ebenso.

    Frank

    Meine Herren,

    diese Nachricht schreibe ich eigentlich zu gestehen, daß ich gestern manche Zeit vergeudet habe, weil ich die Anleitung nicht gelesen habe. Meine Unvorsichtigkeit, RTFM :)

    Spoiler: siehe die Skizze im Anhang.

    Entschuldigung für den Betreff auf Englisch. Auf Deutsch würde ich es nicht so kompakt schaffen.

    In meinem HTPC mit der J4105-ITX hatte ich vor, die zwei T230C2 Dongles auf innen zu dem zweifachen USB 2.0 Header anzuschliessen. Und auch den zweifachen USB 3.0 Header habe ich für manche blauen vornen Buchsen des Gehäuses verwendet. Der restliche einfache USB 2.0 Header wird einer 2.4GHz drahtlosen Mini-Tastatur dienen (den mikro-Empfänger habe ich in dem Gehäuse versteckt).

    Also die zweien zweifachen headers wurden beiden besetzt, die Kabel angeschlossen, ich habe meine DVB Dongles eingeschoben, und... es gab nur USB Fehlermeldungen. USB 1.1 Geräte arbeiteten (Tastaturen und Mäuse) aber irgendwas mit USB 2.0 wurde sich nicht melden. Hmm warum denn... sind die USB-Kabel ungut?

    Ich arbeite in einem "Spielwarengeschäft" (PC Hardware) und die "breakout" USB Kabel sammeln sich überflüssig in unserem Elektro-Schrott (unverwendetes Zubehör). Mein USB 2.0 Kabel war dieser Art = etwas altes mit unklarem Stammbaum. Das USB 3.0 Kabel war aber etwas hoffentlich gutes von DeLock... Also zurück in die Werkstatt, und andere Kabel zu ausprobieren... Ich habe weitere vieren unterschiedlichen Kabel ausprobiert, bis ich bemerkt habe, daß die USB 2.0 Geräte plötzlich arbeiten. **Was?** Oh ja, ich habe ein Kabel abgetrennt. Mit beiden Kabel zu den Headern angeschlossen arbeitete es nicht. Mit nur einem Kabel, irgend einem, war es in Ordnung. Hmm die zweien Header sind ganz nah... wäre es möglich, daß die USB 2.0 Leiter parallel verdrahtet wären? Ein paar Messungen mit dem Multimeter... ja sicher!

    Oh ja. In dem Manual und auch in dem Quick Guide, habe ich endlich folgende Zeile gefunden: "USB3_0_1 is shared with USB_0_1" . Es ist aber nie bei der Skizzen der Headern bemerkt. Es befindet sich in der Stichpunkt-Liste der Eigenschaften.

    Ich habe endlich auch ausprobiert, die USB 2.0 Leitungen aus dem blauen USB 3.0 Kabel auszuschlachten. Danach arbeiten die USB 3.0 Ports von dem USB 2.0 Header unabhängig, man kann gleichzeitig 2.0 und 3.0 Geräte anschliessen. Selbst-verständlich sind die blauen 3.0 Buchsen danach für USB 1.1/2.0 unanwendbar. Als ein "Batterie-Ladegerät" arbeiten sie für Geräte, die auf den Daten-Leitern keine besondere Impedanz erwarten. Also wahrscheinlich Schade mit einem iPhone, aber die RII Mini-Tastatur ist damit ganz zufrieden :)

    dad401 danke für Ihre Gedanken und hilfreiche Vorschläge :) Leider habe ich gestern abend nicht geschafft, den aktuellen softhddevice-Plugin zu ausprobieren - nächste Chance heute Abend.

    Wie mehrere Leute mir hingewiesen haben, auf der Buffering in dem vaapidevice-Plugin wurde vor manchen Monaten etwas gearbeitet und manche Patches in dieser Richtung haben auch in dem dvbsky-Treiber passiert (meinen zweien USB Dongeln entsprechend - daher auch der 5.4.x Kernel).

    Streaming habe ich auch noch nicht ausprobiert - das muss noch warten. Es gibt mehrere Kleinigkeiten die ich noch lösen möchte - und ehrlich gesagt der Pixelsalat ist das kleinste Problem, das größtenteils beim Ende Januar verschwinden wird, weil es keine DVB-T Mehr geben wird :) Prag ist seit dem Ende Novembers schon an T2 umgeschaltet, hier im Norden erwarten wir das in ca drei Wochen. Die Frage sicher schwebt, ob ich den VDR (oder manchen anderen Player) mit meinen alten MPEG2 Aufnahmen künftig verwenden kann, und ob der Pixelsalat für andere "Playback-Weisen" auch gilt. Das muss ich noch alles ausprobieren.

    Zum Thema "Pixelsalat":

    Bei mir passiert es, wenn ich von einem "DVB-T MPEG2 SD" Kanal nach einen anderen "DVB-T MPEG2 SD" Kanal umschalte. Bei dem ersten mal, als ich etwas mit MPEG2 wähle, läuft das Bild ausgezeichnet - aber als ich danach direkt einen anderen MPEG2 Kanal wähle, kommt unbedingt der grüne Pixelsalat. Dieses Problem gibt es gar nicht bei den T2 Muxes (alle senden H.265 HEVC HD oder QHD) und auch kein Problem bei manchen DVB-T (nicht T2 !) Kanälen die in der H.264 Kodierung laufen. Und mein "Workaround im Testbetrieb" ist, zuerst nach einem H.264 oder H.265 Kanal umzuschalten, dann kann ich wieder etwas in MPEG2 wählen...

    Dies ist mein zweiter Versuch, den VDR in Betrieb zu nehmen :) In Mai hatte ich manchen Rechner mit Skylake, jetzt habe ich eine J4105-ITX von AsRock (= Gemini Lake ATOM). Der Pixelsalat passiert ebenso auf beiden Intel GPU's - die beiden VAAPI unterstützen. Hier in Tschechien kann ich vor meinem Ort ca 4 DVB-T Muxes und 2 DVB-T2 Muxes empfangen. Mein Ziel ist VAAPI auf der Gemini Lake Hardware zu benutzen, und VDR gefällt mir - darum versuche ich mit dem vdr-plugin-vaapidevice zu arbeiten...

    Meine SW Versionen: VAAPI frisch aus dem GIT (ca 2 Wochen alt), FFMPEG/libva 4.2.1-release (4.2.2 ist ca 2 Tage alt - habe ich nicht getestet), VDR 4.2.1-release, vdr-plugin-vaapidevice aus dem Git von Rofafor (vor 2 Wochen), Debian 10, kernel 5.4.6