Posts by biggsmann

    Quote

    Warum bleibst du nicht bei Armbian als Unterbau, wenn du Kernel etc. eh selber baust? Ist ja auch nur gepimptes Debian

    Weil ich nur ein grünes oder rosa Bild erhalten habe. Ich vermute mal, dass es mit den von Dir verlinkten Patches läuft - muss ich mich morgen dran machen, gleich ist Fußball...

    Danke für die Unterstützung.


    cu

    biggsmann

    Da ich keinen neuen Thread aufmachen will: Gehen auch so uralt-Teile mit sun7i-Architektur (Cubietruck)? Ich habe mich die letzten zwei Tage aus Langeweile durch die Anleitungen durchgequält in der Hoffnung, (m)einen Raspi3 für andere Aufgaben freistellen zu können. Läuft auch alles, nur das Bild ist komplett grün- oder rosaverpixelt. Klar ist, dass H265 und Hardware-OSD nicht gehen.

    Habe ich eine Chance?


    Danke und Gruß

    biggsmann

    Da sage ich erstmal Danke. Mit den schlanken Vorgaben von Rell meckert meson nicht mehr. Zur Zeit compiliert er - wenn ich weiter bin (oder auch nicht) melde ich mich.


    cu

    biggsmann

    Hallo in die Runde,


    ich versuche mich gerade am Mesa-Compilieren.


    Wenn ich das über

    Code
    1. meson configure build/ -Dplatforms= -Dglvnd=false -Dllvm=disabled -Dlmsensors=disabled -Dlibunwind=disabled -Dgallium-nine=false -Dgallium-va=disabled -Dgallium-vdpau=disabled -Dgallium-xa=disabled -Dgallium-xvmc=disabled -Dgallium-opencl=disabled -Dbuild-tests=false -Dglx=disabled -Dshared-glapi=enabled -Ddri3=disabled -Degl=enabled -Dgbm=enabled -Dgles1=false -Dgles2=true -Dselinux=false -Dzstd=disabled -Dvalgrind=false -Ddri-drivers= -Dgallium-drivers=kmsro,panfrost -Dvulkan-drivers= -Dvulkan-device-select-layer=false -Dvulkan-overlay-layer=false

    probiere (sind die Optionen von zillerbaer auf Seite 8 in diesem Thread) kriege ich ein

    Code
    1. Value "disabled" for combo option is not one of the choices. Possible choices are: "auto", "true", "false".

    Kann mir jemand auf die Sprünge helfen, wo ich "disabled" und wo "false" einsetzen muss?


    Danke und Gruß

    biggsmann

    Hallo jojo 61,


    den 396.24 habe ich jetzt auch (vorher .37 wenn ich nicht irre). Leider keine Änderung. In meiner Verzweiflung habe ich ffmeg mal ohne den Patch übersetzt, ändert leider nichts am Problem. Gibt es irgendwo noch eine Einstellung zum Deinterlacing? Hintergrund meiner Frage ist, dass der Astra-Demo-Kanal sich aller paar Sekunden "fängt", dann ein paar Sekunden vernünftig läuft und dann wieder diese komischen Ruckler produziert. In Log erscheint dann

    Sep 7 17:12:18 uvid vdr: get uniform colormatrix 1

    Sep 7 17:12:18 uvid vdr: get uniform colormatrix_c 2 -0,915688


    Hilft das?


    cu

    biggsmann

    Quote

    Wenn UHD ruckelt liegt das sicher nicht an der HDMI anbindung, Schau mal mit top welche Last am Rechner ist. Wenn die GrKa mit einem Mining Modul angebunden ist dann ist da auch nur ein PCIe Kanal aktiv. Das ist zu wenig für UHD. Da brauchst du schon 4 Kanäle und volle PCIe Bandbreite.

    Hallo Jojo,


    das Mininig-Modul ist rausgeflogen und die Karte steckt in enem x16-Slot. Die Prozessorlast liegt bei ~5-20% pro Kern. Kann es sein, dass ein Athlon64 6000+ mit zwei Kernen trotz Hardware-Beschleunigung nicht reicht?


    Cu

    biggsmann

    Bin jetzt einen großen Schritt mit der Installation weiter. Ursache für das Geruckel war nicht der fehlende ffmpeg-Patch sondern die Anbindung der GraKa über ein Mining-Modul. Mit HD über vdpau hat das gut funktioniert, jetzt muss ich für meinen Bastelrechner eine andere Lösung suchen.

    Stand ist, das SD und HD über Sat sowie HD über DVB-T2 laufen.

    UHD liefert ein zwiespältiges Bild: Fashion 4k und der Astra-Demo-Channel laufen, Travelxp 4k der UHD1 ruckeln sich einen zurecht.

    Liegt das an der Anbindung über HDMI (was ich vermute, obwohl der XServer nur auf 1920x1080@50.00 läuft ) und welchen Adapter könnt Ihr empfehlen, um den DP meiner Karte zu nutzen?


    Danke und cu

    biggsmann

    Hallo zusammen,


    habe mittlerweile mein Ubuntu komplett neu aufgesetzt und kriege mittlerweile ein Bild. Aber: Es ruckelt eigenartig hin und her (als ob Bildbestandteile verkehrt herum zusammen gesetzt werden) und der X-Server hängt sich regelmäßig auf. Die Systemlast sollte es nicht sein, laut htop liegt die Last bei DVB-T2 unter 10% auf beiden Kernen.


    Damit ich nicht unnötig Blindlast erzeuge:

    Im Thread wird immer mindestens eine 1030-er vorausgesetzt. Ich meine aber, dass meine GTX 950 auch laufen sollte?

    Hollywood : Kannst Du Dein Makefile zur Verfügung stellen? Ich habe es selber versucht, kann aber mangels Wissen verschiedene Einträge nicht deuten (bzw. korrigieren).


    Danke für die bisherige Unterstützung!


    cu

    biggsmann

    Hallo jojo,


    /usr/lib64 existiert bei mir nicht (Ubuntu 18.04, 64-bit). Die lib-Dateien liegen unter /usr/lib/x86_64-linux-gnu.

    Die libav* liegen unter /usr/local/lib.

    Ich vermute mal, dass ich alle Verzeichnisse anpassen muss?


    Gruß

    biggsmann

    Hallo Joachim,


    sieht bei mir ähnlich aus, wobei es meine bescheidenen Fähigkeiten übersteigt, auch nur ansatzweise eine Ursache zu finden:

    Code
    1. cc -g -O3 -Wall -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/alsa -I/usr/include/libdrm -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/cuda/include -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DCUVID -DHAVE_GL -DAV_INFO -DAV_INFO_TIME=3000 -DUSE_PIP -DUSE_MPEG_COMPLETE-DH264_EOS_TRICKSPEED -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU -DUSE_VAAPI -DUSE_GLX -DUSE_SWRESAMPLE -DGIT_REV='"d6d2674"' -g -W -Wextra -Winit-self -Wdeclaration-after-statement -c -o softhddev.o softhddev.c

    Gibt es eine Einstellung, dass der Compiler bei allen fehlenden includes abbricht?


    Gruß

    biggsmann

    Hallo Joachim,


    Code
    1. root@Nvidia:/usr/local/lib/vdr# ldd libvdr-softhdcuvid.so.2.4.0
    2. linux-vdso.so.1 (0x00007ffd73ccb000)
    3. libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f82f6528000)
    4. libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f82f618a000)
    5. libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f82f5f72000)
    6. libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f82f5b81000)
    7. /lib64/ld-linux-x86-64.so.2 (0x00007f82f6afa000)

    das sieht tatsächlich dünn aus. Ich habe die Quellen nochmal neu geladen und das Makefile mit dem Patch von U. Eckhardt gepatcht. Der Fehler ist

    Code
    1. vdr: /usr/local/lib/vdr/libvdr-softhdcuvid.so.2.4.0: undefined symbol: __glewGetUniformLocation

    gleichgeblieben.


    Was muss ich den ändern, um korrekt zu linken?


    Danke und Gruß


    biggsmann

    Danke, dann stehe ich aber komplett im Wald. Habe jetzt im Makefile alles mögliche angepasst, compiliert wird immer, die Fehlermeldungen sind wie oben geschrieben (mit und ohne -DUSESCREENSAVER). Vielleicht setze ich die Tage komplett neu auf und kann damit ausschließen, dass das System vermüllt ist.


    Gruß und bis bald ;-)

    Quote

    Da fehlt dann wohl die glew Library. Leider merkt der Linker das nicht was fehlt beim bauen einer Lib. Das merkt man erst beim starten.

    Eben nicht, Das hat er beim compilieren richtig erkannt, dass die fehlt.

    Hallo jojo61,

    wenn ich -DUSE_SCREENSAVER auskommentiere baut es, bringt aber vdr: /usr/local/lib/vdr/libvdr-softhdcuvid.so.2.4.0: undefined symbol: __glewGetUniformLocation


    Die Änderungen von jsffm bringen ebenfalls keine Besserung.


    Noch eine Idee?


    Gruß

    biggsmann