Beiträge von hueb_s

    Mir scheint, dass DD auf einer recht alten Version vom Standard-dvb-core aufsetzt und dessen Weiterentwicklungen nicht übernommen hat. Ob damit auf demselben Rechner gleichzeitig DVB-Treiber für DD und andere Hersteller laufen können, wäre eine interessante Frage.


    Wie soll denn ein eine andere Version des dvb-core Moduls geladen werden? Bei mir (Ubuntu 21.10 Server) wird das Standard-Modul dvb-core verwendet zusammen mit ddbridge:


    modinfo dvb_core

    filename: /lib/modules/5.13.0-23-generic/kernel/drivers/media/dvb-core/dvb-core.ko

    license: GPL

    author: Marcus Metzler, Ralph Metzler, Holger Waechtler

    description: DVB Core Driver

    srcversion: 845D85FD515EAA6AFD248B5

    depends: mc

    retpoline: Y

    intree: Y

    name: dvb_core

    vermagic: 5.13.0-23-generic SMP mod_unload modversions


    modinfo ddbridge

    filename: /lib/modules/5.13.0-23-generic/kernel/drivers/media/pci/ddbridge/ddbridge.ko

    version: 0.9.33-integrated

    license: GPL v2

    author: Ralph and Marcus Metzler, Metzler Brothers Systementwicklung GbR

    description: Digital Devices PCIe Bridge

    srcversion: 26A5F203B39FDCD7E5CC63E


    Oder gibt es zwei verschiedene dvb-core-Module im Kernel? Kann ich mir nicht vorstellen...

    Interessant auch, dass die DVB-Core-Entwickler auch das ddbridge-Modul entwickelt haben?

    Hallo,


    ich habe das Problem, dass bei ARD-Serien (In Aller Freundschaft, Lindenstraße etc.) im EPG die Episode-Nr. im Titel auftaucht. Bsp:

    Titel: Lindenstraße (1672)

    Episode: Aufgeflogen


    Das führt leider bei Serienaufnahmen dazu, dass jede Aufnahme in einem separaten Verzeichnis abgelegt wird:

    Lindenstraße (1672)~Aufgeflogen


    Ich hätte es lieber so, dass die Aufnahmen im gleichen Verzeichnis abgelegt werden (ist ja eigentlich der Sinn der Serienaufnahmen):

    Lindenstraße~Aufgeflogen (1672)


    Gibt es einen Weg, das zu korrigieren? Meine Ansätze wären entweder, den EPG-Eintrag vor der Aufnahme zu ändern, oder nach der Aufnahme diese ins korrekte Verzeichnis zu verschieben.

    Gibt es dafür ein Plugin o.ä.? Ich finde nur das nicht mehr gepflegte EPGFixer Plugin.


    VG,

    Steffen

    Hab einen Headless Server mit 2x S952 (allerdings Standard-Ubuntu mit zusätzlichen yaVDR-Paketen), der läuft ebenfalls mit Kernel 4.2 (seit Erscheinen von yaVDR 0.6). Ebenfalls keine Probleme mit Klötzchenbildung oder anderes. Allerdings hab ich das Problem, dass nach dem Reboot des Systems die beiden Karten nicht erkannt werden, sondern erst nach manuellem Restart des vdr Services. Hab den Eindruck, dass es mit dem Laden der Firmware oder Kernel-Module zusammenhängt, hab allerdings noch keine Zeit zur Untersuchung gehabt.

    - DVBSKy S952 Dual: Herstellertreiber. Danke.


    Funktioniert ab yaVDR 0.6.0 mit Wily-Kernel auch ohne Hersteller-Treiber (nur Firmware installieren)! Bei mir völlig problemlos. Bis yaVDR 0.5.0 war es immer ein Gefrickel mit den Herstellertreibern...
    Kann ich aber mit 0.6.0 nur empfehlen! Ich werde demnächst meine 2 PCI-Karten rausschmeissen und eine zusätzliche DVBSKy S952 PCIe einbauen.


    Technisat Skystar S2


    Geht bei mir auch problemlos mit o.g. Setup.


    Die TechnoTrend TT-budget S2-1600 kann ich auch empfehlen, die ist eigentlich am unkompliziertesten und funktioniert seit Jahren problemlos.

    Ich habe Probleme mit dem Sound über HDMI bei meinem J1900. Ootb funzt es gar nicht, erst nach Aktivierung des SP-DIF (!) Ausgangs in alsamixer. Allerdings stottert der sowohl mit dem Trusty- als auch mit Wily-Kernel. Außerdem gibt es (nur) bei SD-Kanälen ein Offset zw. Bild und Ton.


    Funktioniert das mit den NUCs oder gibt es dort auch Probleme?


    Zum Vergleich: In MLD-5 (Kernel 3.16.x) funktioniert der Sound ootb.


    @yavdr-Team: Wie stellt ihr euch ein Hardware-Sponsoring vor? Soll ich euch ein Mainboard schicken?

    Das hat schon auf die gleiche Art und Weise (Neukompilieren des softhddevice + Anpassung Parameter) mit 0.5.0 funktioniert. Ich hatte noch nicht mal eine xorg.conf editiert. Allerdings hab ich nach Umstieg auf neuere Hardware (intel J1900) bedingt durch zu alte Softwarestände in yaVDR 0.5.0 einige Probleme gehabt und es nicht zum laufen bekommen, selbst mit neuem Kernel + Grafiktreibern etc. Bin deshalb erst mal auf MLD-5 umgestiegen, das funzt ootb! Werde jetzt mit 0.6.0 wieder einen Versuch starten.


    Ich denke, der Weg zu yaVDR mit vaapi-Support auf Basis von günstiger und vor allem ohne viel Aufwand auch lautloser intel-Technik ist nicht mehr weit! Ich sehe nicht so richtig einen Sinn drin, nur auf nvidia zu setzen. Auch die Bildqualität ist für mein Empfinden auf vaapi gut. Ich jedenfalls werde künftig eher auf vaapi setzen als auf vdpau, schon allein wegen der Systemkosten. Der beschriebene VDR-Client besteht bei mir nur aus Mini-ITX-Board (ASRock Q1900B-ITX), einer billigen SSD, einem Slot-In-DVD-Laufwerk (ja, ja, die Kinder wollen ständig DVDs schauen), einer ext. Stromversorgung über Pico-PSU und einem Atric-IR-Empfänger/Einschalter, das ganze in einem stinknormalen ITX-Gehäuse verbaut ohne zusätzliche Kühlung/Lüfter (also lautlos). Der auf dem Prozessor verbaute Kühler wird im Betrieb nicht mal handwarm...

    Bei mir läuft die S952 jetzt mit yaVDR 0.6.0 und vivid-Kernel (3.19) sowie installierter Firmware von DVBSKY direkt ootb, ohne media-build-dkms oder andere Kopfstände.

    Hallo,


    hier ein kurzer Erfahrungsbericht zu intel VA-API auf Basis von yaVDR 0.5 inkl. dem Update auf VDR 2.0.2:


    Nach dem mein VA-API System (siehe Sig.) seit (gefühlt) Jahren mit hohem WAF-Faktor lief, habe ich dort ebenfalls das Update auf VDR 2.0.2 durchgeführt.


    Nötige Änderungen an einem stinknormalen yaVDR sind:


    1. Einkompilieren VA-API Support in vdr-plugin-softhddevice, dazu Neukompilierung aus Quellen
    Änderung im Makefile:
    -#VAAPI ?= $(shell pkg-config --exists libva && echo 1)
    +VAAPI ?= $(shell pkg-config --exists libva && echo 1)


    Achtung: Das Paket muss halt auf HOLD gesetzt werden oder bei jedem Update neu aus den Quellen erstellt werden.
    Frage an das yaVDR-Team: Wird VA-API Support mit Absicht nicht einkompiliert? M.E. ging das bei den 1.7.x Paketen noch, da habe ich nichts neu kompiliert (kann mich aber auch täuschen).


    2. Änderung in /etc/vdr/plugins/plugin.softhddevice.conf, dazu Template erstellt /etc/yavdr/templates_custom/etc/vdr/plugins/plugin.softhddevice.conf/20_main mit Inhalt:
    -v va-api -D <?cs var:mixer ?>


    Anmerkung: Bei AMD-Systemen müsste der Inhalt so lauten:
    -w no-mpeg-hw-decoding -v va-api -D <?cs var:mixer ?>


    Die conf-Datei muss nach Anlegen des Templates natürlich neu erstellt werden...


    Die nvidia-Treiber sollten deinstalliert werden und dafür die Intel-Treiber bzw. va-api Kram:
    libva-intel-vaapi-driver


    Damit läuft das System erstmal grundsätzlich (auch keine Änderungen an xorg.conf etc. nötig).


    Ich habe jetzt skinnopacity am laufen. Damit funktioniert allerdings das "Verkleinern" das Video-Bildes beim Menueinblenden nicht. Aber das ist auch das einzige Manko, was ich bisher feststellen konnte. Alles zusammen sehr stabil (vielen Dank nochmals an das VDR und yaVDR Team!).


    Fazit: Ich ziehe das VA-API System mittlerweile dem Atom/Nvida vor... Es ist schon wesentlich performanter.

    Ich habe meist direkt nach dem Start des Clients das Problem, dass das RemoteTimers plugin den Server nicht findet... Aber 5 min. später funzt dann alles. Ursache ist mir momentan nicht klar...

    Das log sieht für meine Begriffe gut aus. VA-API wird initialisiert... Gibt allerdings noch ein Audio-Problem, aber das sollte nicht das Bild verhindern.


    Dann prüfe mal bitte die softhddev Optionen in der setup.conf (Änderungen nur bei gestopptem vdr machen :) )



    Meine Kiste ist übrigens kein G440, sondern ein G540; hatte ich schon verdrängt, weil er so gut läuft :)

    Mein Testsystem ist der G440, siehe Sig.
    Du musst die Änderung in softhddevice.conf erst mal update-sicher machen, sprich über ein Template.
    Hast du mal ein Restart des Frontends probiert? Ansonsten mal ins syslog schauen.

    Hier die top-Werte (alles mit BOB deinterlacer)


    ServusTV HD:


    ARD HD


    RTL (SD)


    Zum Vergleich: RTL (SD) mit Software Spatial deinterlacer

    Messen? Nicht powertop!

    Ja, ja, ich weiss schon :) Top(as) ist mein täglich Brot! Wobei, auf AIX ist es eher nmon...


    Seit heute hängt das System am 24" Monitor und hat schon den ersten 3 Stunden mit akzeptablem WAF überstanden :)

    Bei einer frischen Installation von yavdr 0.5a1 auf meinem SandyBridge System war nur diese Änderung in /etc/vdr/plugins/plugin.softhddevice.conf nötig:


    -v va-api -D


    Dann läuft es, keine fremden Pakete installiert oder so was...


    Bei meinem AMD System muss die Zeile wohl so heissen:


    -w no-mpeg-hw-decoding -v va-api -D


    Hab aber dort immer noch das Problem, dass ich das Plugin nicht an das Display :1 verbinden kann... Muss evtl. die Installation mal neu aufsetzen, ist schon ziemlich "zertestet" :)
    Wenn ich im X11 die VDR Frontend-INstanz manuell starte, geht es halbwegs. D.h. bei HD-Kanälen flimmert das Bild nach kurzer Zeit und bei (software-decodierten) SD-Kanälen läuft der Ton hinterher.


    htop-Werte mit dem SandyBridge System werde ich mal messen.


    johns: Super Arbeit! Kann man nicht oft genug sagen!