vdr-plugin-softhddevice hängt

  • Hi,


    "svdrpsend ping" gibt "timeout" zurück.


    der bt von gdb:


    bt full:


    Im syslog steht:

    Code
    Nov 22 13:10:10 vdr1 vdr: video: 11:23:30.055  +44  360   0/\ms  24+6+4 v-buf
    Nov 22 13:11:00 vdr1 vdr: video: 11:24:20.055  +47  314   0/\ms  37+6+4 v-buf
    Nov 22 13:11:50 vdr1 vdr: video: 11:25:10.055  +50  397   0/\ms  55+6+4 v-buf
    Nov 22 13:12:01 vdr1 vdr: audio/alsa: using device 'pulse'
    Nov 22 13:12:01 vdr1 vdr: audio/alsa: start delay 336ms
    Nov 22 13:12:01 vdr1 vdr: [9166] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    Nov 22 13:12:01 vdr1 vdr: audio/alsa: using device 'pulse'
    Nov 22 13:12:01 vdr1 vdr: audio/alsa: start delay 336ms
    Nov 22 13:12:01 vdr1 vdr: audio/alsa: using device 'pulse'

    Die letzten 2 Zeilen wiederholen sich sehr oft.

    Zwischendrin dann immer wieder ein "vdr: [9167] ERROR: driver buffer overflow on device 2".

    Das Bild steht.


    ~ Markus


    "

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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

  • Hab da schon eine Zeile, die regelmäßig aufgerufen wird:

    Code
    /usr/bin/svdrpsend stat disk 2>&1|grep timeout >>/var/log/vdr/shutdown.log && [ `cat /var/lib/vdr/timers.conf|grep ^9|wc -l` -eq0 ] && /sbin/systemctl restart vdr

    Wenn also das svdrpsend nicht reagiert ("timeout"), wird nach einer gerade laufenden Aufnahme (aber nicht mit svdrpsend, das funktioniert dann ja auch nicht) gefragt und, wenn keine läuft, der vdr mal neu gestartet.

    Passiert auch so 2-3x am Tag, meist ohnehin wenn der Fernseher nicht läuft. Wenn er aber läuft, ist die FB auch "tot".

    Der Zustand dauert aber auch ohne Neustart nicht "ewig", zu einem watchdog timeout kommt es nur selten.

    Und ja, das Logfile sagt während der Zeit sogut wie nix, als ob das Logging auch mit hinge.

  • 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

  • Danke für Eure Rückmeldungen.

    Ich tippe auf einen Bug in softhddevice.

    Bei meinem Server tritt es nicht auf.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Here no atmo- or boblight, and softhddevice with vdpau. It appears the hangs mainly appear with high background activity like epgd-updates or transcoding.

    Using a i5 with enough ram ...

  • 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
    vdr-plugin-softhddevice              1.0.7+git20201108-3-003e956-0yavdr0~focal

    with the options

    Code
    -v vdpau
    -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!

    Lascala LC17 - tribute to viking ;o) + atric IR / SoC ASUS J3455M-E / OctopusNet S4 / yavdr ubuntu jammy / output: osd2web + kivy-osd2web / branch 'python3' via 6.4" TFT & sat>ip DVB-S/S2 via FullHD / NVidia GT1030 passiv

    Einmal editiert, zuletzt von ciax ()

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

    Code
    Nov 18 05:36:11 vdr kernel: NVRM: GPU at PCI:0000:01:00: GPU-d4ae550e-c6cc-3f65-7a21-d846279d6f78
    Nov 18 05:36:11 vdr kernel: NVRM: GPU Board Serial Number:
    Nov 18 05:36:11 vdr kernel: NVRM: Xid (PCI:0000:01:00): 68, pid=1166, CCMDs 00000016 0000c2b0
    Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: start delay 336ms
    Nov 18 05:36:13 vdr vdr[1166]: [6585] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: start delay 336ms
    Nov 18 05:36:13 vdr vdr[1166]: audio/alsa: using device 'default'
    [..]
  • Nov 18 11:12:08 vdr vdr[1166]: [1222] SATIP-ERROR: Connection timeout - retuning [device 1]
    Nov 18 11:12:09 vdr vdr[1166]: [1225] SATIP-ERROR: Connection timeout - retuning [device 2]
    Nov 18 11:12:09 vdr vdr[1166]: [1228] SATIP-ERROR: Connection timeout - retuning [device 3]

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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

  • Nov 18 05:36:11 vdr kernel: NVRM: Xid (PCI:0000:01:00): 68, pid=1166, CCMDs 00000016 0000c2b0

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

  • 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!

  • Ich nutzte den nvidia-Treiber, der bei Ubuntu focal dabei ist und mit der GT1030 die Ausgabe über das vdr-plugin-softhddevice-cuvid mit aktiviertem CUVID:

    Code
    [softhddevice]
    -D
    -w alsa-driver-broken
    -w also-no-close-open
    -v cuvid

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

  • [..]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.")

  • .... daß die Systemplatte via USB-2-SATA Adapter an der Box hängt. ...

    Falls es mit den letzten Änderungen doch nicht gelöst ist: schau mal, ob die USB-Festplatt sich nach einer bestimmten Zeit schlafen legt und deshalb das Connection Timout kommt.

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Hi,


    I have an older Nvidia grafics card, so I cannot use cuvid.

    @Inj, any idea how this can be solved for VDPAU?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • I have an older Nvidia grafics card, so I cannot use cuvid.

    Welchen Treiber nutzt du denn? ciax nutzt das ja erst mal auch mit VDPAU:

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!