Posts by dad401

    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.

    Hallo,


    nach einigen Jahren bin ich nun bei einem meiner VDR auf Intel umgestiegen und nutze ein Asrock J4105 Board.


    Mit der Ausgabe über softhddevice (0.7.0) (yavdr experimental ppa) bin ich zufrieden - bis auf PIP und dem Fernbedienungsmodus im live-Plugin (klappt nicht so richtig), funktioniert soweit alles ganz gut.


    Mit meiner Konfiguration (siehe Signatur) läuft alles, jedoch mit folgenden Einschränkungen - ggf. kann das der ein oder andere J4105-Besitzer bestätigen:


    1. Irgendwie gibt es ab und an einen Reset? am SATA-Anschluss 2 in Kombination mit einer WDC WD40EZRZ. Anschluss 1 in Kombination mit einer Samsung SSD 840 EVO scheint nicht betroffen:

    Mit einem weiteren BR/DVD-Laufwerk war es m.E. noch schlimmer - ich habe aber keine Logs mehr, da ich es ausgebaut habe. Wenn die o.g. letzten Meldungen auftauchen, hört man auch ein Geräusch bei der Festplatte.

    Ich werde mal probieren, die WD auf SATA3 bzw. 4 zu stecken, dies ist m.E. ein anderer Controller (ASM1062 Serial ATA Controller).


    2. derzeit (Kernel: 4.18.0-17-generic) Probleme mit der Nutzung einer TBS 6981 (6981:8888) DVB-S2 Karte. In nicht definierten Abständen ist der DVB-Signal weg und im Kernel-Log steht mpeg risc op code error. Ein Neustarten des VDR hilft, ist aber keine Lösung. Mit Verwendung von media_build Modulen tritt das Problem nicht auf. Ich vermute mit Kernel 4.20 wird es dann funktionieren, da der Treiber m.E. einen Workaround hierfür besitzt:

    Code
    1. parm: dma_reset_workaround:periodic RiSC dma engine reset; 0-force disable, 1-driver detect (default), 2-force enable (int)

    Genau dieser Reset kommt vor dem Absturz ein oder mehrmals. Im media_build Module habe ich jedoch keine Option angegeben. Das Modul funktioniert OOTB.


    3. WakeUp funktioniert nur richtig, wenn HPET im BIOS abgeschaltet wird. Der daraus entstehende Eintrag im Log hat keine mir bekannten negativen Auswirkungen:

    Code
    1. [ 4230.000463] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large:
    2. [ 4230.000486] clocksource: 'acpi_pm' wd_now: f63a1c wd_last: 3e978 mask: ffffff
    3. [ 4230.000487] clocksource: 'tsc' cs_now: 5cbde85c352 cs_last: 5ca5282b040 mask: ffffffffffffffff
    4. [ 4230.000490] tsc: Marking TSC unstable due to clocksource watchdog
    5. [ 4230.000543] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
    6. [ 4230.000545] sched_clock: Marking unstable (4229972523459, 27982829)<-(4229979527168, 21015925)
    7. [ 4230.001152] clocksource: Switched to clocksource acpi_pm

    4. lm-sensors - es sind nicht viele Daten verfügbar. Wenn man das Modul nct6775 lädt, erhält man folgende Werte:

    Die Spannungen sind also nicht alle vorhanden (z.B. 12V Schiene).


    Ggf. kann ja die Liste mit weiteren Tipps ergänzt werden...

    Hallo,


    ich glaube die Version hatte ich von hier.


    Ich habe den Wert komplett auskommentiert/entfernt.


    Der Vollständigkeit halber, hier meine bisher gut laufenden Units:


    vdr.service (LimitCORE nur für Testzwecke)


    devices (udev)

    Code
    1. cat /etc/udev/rules.d/80-tbs-i915.rules
    2. # symlinks and tags for frontend0 of the DVB-S card and for graphic card (drm)
    3. SUBSYSTEMS=="pci", DRIVERS=="cx23885", ATTRS{subsystem_device}=="0x8888", ATTRS{subsystem_vendor}=="0x6981", SYMLINK+="tbscard", TAG+="systemd"
    4. SUBSYSTEMS=="pci", DRIVERS=="i915", ATTRS{subsystem_device}=="0x2212", ATTRS{subsystem_vendor}=="0x1849", SYMLINK+="i915card", TAG+="systemd"

    xorg.service

    => ohne das require für das DRM-Interface startete der X-Server - nach Nutzung von media_build - immer zu früh und fand kein Device. Mit den Original-Kernelmodulen hatte ich den Effekt nicht. Leider brauche ich die Module für meine TBS Karte aufgrund von "mpeg risc op code error" noch - mit Kernel 4.20 sollte es gelöst sein.


    vdradmind.service


    In vdr-exec-stxxx.sh kann ich die Module nun starten/stoppen - ist aber nicht zwingend notwendig.


    killall vdr klappt aber immer noch nicht - scheint wohl am exit code 0 zu liegen:

    Danke für die Tipps/Neuerungen - bin auf einem guten Weg. Das mit conf.d funktioniert sehr gut - ich habe das VDR CONF-DIR nun nach /opt umgezogen und conf.d verlinke ich dort hin.


    Die VDR-Konfiguration ändere somit wie folgt:

    Code
    1. --config=/opt/vdr
    2. --video=/video
    3. --record=/opt/vdr/tools/rwrapper.sh
    4. --shutdown=/opt/vdr/tools/safepower.sh
    5. --grab=/tmp
    6. --port=6419
    7. --watchdog=90
    8. --epgfile=/video/epg.data
    9. --log=3
    10. --lirc=/var/run/lirc/lircd


    Ich nutze nun folgende Units:

    vdr.service

    Das ganze kann ich mit ExecPre/Post ja noch ausbauen.


    Und X wird nun mit dieser Unit gestartet:

    xorg-vdr.service

    Code
    1. [Unit]
    2. Description=X Server für VDR
    3. BindsTo=vdr.service
    4. [Service]
    5. ExecStart=/usr/bin/X -br -nolisten tcp :0
    6. [Install]
    7. WantedBy=multi-user.target


    vdr.service kann ich nun starten und stoppen, und X startet/stoppt gleichzeitig mit.


    Was jedoch noch nicht funktioniert, ist der Restart des VDR, wenn er mal abschmiert. Gebe ich killall vdr ein, wird der service nicht neu gestartet. Restart=on-failure scheint irgendwie nichts zu bewirken?!

    Hallo,


    ich habe hier ein komisches Verhalten des VDR, welcher, wenn ich auf der FB die OK Taste drücke, doppelt reagiert.

    Ursache ist der IMON IR-Empfänger in meinem Gehäuse, welcher reagiert, wenn ich das Protokol rc-6 aktiviere:

    Nehme ich rc-6 weg, funktioniert alles korrekt. Ich frage mich jedoch, warum der VDR auf /dev/input/event5 überhaupt reagiert. Ich habe hier nur inputlirc am Laufen mit folgender Konfiguration:

    Code
    1. # Options to be passed to inputlirc.
    2. EVENTS="/dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00XWRC-event-if00"
    3. OPTIONS="-g -m 28"

    D.h. er darf nur auf die den MCE-IR-Empfänger reagieren.


    Kann es sein, dass Xorg event5 auswertet - quasi wie eine angeschlossene Tastatur?! Der VDR funktioniert auch mit einer Tastatur (remote.conf) und ENTER ist "OK" - genauso wie die event5 evtest-Ausgabe KEY_ENTER ausgibt.

    Kann das jemand bestätigen - oder ist die Vermutung falsch?