Posts by dad401

    Der Aufruf "was läuft jetzt" scheint nun stabil zu sein.


    Heute habe ich auf "next" (im "was läuft jetzt menü die grüne Taste zum Ändern der Zeiten) gedrückt und hatte einen Crash:


    Version: vdr-plugin-epgsearch/bionic,now 2.4.0+git20190919-8-84811de-0yavdr0~bionic


    Oder ist das jetzt eher ein IPTV-Plugin Problem?


    Marcus

    Hallo,


    ich habe hier das Problem, dass Kodi nicht alle meine Alsa-Geräte erkennt. Insbesondere der SPDIF Ausgang fehlt in der Auswahl bei den Einstellungen.

    Um Probleme mit der Hardware auszuschließen, habe ich mal LibreELEC per Stick gestartet - dort sind alle ALSA Devices vorhanden.

    Ich bin jedoch noch nicht dahinter gekommen, was an meiner Ubuntu 18.04 Installation da schief läuft. Unterschiede bei aplay sind jedoch sichtbar.


    Wegen Zeichenbegrenzung das kodi.log über Pastebin von LibreELEC und hier das kodi.log von meiner Ubuntu-Installation (jeweils nur relevante Anteile).


    aplay -l ist bei beiden gleich - aplay -L aber sehr unterschiedlich:


    LibreELEC:

    bei Ubuntu:

    Ich weiss jetzt nicht woher die ganzen anderen (virtualen Devices?) wie dmix und plughw kommen / wann diese angelegt werden. Ich habe unter Ubuntu keine .asoundrc unter HOME oder /etc/asound.conf


    Ideen?




    Zu Amazon Prime mit Kodi: Haltet ihr das Addon für "vertrauenswürdig"? Ich meine, mit den Logindaten kann man ja ganz viel anstellen (Bestellungen etc.).

    Oder gibt es hier alternative Lösung (ala "Prime readonly Account").

    Ich hab es mal mit dem Haushaltsgast-Account probiert - aber der lässt kein Prime Video zu, sondern nur Prime-Bestellungen.

    Hallo,


    ich habe hier gelegentlich einen Absturz des VDR wenn ich die Übersicht aufrufe, welche alle Sender mit den aktuellen Programm liefert (Programmmenü von epgsearch und dann grüne Taste). Ich rufe das über ein Keymacro auf (User1 @epgsearch Green) .


    Hier ein backtrace:

    Verwendete Versionen:

    Hat jemand ggf. dasselbe Problem? Kann man am backtrace die genaue Ursache erkennen?


    Das ganze tritt nicht immer auf, sondern nur sporadisch. Gefühlt wenn der VDR etwas länger schon läuft bzw. nach mehreren (erfolgreichen) Aufrufen der Übersicht.


    Marcus

    Ich habe mir wie folgt Abhilfe geschaffen:


    1. Meldungen für rsyslogd blocken (damit die Logdateien nicht zu groß werden):

    Code
    1. cat /etc/rsyslog.d/10-ignore.conf
    2. :msg, contains, "dvb_frontend_get_frequency_limits" stop

    2. Und damit mir dmesg nicht zuviel ausgibt, folgenden alias:

    Code
    1. alias dmesg='dmesg -l emerg,alert,crit,err,warn,notice,info'

    Siehe auch hier.


    Sollte reichen, bis es in einem späteren Kernel gefixt ist.


    Änderungen bei /proc/sys/kernel/printk brachten bei mir keinen Erfolg.

    Ich habe das J4105-ITX und nutze softhddevice aus den YaVDR-PPA. Ich kann hier absolut nicht klagen (SD, HD und HVEC über DVB-T2). Läuft stabil.

    Laut Installation wird folgende Version genutzt:

    vdr-plugin-softhddevice-vdpau-hevc 0.7.0+git20180203-724-3781118-pesintta-2yavdr3~bionic


    vaapidevice konnte mich damals beim Umstieg auf das J4105-System nicht so überzeugen.


    Anbei noch paar Ausgaben:

    Hallo,


    ich versuche derzeit das IPTV-Plugin zum Laufen zu bekommen. Das ganze scheitert derzeit an einer Bildausgabe, da VLC den Encoder nicht findet. Hier mal den Fehlerausgabe bei Aufruf des VLC per Console:

    Ich habe schon einiges gegoogelt. Von unstripped Paketversionen, -extra Pakete und VLC-Einstellungen (strict-standard) - hilft alles nichts unter Ubuntu 18.04. Der Encoder ist nicht dabei.


    Hat jemand noch einen Tipp? Soll ich ggf. VLC aus den VideoLAN-PPA installieren? Noch genialer wäre ja ein HW-basiertes Transcoding per FFMPEG und VAAPI.

    Welche Codecs versteht das IPTV-Plugin eigentlich - ich empfange eigentlich nur einen reduzierten HD-Stream (streamdev-server) von einem anderen VDR mit folgenden Parametern:

    Code
    1. PROG=ffmpeg; FFMPEG_VC=h264_vaapi; FFMPEG_AC=libmp3lame; VBR=3000; ABR=96; FFMPEG_H264_VOPTS="-bufsize 2M -minrate 1M -maxrate 3M"


    Marcus

    Hi,

    dann mit Verlust anderer Meldungen

    Code
    1. /etc/sysctl.conf
    2. #kernel.printk = 3 4 1 3

    Wirkt das auch auf den Ringpuffer /dev/kmsg und damit auf die dmesg Ausgabe? Ich dachte das wirkt nur auf die Consolen-Ausgabe. Es steht derzeit auf 4 4 1 7. "Current" ist damit 4 und dürfte (soweit ich verstanden) die Meldung mit 7 (dprintk) nicht ausgeben?! Tut sie ja aber...oder gilt die letzte Ziffer hier (boot-time-default)?


    EDIT: getestet mit 3 4 1 3 und dmesg gibt die Meldung weiterhin aus.


    Mein Workaround wäre erstmal der gewesen:

    Code
    1. alias dmesg='dmesg -l emerg,alert,crit,err,warn,notice,info'

    Hatte ich vor einiger Zeit mit VDPAU @ nouveau befasst und glaub auch mal was geschrieben hier. Grundsätzlich hatte ich das ganze ans Laufen gebracht gehabt, nur fehlt der freien VDPAU Implementation leider der ganze heiße Scheiß zur Bildaufbereitung, temporal, temporal_spatial, etc. der VDPAU ausgezeichnet hat. Denke das hat auch Lizenz-rechtliche Gründe.

    Ich glaube das habe ich gelesen um es dann zu probieren. Demnach scheint es (derzeit) keinen Sinn zu machen.

    Fazit:

    Die alten VDRs (GeForce 9300M/8400?) müssen auf dem 340er bleiben und damit bei 18.04 LTS, mit Glück gibts den 340er noch in der nächsten LTS. Danach ist Ruhe, falls es der nouveau bis dahin nicht schafft. 2 meiner Haupt-VDR sind inzw. auf Intel umgestellt und laufen inzw. ganz gut (inkl. HVEC DVB-T2 Sender).

    Ja ist bekannt - bis der Patch bei Ubuntu im Standardkernel ankommt dauert das aber ne Weile. Ziel war ohne eigenes Bauen der Module (media_build) auszukommen.


    Wie ich jedoch sehe, wird die Meldung nicht mehr in syslog / kern.log geloggt sondern lediglich nach /dev/kmesg, welches mit dmesg ausgegeben wird. D.h. die Ausgabe mit dmesg bleibt unschön, aber zumindest werden die Meldungen nicht mehr in die Logdateien geschrieben.

    Bzgl. rsyslog: Kann es sein, dass anstelle ~ nun stop als Keyword genommen werden muss (Manpage rsyslog.conf bzw. hier)? Hab es mit beiden probiert - scheint mit beiden zu klappen (getestet mit kern.log)

    Hallo,


    ich war jetzt erstmal im Urlaub und komme jetzt zum Testen.


    Leider wird dmesg weiter mit den Logmeldungen befüllt (Kernel 5.0.0-27-generic):

    Code
    1. [ 77.365679] i2c i2c-4: cx24117_load_firmware: FW version 1.44.95.2
    2. [ 77.365692] i2c i2c-4: cx24117_firmware_ondemand: Firmware upload complete
    3. [ 77.398019] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    4. [ 77.433987] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    5. [ 81.045862] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    6. [ 131.628706] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0

    /etc/systemd/journald.conf enthält

    MaxLevelKMsg=notice


    wobei dies quasi schon default war. Und /etc/rsyslog.d/10-ignore.conf habe ich wie oben angelegt. Danach auch zu Sicherheit neugestartet.


    Ideen?

    Hier die Rückmeldung:


    mit dem Treiber aus dem o.g. PPA klappt es nun auch mit Kernel 5.0. Auch reduzieren sich die Meldungen unter Kernel 4.18 auf wenige Zeilen - analog ist es im 5.0er:

    Code
    1. [ 5.715725] ACPI Warning: \_SB.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20181213/nsarguments-66)
    2. [ 5.770188] resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window]
    3. [ 5.770357] caller os_map_kernel_space+0x8d/0xb0 [nvidia] mapping multiple BARs

    Und nun muss ich dennoch auf Updates des Kernel warten, da man diese nervigen Debugmeldungen nicht rausgenommen hat:

    Code
    1. [ 36.626689] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    2. [ 40.499663] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 950000000...2150000000, frontend: 950000000...2150000000
    3. [ 52.958558] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    4. [ 55.182528] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    5. [ 55.775289] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0

    Bleibt dann nur wieder media_build, wo ich diese Debugmeldung (dvb_frontend.c) schon entfernt habe...

    Dies ist hier bereits thematisiert...

    Danke für den Tipp - das kann ich mal probieren.

    So richtig toll scheint der nvidia-Treiber aber auch nicht mehr zu funktionieren - daher die Idee mit nouveau.

    Mit Kernel 4.18.0-25 gibts immer folgende Warnung/Fehler beim Start (dmesg):

    Auch beim Entladen der DVB-Module macht der m.E. Probleme.


    Rückmeldungen, falls jemand nouveau mit VDPAU und dem VDR zum Laufen gebracht hat, können gerne noch gepostet werden...

    Inzwischen ist bei Ubuntu 18.04 der 5er Kernel standardmäßig installierbar. Leider musste ich feststellen, dass das Modul für den nvidia-340 Treiber nicht mehr mit DKMS kompiliert. Ich hoffe nur, dass die 340er Version im 5er doch noch mal laufen wird - die GF 9300 ist für TV ja sonst völlig ausreichend.


    Aufgrund des Problems habe ich mir den nouveau Treiber mal wieder angesehen und er bietet inzwischen VDPAU-Unterstützung - auch für meine Graka. Testweise habe ich den mal installiert. vdpauinfo liefert auch korrekte Ausgaben:

    Leider stürzt der VDR jedoch mit softhddevice beim Starten ab oder startet immer wieder neu (Log: vdr[1397]: vdr: ../src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c:368: nouveau_vp3_fill_picparm_h264_vp: Zusicherung »dec->refs[refs[j]->valid_ref].vidbuf == refs[j]« nicht erfüllt.)


    Das OSD (Kanalinfo) blendet beim Start ein, aber das TV Bild bleibt schwarz. Eine andere softhddevice Version lies den VDR mit der Kanalinfo einfrieren.


    Hat jemand ggf. softhddevice mit nouveau am Laufen?

    Ich habe die Karte gestern eingebaut. Ähnlich wie bei einer TBS-Karte gab es manchmal auch hier (mit einem älteren cx23885 Treiber) mpeg risc op code Fehler und ähnliche dmesg-Ausgaben wie hier.

    Mit Kernel 5.0 ist das Problem m.E. im Treiber behoben. Da dieser derzeit (noch?) nicht mit dem nvidia-340 funktioniert, habe ich die Karte derzeit mit Kernel 4.18.0-25 und media_build am Laufen. Soweit ich es verstanden habe, benötigt der Treiber den "dma_reset_workaround".


    Die Karte läuft seitdem gut. Schön ist die Kombination DVB-S2/C, die auch OOTB im VDR funktioniert.

    Hoffe die läuft auch länger so gut - sie ist ja erst 1 Tag im Einsatz...