Posts by ciax

    Wollte gerade auf "vdr-plugin-softhddevice-cuvid" wechseln, plugin installiert - hatte genau die gleiche Versionsnummer wie "vdr-plugin-softhddevice":


    Code
    1. ii vdr-plugin-softhddevice-cuvid 1.0.7+git20201108-3-003e956-0yavdr1~focal amd64 Plugin for VDR. A software and GPU emulated HD device


    Auch wenn ich mit den Paramtern

    Code
    1. [softhddevice]
    2. -D
    3. -w alsa-driver-broken
    4. -w also-no-close-open
    5. -v cuvid


    starte, kommt im Log, daß vdpau aktiviert sei ... ?


    Keine Spur von "cuvid" im Log? Hmm.


    Grusz!

    .. aus dem Thread zu den Problemen mit dem softhddevice plugin (vdpau/also - "vdr hängt") kommend, bleiben hier folgende Logeinträge bzgl. SAT>IP und - gerade bemerkt - 2 defekten Sektoren auf einer Intel 600GB SSD (eventuell macht das die timeouts aus? davie2000 der Hinweis mit der "Schlafen legenden USB-Disk" machte mich darauf aufmerksam, obwohl ich nicht denke, daß die Platte sich schlafen legt - es werden ständig logs geschrieben, Kanäle aktualisiert, usw. - ein Problem mit der Platte :wacko:?


    Hier ein auf die schlimmsten Einträge gefilterter Output des journalctl vom heutigen Tag - sieht gar nicht so gut aus:


    Grusz!

    .. kurzes Feedback - seit ca. einem Tag mit dem unter Focal gelieferten nvidia-Treiber kam der Fehler (vdpau aktiviert) mit den massiven alsa-Einträgen (audio/alsa: start delay 336ms) im Log nicht mehr. Nur beim Kanalwechsel, wo die Einträge dann eh vorgesehen sind. Bin mir aber nicht sicher, ob schon 'Vorfreude' aufkommen darf :schiel


    Die anderen Fehler im Log bleiben (SATIP timeout, etc) und sollte ich besser in dem von mir eröffneten Fred ansprechen.


    Grusz!

    [..]Hoffentlich zerschieße ich mir nicht schon wieder alles :monster2.[..]

    so .. nun sieht die installierte nvidia-Paketliste etwas dezimiert aus - nach ppa-purge (inkl. dort vorgeschlagenem Lösungsweg), danach apt update + distupgrade.

    Der unter Focal mitgelieferte Treiber (nvidia-driver-450) wird nicht automatisch installiert - bin schon drüber gestolpert (ab hier [ansible] .. Grundsätzliches, X-Server, Lirc, etc)


    Es läuft jetzt mit dem bei Focal mitgelieferten Treiber .. noch via vdpau. Vorerst sieht es im Log ruhig aus.


    :tup für den Tip mit den "originalen-nvidia" Treibern


    Grusz!


    PS: zusätzlich habe ich noch "hpet=disable" unter grub gesetzt, da gab es auch immer wieder Logeinträge ("kernel: hpet: Lost 7161 RTC interrupts.")

    .. also einfach das "Graphics Drivers PPA" 'ppapurgen' und 'apt-get update+dist-upgrade'. Hoffentlich zerschieße ich mir nicht schon wieder alles :monster2. Hier steckt auch eine nvidia 1030 in der Box - meine Sig. passt noch.


    Ich probiere es aus! :tup .. auch das softhd-cuvid plugin.


    Danke für deine Config!

    Grusz


    PS: MarkusE deinen Fred wollte ich nicht hijacken, aber eventuell bestehen Analogien zu deinem Problem.

    Vielleicht wäre es einen Versuch wert, einen anderen nvidia Treiber zu probieren, und zu sehen was dann passiert?

    Ich baue das ansible system schon seit Mitte 2019 langsam (da nur sporadisch Zeit vorhanden) auf. nvidia Treiber bezieht das System aus dem "Graphics drivers PPA". Derzeit ist der Treiber in der aktuellsten Version 455.38 installiert. Seit 2019 gab es mehrere Updates, das Problem bestand aber immer schon. Welcher "alte" Treiber wäre denn zu empfehlen? Es sollten natürlich keine Abhängigkeiten zu anderen Paketen entstehen, die unter focal gar nicht mehr verfügbar sind.


    Danke für den Hinweis!

    Grusz!

    Gibt es eventuell dazu passend im Log des Systems Meldungen über eine nicht funktionierende Netzwerkverbindung?


    Laufen da neben dem VDR noch Prozesse, die eine hohe Last erzeugen (z.B. epgd und MariaDB beim Mergen des EPGs?)

    Das (Test)system ist nur für vdr ausgelegt. Es gibt hier keine speziellen plugins, die hohe Last erzeugen sollten (kein epgd). Warum es zu den Einträgen "SATIP-ERROR: Connection timeout - retuning [device 1]" kommt, kann ich mir nicht erklären. Der einzige Unterschied zum derzeit noch laufenden Produktivsystem (yavdr-0.6x) ist, daß die Systemplatte via USB-2-SATA Adapter an der Box hängt. Der alte Adpater kann sicher kein USB3. Am Produkivsystem kommt es nicht zu den SATIP Timeouts. Netzwerkseitig habe ich im allgemeinen keine Probleme.


    Grusz!


    PS: ich hab das Log (journalctl) ohne Filter durchgekämmt - keine Fehler zu Netzwerk & co

    .. and always you can see a "kernel GPU" output in the log before the massive audio/alsa log entries start:

    Code
    1. Nov 18 05:36:11 vdr kernel: NVRM: GPU at PCI:0000:01:00: GPU-d4ae550e-c6cc-3f65-7a21-d846279d6f78
    2. Nov 18 05:36:11 vdr kernel: NVRM: GPU Board Serial Number:
    3. Nov 18 05:36:11 vdr kernel: NVRM: Xid (PCI:0000:01:00): 68, pid=1166, CCMDs 00000016 0000c2b0
    4. Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    5. Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: start delay 336ms
    6. Nov 18 05:36:13 vdr vdr[1166]: [6585] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    7. Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    8. Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: start delay 336ms
    9. Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    10. [..]

    Did it happen after the last update, or was it all the time?

    Here it happened always. The error occured with ansible bionic and now with ansible focal also. Now installed is version:

    Code
    1. vdr-plugin-softhddevice 1.0.7+git20201108-3-003e956-0yavdr0~focal

    with the options

    Code
    1. -v vdpau
    2. -w alsa-driver-broken

    activated. I have no special epg-plugins or plugins for visual effects installed. Usally it happens in the night, when nobody operates/controls vdr.


    Thx!

    Nachtrag - so sieht das Log innehalb einer Minute im "Fehlerfall" aus (gekürzt):


    vdr wurde dabei mittels "systemctl stop vdr" gestoppt, was doch bis zu ~30sec+ dauert, dabei läuft das Log so weiter wie oben dargestellt.


    Grusz!


    PS: hoffe nicht, daß das Problem hier ganz woanders liegt :schiel

    Die Logeinträge mit den 336ms habe ich auch massiv, wenn der vdr sich „aufhängt“. Das kommt, wenn er eine Zeit lang unbedient läuft - meistens passiert’s über Nacht, aber nicht immer. Eigenartig ..


    Grusz!


    PS: bin auf ansible focal

    Danke! :tup :] :tup - hab es wieder hinbekommen - da hab ich wohl voll daneben gegriffen :monster2


    Ohne deine Hinweise, wäre ich da nicht mehr retour gekommen. Auch die Liste mit den installierten nvidia Paketen war sehr wertvoll (ohne diese nachinstalliert zu haben, war Ton da, Bild schwarz).


    "libnvidia-ml-dev" + "nvidia-cuda-dev" hätte ich mir aber sparen sollen (~0,5G).


    Grusz!

    Du hast da überall nur ein PPA drin:

    Code
    1. 500 http://ppa.launchpad.net/seahawk1986-hotmail/vdr-2.4.5-patches/ubuntu focal/main amd64 Packages


    Bei mir ist da noch

    Code
    1. 500 http://ppa.launchpad.net/yavdr/experimental-vdr/ubuntu focal/main amd64 Packages

    dabei. Liegt's an dem?

    Installiert ist "2.4.5-2yavdr1~focal" aus dem neuesten PPA - also neue ABI.


    Trau' mich jetzt das "experimental-vdr" nicht einfach wegzu'purgen'. Außerdem sind bei dir "10x"-mehr nvidia Pakete installiert :wow


    Grusz!


    //edit: ach, es ist ein Testsystem - jetzt mach'ich's. Steckt aber schon viel Arbeit drin ..

    Danke für die rasche Antwort!


    Ich habe hier aber keine selbstkompilierten Plugins - die Pakete in deinem PPA sind doch schon sauber gegen die neue ABI gebaut. Verstehe das jetzt nicht.

    In meiner "Verzweiflung" habe ich gestern auch noch den "nvidia-Treiber" auf Version 455 aus dem "Grafic Driver PPA" hochgezogen:

    Code
    1. ii libnvidia-common-455 455.38-0ubuntu0.20.04.1 all Shared files used by the NVIDIA libraries
    2. ii libnvidia-compute-450:amd64 450.80.02-0ubuntu0.20.04.2 amd64 NVIDIA libcompute package
    3. ii libnvidia-gl-440:i386 455.28-0ubuntu0~0.20.04.1 i386 Transitional package for libnvidia-gl-455
    4. ii libnvidia-gl-455:amd64 455.38-0ubuntu0.20.04.1 amd64 NVIDIA OpenGL/GLX/EGL/GLES GLVND libraries and Vulkan ICD
    5. ii libnvidia-gl-455:i386 455.38-0ubuntu0.20.04.1 i386 NVIDIA OpenGL/GLX/EGL/GLES GLVND libraries and Vulkan ICD
    6. ii nvidia-settings 440.82-0ubuntu0.20.04.1 amd64 Tool for configuring the NVIDIA graphics driver

    Da passen die Versionen auch nicht so richtig zusammen .. ? Vllt. habe ich mir da zusätzlich einen "Hund" reingehauen.


    Die beiden Ausgabeplugins (softhddevice oder softhddevoce-cuvid) lassen sich wg. dem ABI o.a. ABI Fehler nicht installieren. Du meinst doch nicht, daß ich die Ausgabeplugins selbst nochmal neu bauen muß oder vllt. doch? Eventuell nach dieser Anlietung von dir? ==> yavdr experimental für Ubuntu 20.04 (yavdr ansible @ focal)


    Grusz!

    Seit heute startet der vdr nicht mehr - kein "primary device" und beim (neu) Installieren von softhhddevice gibt's einen ABI Fehler aus:


    Code
    1. Die folgenden Pakete haben unerfüllte Abhängigkeiten:vdr-plugin-softhddevice : Hängt ab von: vdr-abi-2.4.5-0yavdrE: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.


    Zuvor hatte ich die PPAs vdr-2.4.3-patches und gleichzeitig auch vdr-2.4.5-patches installiert - vdr-2.4.3-patches ist nun deinstalliert.


    syslog gibt mir das, logisch - es ist kein softhddevice Paket installierbar



    Grusz!

    .. hmm, jetzt stürzt er "ab", wird unbedienbar - und das log läuft voll, Sender ('verschlüsselt' oder nicht) ist dabei egal ..

    Die letzten angeführten Fehler(meldungen) traten in der Art nicht mehr auf.


    Ich hab nun auch softhd lt. diesem Post [Gelöst] yaVDR-Ansible Microruckler auf

    Quote

    [..]bei einer GT1030 mit dem vdr-plugin-softhddevice-cuvid und dem Startargument -v cuvid, damit man CUVID statt VDPAU nutzen kann.

    umgestellt.


    Läuft recht gut - immer noch im Test (also HDD/SSD via USB-Adapter an der Box)

    [..]die Verbindung zur Octopus Net nicht klappt und bei Empfangsproblemen wird der VDR praktisch unbedienbar.

    ja, eigentlich schon .. !


    Nicht ganz erklären kann ich mir, daß es am gleichen System auf einer anderen SSD ("OS" mit yavdr.0.6x) keine Probleme damit gibt.

    Das Test-Ansible/Focal System ist allerdings per USB (auf intern 3.0, Pc,Box / extern ist die SSD via altem Adapter per SATA mit Strom dran).


    'Sat-IP' kommt dabei per LAN direkt vom Octopus zum vdr. In den Logs ist nich zuviel zu finden ..