Posts by Dr. Seltsam

    Ich will mich hier nicht über die Studio Levels auslassen, aber die gibt es im TV Content nicht und wenn man sie nutzt dann wird der Dynamic Bereich des Bildes nur verzerrt.

    Einspruch.


    Studio levels entspricht dem Farbraum 16-255 ("limited RGB") und das ist für TV Standard. Solange man das Gerät an einem TV anschließt, sollte Studio Levels immer aktiviert werden und es ist mir ein Rätsel, warum das in softhdcuvid und softhddevice nicht standardmäßig auf 1 gesetzt wird. Die wenigsten werden ihren VDR an einem Computermonitor betreiben.


    Ohne Studio Levels wird 0-255 = Full RGB übertragen. Damit es zu keiner Fehlkonfiguration kommt, muss dann aber auch der TV auf Full Range konfiguriert werden, und das ist zumindest für die HDMI-Eingänge normalerweise nicht die Standardkonfiguration.

    Die Grafikkarteneinstellung sollte, so wie ich https://kodi.wiki/view/Video_levels_and_color_space verstanden habe, hingegen immer auf Full Range stehen.

    Ist denn nur das Bild von softhddevice zu dunkel, oder merkt man das auch bei z.B. Kodi oder vlc?

    Bringt die Grafikkarte ein gutes Bild, wenn ein normaler Linux Desktop gebootet wird, z.B. ein Ubuntu-iso?

    Ich überlege, mir ein digitales Mikroskop anzuschaffen. Es sollte nicht nur unter Linux laufen, sondern auch mit dem ipad koppelbar sein - daher scheiden reine USB-Mikroskope wahrscheinlich aus und es muss wohl auch Wifi haben. Hat jemand vielleicht eine Empfehlung? Es gibt solche Teile in der Preisklasse um 50,- Euro, aber wenn man sich die Bewertungen genauer anschaut, vergeht einem die Laune.

    rell: Du kannst Dir ja mal anschauen, wie jojo61 es in softhdodroid gelöst hat. Die entscheidende Stelle ist m.E. in video.c in der Funktion CodecVideoDecode. Wenn es sich um einen Rückwärts-Trickspeed handelt oder um die Stufen 1, 3 oder 6 (=Spulen, keine Zeitlupe) wird ein reset des Decoders mit Leerung der Buffer ausgeführt. Es findet zudem mittels usleep eine kleine Verzögerung statt, deren Dauer von der Art des Trickmodus abhängig ist. Und irgendwas wird da auch mit der PTS gemacht.


    Was mich interessieren würde: Wie gut funktioniert denn bei Euch die aus der Pause heraus aufgerufene Zeitlupe vorwärts und hier insbesondere der Wechsel zurück auf Normalgeschwindigkeit? Hier haben wir uns bislang die Zähne ausgebissen. Es kommt dabei zu Bildsprüngen, weil eine A/V Asynchronität aufgeholt werden muss, die u.a. dadurch entsteht, dass ab Wechsel zu Pause die Audiopakete verworfen werden und der Audio-Buffer gecleart wird. Von vdr kommt an dieser Stelle aber kein Clear. Ich habe versucht, das ähnlich wie beim Spulen mit einem reset des Videodecoders zu lösen, aber es kam nichts brauchbares dabei raus.


    Mir ist klar, dass softhdodroid mit seinen amlogic-spezifischen ioctl ganz anders funktioniert, aber vielleicht kannst Du ja trotzdem die eine oder andere Anregung mitnehmen. Generell ist zu sagen, dass Rückwärtsspulen bei h264 Glückssache ist. Es gibt immer wieder Aufnahmen, bei denen das trotzdem nicht funktioniert. Das ist bei softhddevice so, das ist bei softhdodroid so und scheint senderunabhängig zu sein. Wahrscheinlich heißt es deswegen Trickspeed - weil es so tricky ist :lachen3

    Ich packe das image auf eine SD und mache eine Neuinstallation. Aktiviere dabei SSH, lege ein Passwort fest und mache die Konfigurationen, die das CE-setup abfragt. Erstes Login schlägt bereits fehl und wird auch nach reboots nicht besser.

    Gleiche Vorgehensweise bei images von der CE-Seite oder selbst gebauten VDRCoreElec-images funktioniert fehlerfrei.

    Die Variante CE image installieren und dann die tar Datei von Zabrimus in den .update Ordner legen habe ich noch nicht probiert. Teste ich bei nächster Gelegenheit.

    probiere doch bitte meinen Vorschlag aus # 3!

    Code
    ZDF HD;ZDFvision:338000:C0M256:C:6900:6110=27:0;6120=deu@106,6121=mis@106,6123=mul@106:6130;6131=deu:0:11110:1:1079:0

    und bedenke bitte, dass vdr vorher beendet werden muss, wenn Du die channels.conf manuell editierst.

    wahrscheinlich reicht es, bei der ersten Zeile den Wert 102 durch 1 zu ersetzen. Das ist der drittletzte Wert und müsste die NID sein.

    Aber wie Stefan schon richtig sagte, sollte vdr in der Lage sein, das automatisch zu korrigieren. Dazu müsste unter DVB - Kanäle aktualisieren sogar die Option "Namen und PIDs" reichen.

    Mich verfolgt dieser ssh-Fehler sehr hartnäckig weiter mit images aus dem Zabrimus-git, zuletzt VDR-CoreELEC-Amlogic-ng.arm-21.1.1-Omega-2024-10-05.1-Generic vom 05.10.24.

    Die images von CoreElec und auch ein selbstgebautes VDRCoreElec image vom 27.08.24 zeigen diesen Fehler hingegen nicht.

    Es liegt auch definitiv nicht am Client, denn auch meine Apps auf dem ipad kriegen keine Verbindung zum ssh-Server.


    Bin ich denn wirklich der einzige mit diesem Problem?

    Laut Readme soll ein make install reichen, um Plugin und libskindesignerapi.so zu bauen:


    Quote

    Skindesigner consists of the Skindesigner Plugin itself and a shared library called "libSkindesignerAPI" which allows other Plugins to use the facilities of Skindesigner. Since these other Plugins need to have access to the library, the library has to be proper installed on your system. With a "make install" both the plugin and the library are installed on your system. The destination where the library will be installed can be set with the PREFIX parameter: "PREFIX=/usr make install". Default of PREFIX is /usr/local.

    Ich kriege aber

    Code
    make install
    Failed to open 'libskindesignerapi/libskindesignerapi.pc': No such file or directory
    No package 'libskindesignerapi/libskindesignerapi.pc' found

    Danach baut das Plugin dennoch (??), bringt aber am Ende einen Fehler:

    Code
    /usr/bin/ld: libskindesignerapi/libskindesignerapi.so. kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden
    collect2: error: ld returned 1 exit status
    make: *** [Makefile:187: libvdr-skindesigner.so] Fehler 1

    Im Unterordner libskindesignerapi ist nichts gebaut worden.


    Ich habe dann statt make install (was ich aus Bequemlichkeit auf einem System,wo alles als root läuft, immer mache) nochmal nur ein make gemacht, und nun wird auch zuerst die libskindesignerapi gebaut. Das anschließende make install liefert dann keinen Fehler mehr.


    Falls das Bauen der ibskindesignerapi nicht auch bei einem make install möglich ist, wäre mein Vorschlag, das Readme einfach anzupassen

    wenn Ihr sicher gehen wollt, dass es an der Hardware und nicht an schlechten Treibern liegt, könnt Ihr versuchsweise ein Ubuntu mit Kernel 6.6 https://forum.odroid.com/viewtopic.php?f=177&t=48620 installieren. Darauf wird weder Kodi noch softhdodroid laufen, weil amlogic-spezifische Treiber fehlen. Wenn die USB3-Performance damit aber besser ist, müsste man im nächsten Schritt schauen, welche Patches es seit Kernel 4.9 bzw. 5.15 am xhci-hcd gegeben hat.

    Ich denke das sind unterschiedliche Probleme. Ein paar Fehler in den Aufnahmen sind oft nicht vermeidbar, insbesondere bei DVB-T2, wo der Empfang von der Witterung abhängig ist. Bei mir sind die Empfangsdaten super, nur kommen offenbar keine Streamdaten mehr an. Wobei ich mir jetzt nicht sicher bin, woher femon diese Daten bezieht - vom vdr oder vom Ausgabeplugin?

    Ich hatte den gleichen Fehler auch schon mit softhddevice auf PC-Hardware, so dass ich nicht denke, dass es am Ausgabeplugin softhdodroid liegt. Solange überhaupt kein Fehler geloggt wird, ist das schwer zu debuggen.

    Grundsätzlich läuft die dualHD super, aber ab und an scheint einer der beiden Tuner seinen Betrieb einzustellen. Das äußert sich so, dass man einen Kanal anwählt und das Bild bleibt schwarz. Femon zeigt, dass STR/SNR und BER top sind. Geht man auf die Streaminformationen, sieht man dass keine Infos verfügbar sind. Es ist, als wenn der Tuner bzw. Das DVR-device keine TS-Daten liefert. Man kann mit femon manuell auf den zweiten Tuner umschalten und kriegt ein Bild.

    Wenn man Pech hat und vdr das nicht funktionierende device für Aufnahmen verwenden will, scheitern die mit 0kB großen Dateien. Es empfiehlt sich deshalb, den Notausstieg zu aktivieren. Nach einem vdr-Neustart (wobei m.E. auch die Treiber entladen und neugeladen werden) funktionieren beide devices wieder. Ich habe das schon auf verschiedenen VDRs gelegentlich beobachtet, ohne dass es je Fehlermeldungen im Log gab. Hat das noch wer beobachtet?


    Das hat jetzt nichts mit dem bulk/isoc-Problem zu tun, aber ich erhoffe mir, in diesem Thread möglichst viele Benutzer einer dualHD zu erreichen.

    Ich verstehe das Problem nicht. Auf welchem Sender man die Timer anlegt, hat man doch selbst in der Hand. Und warum sollte man sich auf einem System, das HD-tauglich ist, ausgerechnet bei Aufnahmen auf SD kastrieren? Wenn es ein Platzproblem ist, kauft man eine größere Platte…

    Kann mir nur vorstellen, dass die Chips in den SATA-USB-Konvertern unterschiedlich gut unterstützt werden. Ich verwende ein günstiges Gehäuse und eine ausrangierte 500GB-SSD von Samsung aus der EVO-Reihe, die ext4-formatiert ist.

    Code
    CoreELEC:~ # hdparm -t /dev/sda1
    
    /dev/sda1:
     Timing buffered disk reads: 916 MB in  3.00 seconds = 305.28 MB/sec

    Kernel ist 4.9.269