Posts by dad401

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

    Hallo,


    mein System mit mit dem Futaba-Display läuft soweit und ich bin am "fein"-einrichten.


    Das installierte lcdproc funktioniert mit dem Display - im VDR werden jedoch die Zusatzsymbole nicht verwendet.

    Brauche ich hier noch ein bestimmtes lcdproc-Plugin? Ich nutze derzeit lcdproc (0.0.10-jw9) aus dem in der Signatur angegebenen ppa.


    P.S.: ja, das targavfd-Plugin kenne ich, mich interessiert aber der aktuelle Stand, der mit lcdproc funktioniert.

    Ich habe nun auch System 3 vom Atom N330, Zotac IonTX-F-E auf das J4105 inkl. Update 18.04 aktualisiert (quasi das OS von System 1 geklont).


    Erfahrungen hiermit:

    Xubuntu wollte anfänglich aufgrund des (Slim-Line) DVD-Laufwerkes (Anschluss am zweiten SATA-Controller) nicht starten. Es blieb bei der Anzeige der SATA-Kernelmeldungen stehen, es half nur ein harter Reset. Nachdem ich das Laufwerk auf den ersten Controller, dort wo die SSD angeschlossen ist, umgesteckt hatte, ging es endlich. Etwas merkwürdig.


    Weiterhin hatte ich beim SDC Megtron Display (Alphacool Variante) beobachtet, dass es nach einem Neustart (bzw. Abschalten/Anschalten) sporadisch nicht initialisiert wurde. Der Start wurde dadurch stark verzögert - ich glaube es gab da einen USB Timeoutfehler.

    Ich habe das Display nun an das doppelte interne USB 2.0 Panel, anstelle des Panel mit der einzelnen Leiste angeschlossen. Bisher scheint es zu laufen - ich werde es beobachten...


    Auf System 3 läuft lirc mit dem Atric (serial). Die Fernbedienung reagiert viel besser als auf dem ION-Board zuvor. Allerdings habe ich immer noch folgende Meldungen im Log:

    Code
    1. serial_ir serial_ir.0: ignoring spike: 1 1 16079367532089ns 16079097271319ns


    Die Cine S2 (V5.5?) läuft bisher auch OOTB - musste nur die Firmware noch kopieren (ngene_18.fw). Im Gegensatz zu System 1 (TBS Karte) brauche ich hier keine extra Kerneltreiber von media_build.


    Ansonsten bin ich bisher zufrieden mit der Ausgabe per VAAPI und Intel. Besonders das Encodieren in Hardware für einen Stream (streamdev-server + ffmpeg) übers Internet ist super. Ich hab mal meine leicht geänderte externremux.sh angehangen. Es ist QUALITY=F1.


    Hier noch einige udev-Regeln, falls es jemand braucht:

    Für LIRC und dem COM-Port: serial-ir.conf unter modprobe.d:

    Code
    1. options serial_ir irq=4 io=0x3f8
    2. install serial_ir setserial /dev/ttyS0 uart none; modprobe --ignore-install serial_ir

    Ich meine der shutdown-Workaround ist nicht meht notwendig, habe es aber dennoch diese Optionen vom Altsystem übernommen:

    Code
    1. options stb6100 verbose=0
    2. options ngene shutdown_workaround=1

    Ohne die letztere, schaltete der PC mit dem Atom/ION-Board nicht richtig ab.


    vdr.service für System 3:


    Was mir am System 1 noch aufgefallen ist: Ich habe das interne USB 3.1 Panel per Slotblech nach aussen geführt - aber so richtig mag der Port nicht funktionieren - oder liegt es am USB 3.0 Chinaslotblech?!. Gerade eine Webcam angesteckt :-/

    EDIT: meine Dummheit: ich hatte vergessen den internen USB2-Anschluss des Gehäuses abzustecken. Es funktioniert entweder nur der interne Doppel-USB3.0 Header oder der interne Doppel-USB2.0 Header. Beide zusammen nicht. Nun klappts auch mit dem Gerät im USB3.0 Slotblech:

    Code
    1. [ 195.104200] input: UVC Camera (046d:0807) as /devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/input/input23
    2. [ 195.104512] usbcore: registered new interface driver uvcvideo
    3. [ 195.104514] USB Video Class driver (1.1.1)
    4. [ 195.332143] usb 1-2: set resolution quirk: cval->res = 384
    5. [ 195.332647] usbcore: registered new interface driver snd-usb-audio


    Fazit: bis auf ein paar kleine Macken läuft soweit alles ganz gut...

    Die Standard (X)ubuntu Quellen. Du meinst mit "allg Kernel ppa" sicher ein zusätzliches PPA.


    apt search linux-image liefert keinen 5er Kernel. Der neueste ist soweit ich meine installiert:

    "Linux antecvdr 4.18.0-17-generic #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux"

    Ich habe das mit den SATA-Ports nochmal getestet. Am 1. SATA Controller (ata1 und ata2) hängt die SSD und nun ein DVD-Brenner. Am 2. Controller nun die WD-HDD (war vorher an ata2) - das Log ist ähnlich:



    Bisher habe ich jedoch keine negativen Auswirkungen feststellen können. Ich lasse das erstmal so.

    Ergänzend: am 2. SATA-Controller habe ich den 3. Anschluss (ata3) als eSATA per Slotblech nach aussen geführt. Das funktioniert auch (im o.g. Log war dort jedoch nichts angeschlossen).


    Folgendes ist m.E. jedoch zum alten System (ION) anders bzgl. HDD: Wenn ich im VDR den Schnitt einer Aufnahme starte, dann ruckelt/stockt kurzzeitig die Wiedergabe einer Aufnahme (nicht das TV Signal). Das kannte ich bisher noch nicht. Im extrecmenung ist "Bandbreite beim Schneiden begrenzen" aktiviert. Vorher nutze ich jedoch das extrecmenu (ohne ng).

    Ich suche für einen meiner VDRs eine neue DVB-S2 Karte (PCIe). Viel ausgeben wollte ich nicht dafür. Allerdings bin ich bei der Suche auf die Hauppauge WinTV HVR 5525 gestossen, da diese vermutlich DVB-S2 und DVB-C/T2 unterstützt. Da ich nur einen PCIe Slot habe, wäre das ganz sinnvoll.


    Kann jemand bestätigen, dass diese Karte problemlos läuft und vor allem DVB-C oder T2 und DVB-S2 parallel laufen? Dann könnte ich auf einen USB DVB-C/T2 Empfänger verzichten - wobei ich einen ungenutzt da habe.

    D.h. Alternativ: gibt es andere Empfehlungen für eine günstige, gut laufende DVB-S2 PCIe Karte?

    Danke...das passt zu meinen Beobachtungen. Aber evtl. kann man das Farbmenü ja umschaltbar machen. Bei "Programm" geht das mit "0" - die hier aber schon für die Sortierung belegt ist.

    Soweit ich weiss, ist der neueste Kernel noch nicht standardmäßig verfügbar. Da könnte ich auch warten...

    Endladen: modprobe -r budget_ci lnbp21 stb6100 stb0899 rc_tt_3200 - wenn ich einzeln entlade, geht es gut für budget_ci lnbp21 stb6100. Danach ein modprobe -r stb0899 und der Fehler kommt.

    Weiss jemand nach welchem Schema das Plugin auf der roten Taste mal UNDELETE und mal die Aufnahmebefehle legt?

    Wie komme ich an die Befehle, wenn UNDELETE angezeigt wird (bzw. umgedreht)?

    Hallo,


    beim Umstellen auf Xubuntu 18.04 (System 2) stelle ich fest, dass beim Entladen der Module der TT Budget S2-3200 es Probleme gibt. Beim Entladen des Modules stb0899 gibt es folgende Fehlermeldung im Kernel und das System wird instabil:

    Das gleiche passiert auch mit media_build-Treibern.


    derzeitiger Workaround: Module nicht entladen. Allerdings bleiben dennoch einige Zweifel zwecks Stabilität.

    Ja - das Kabel habe ich schon getauscht - ich glaube 3x, da ich schonmal schlechte Erfahrungen damit gemacht habe. Bei den SATA-Geräten bin ich aber (vermutlich) auf die Ursache eines Problems meines VDRs gestossen, welches ich nie identifizieren konnte. Der VDR (damals mit ION-Board) stürzte in unregelmäßigen Abständen ab (das Bild blieb stehn und der Ton stotterte/zischte in einer Endlosschleife). Ursache war wohl das BR/DVD-Laufwerk, denn also ich dieses jetzt angeschlossen habe (war mangels Stromleitungen der PicoPSU noch abgeklemmt), konnte ich den Absturz durch VDR => Commands => eject reproduzieren. Nunja...Thema am Rande.


    @Der_Pit - also ich habe einen 40" und kann mit dem SD gut leben. Es stimmt aber, dass VDPAU hier besser war. Meine Konfiguration:


    Geht denn PIP bei Dir? Bei mir stürzt der VDR damit ab. Ich nutze derzeit vdr-plugin-softhddevice-vdpau-hevc. Vaapidevice habe ich nur funktionsweise getestet, softhdcuvid (4 Versionen?) noch gar nicht. Da blicke ich derzeit nicht durch, was besser/aktueller ist. Fazit: softhddevice geht gut mit SD, HDTV und HVEC (DVB-T2), Stereo-Ton über HDMI funktioniert (SPDIF noch nicht getestet). PIP ist eher Spielerei.