Posts by frispete

  • DD Max S8 an VDR: Probleme mit Aufzeichnungen

    Quote from Uwe

    Über Sat gibt es nur UHD, 1080i25, 720p ... 1080p25 sagt mir nix. Wird hier eventuell etwas falsches erkannt?

    Nope, sorry, ich meinte dann 1080i25 (1080p25 ist die naheliegenste Entsprechung in HandBrake..)

    MPEG-TS wird zuverlässig erkannt, nur mit ganz ganz alten MPEG2 Streams gibt es manchmal Schwierigkeiten (ab dann stürzt ffmpeg/HB komplett ab. Ich habe bislang einen solchen Vorfall gefunden in meinem > 10 TB großen Filmarchiv).

  • DD Max S8 an VDR: Probleme mit Aufzeichnungen

    Hi,

    ich kämpfe mit einem Problem, und komme einfach nicht weiter - Kurzversion: VDR zeichnet im Server auf ohne zu murren, beim Umwandeln des MPEG TS streams in MP4 meckert HandBrake über die Eingangsdaten, die sich als Encoding-Artefakte (blockige Störungen, Audioverzerrungen) bis hin zu Dropouts im Sekundenbereich bemerkbar machen.

    Environment: openSUSE 15.1, Kernel 5.4.14, nativer Max S8 Treiber, VDR 2.4.1, HandBrake (current git), ffmpeg 4.2.2

    Typische HandBrake Meldungen:

    Die Stellen an Positionen 1,48%, 1,56% 7,41% usw. haben dann Störungen.

    Wenn man im Kernel die dvb_core debug messages aktiviert, erscheint:

    Ich habe schon alle möglichen ddbridge Optionen versucht (fmode=0|1|2, dma_buf_num=16, dma_buf_size=32), leider ohne Erfolg.

    Hier die Treiber boot Meldungen:

    Die Karte hat die aktuelle FW, ihren eigenen Interrupt, das System hat kein Swap aktiviert, und läuft auf einem Xeon X3460 @ 2.80GHz mit 24 GB RAM.

    Die offiziellen DD Treiber funktionieren leider gar nicht (es kommt keine Aufzeichnung zustande, evnt. wegen des recht neuen Kernels, habe ich bislang nicht weiter untersucht).

    Code
    <6>[    0.310602] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
<6>[    0.310607] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier


    Keine weiteren sysctl's, aber transparent_hugepage=never ist gesetzt.

    Die Auslastung ist moderat. Die Probleme betreffen alle Aufzeichnungen, bei Älteren und SD seltener, mit 1080p25 via CAM vermehrt.

    Irgend jemand eine Idee, was hier schief läuft, und wie dass in den Griff zu kriegen ist?

    Danke schon mal im Voraus,

    Pete

  • Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

    Quote from fnu

    Bau die MaxS8 in einen Octopus Net Kit für SAT>IP ein, ist dann auch flexibler:

    - DigitalDevices DVB-S2 MaxS8 goes Octopus NET (SAT>IP mit 4/8 Tunern)

    Danke für den Link. Das Produkt kannte ich noch nicht.

    DIe Idee, daraus eine SAT>IP Lösung zu bauen ist schon sehr verlockend. ;)

    Quote from fnu

    Herr McPherson respektiert leider nur die Meinung von Herrn McPherson ..

    Nach einem längeren Telefonat mit ihm kann ich sagen: er ist sehr nett, kompetent, und hat letztlich die entscheidende Idee geliefert. :thumbup:Nach Umstecken von einem PCIe x4 in einen PCIe x 16 Port funzt die MaxS8 wieder einwandfrei. :rolleyes:

    Warum sie jahrelang im anderen Port problemlos funktionierte und mit dem neuen Kernel nach einem x16 Port verlangt, bleibt wohl den Untiefen der PC-Architektur geschuldet. (Hier mit msi=0). Funktioniert MSI hier bei euch (mit älteren MaxS8 Revisionen) und bringt es einen Vorteil?

    @DD-Developer: was an der Sache noch verbesserungswürdig ist: ich gehe mal davon aus, dass der Treiber sehr wohl irgendwo gemerkt hat, dass etwas nicht stimmt (sieht ja stark nach frame-losts aus). Schön wäre es, wenn er dann (rate-limited) Fehler/Hinweise ausgeben könnte, am Besten aktivierbar per Modul-Option... Solche Fehler können einen in den Wahnsinn treiben.

    nst: Ich freue mich mich sehr darauf, diesen Treiber bald im Mainline Kernel zu finden.

    Das ist ein Meilenstein in der fortgeschrittenen Linux-Multimedia Unterstützung und irre viel Arbeit, die Du da hineingesteckt hast.

    Cheers,

    Pete

  • Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

    Hi nst

    Quote from nst

    Der linux-media Maintainer hat - bis auf eine Kleinigkeit, die aber keinem in der Praxis wirklich weh tun wird - ALLE(!) Patches, die sich im Laufe der Zeit "entwickelt" haben, in den Kernel gemerged. Mit anderen Worten: Linux Kernel 4.14, beginnend ab rc1, wird ddbridge in Version 0.9.31 mit vollständigem (CI-Bridge und MaxS8(!) inklusive) Kartensupport enthalten. Alle Digital Devices Tunerkarten und Flexmodule werden dadurch OotB funktionieren!

    Chapeau!

    Ich werde versuchen, die Sachen mal in einen 4.12 Kernel rückzuportieren, weil hier meine ganze Familie schon am Rad dreht wegen einer MaxS8, die nach Kernel-Update nicht mehr richtig funktioniert.

    Nachdem ich die MaxS8 seit 2 Jahren mit einem selbstgebackenen 4.2.5 und Oliver Endriss' experimental driver (ddbridge 0.9.18) weitgehend problemfrei einsetzte, war es aus verschiedenen Gründen an der Zeit, den Kernel zu aktualisieren. Da die experimental driver für aktuelle Kernel nicht mehr passen, fiel die Wahl auf dddvb 0.9.29 mit Kernel 4.11.11. Und siehe da, das Ergebnis war unbrauchbar. Kontinuierliche Pixelstörungen und Bewegungsartefakte im Sekundentakt. Zurück zu 4.2.5: alles bestens.

    Damit habe ich mich an den DD Support gewendet. Der hat nach einigem Hin und Her die Lösung gefunden: Firmware-Update!

    Vorher: DDBridge: HW 01010004 REGMAP 00010001

    Nachher: DDBridge: HW 0101000c REGMAP 00010002

    Es kam, wie es kommen musste. Nach der FW-Aktualisierung gab es die Störungen jetzt auch unter 4.2.5. :( Vielleicht wäre besser gewesen, Deinen Treiber zu verwenden, der z.Z. keine FW-Aktualisierung zulässt. 8o (Kidding)

    Aus nicht nachvollziehbaren Gründen versagt der DD Support nun aber den FW downgrade, sodass ich jetzt mit einem dysfunktionalen VDR dastehe (naja, der VDR funktioniert, nur sind die Sendungen/Aufnahmen hat nicht genießbar ;(). Ich baue gerade einen 4.12.8 mit ddbridge 0.9.31. Mal sehen, was da rauskommt.

    Ach ja, DD Support, Herr McPherson kann meine Argumentation, dass etwas faul im aktuellen FW-Stand ist, nicht nachvollziehen, und vermutet einen woanders gelagerten Software Fehler. ?(

    @* Kennt hier schon jemand dieses Verhalten? Welche FW Stände benutzt ihr? Ist vielleicht nur der letzte/die letzten DD FW Stand/Stände problematisch. Natürlich veröffentlicht DD nicht das Revisionslog der FW, somit bleibt nur trail & error.

    Wie verhält sich eure MaxS8, wenn der Rechner unter Last steht?

    HW: Xeon X3460, 24 GB RAM, ASUS P7F-E Motherboard, Areca ARC 1882IX-16 Hardware-RAID 5 mit HGST-Server Platten

    SW: heavily tweaked openSUSE 13.2, Kernel s.o., XFS FS, vdr 2.2.0

    VDR und vieles andere baue ich selbst auf dem OBS: z.B hier: https://build.opensuse.org/project/monitor/home:frispete:vdr


    Cheers,

    Pete

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT, MAX S8 sowie TT S2-6400 (Teil 3)

    Hi Mike,

    Looks, like your kernel build is flawed in some way, but without further details, it's hard to tell you much more.

    READ_ONCE is defined in compiler.h, and was added rather lately. Do you have build rudiments from older kernels lying around?

    Did you made a make mrproper after saving away your config? make oldconfig?

    Cheers,
    Pete

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT, MAX S8 sowie TT S2-6400 (Teil 3)

    Quote from UFO

    Hatte ich auch schon einmal auf einem 32-Bit System. Aus irgendeinem Grund scheint es da einige Funktionen nicht zu geben. Da ich keine Lust hatte, mich durch Kernel und Upstream-Treiber zu graben, habe ich "CONFIG_OF" in v4l/.config und v4l/.myconfig deaktiviert...


    Hmm, der Fehler stammt von einer Kernel-Build Variante (i386/desktop), die CONFIG_OF und Konsorten gerade nicht aktiviert hatte.

    Quote

    Eine sauberere Methode wäre, alle Treiber, die von "OF" abhängen, per "make menuconfig" zu deaktivieren...

    Offenbar ist dies bei x86_64 builds der Fall, da ist CONFIG_OF auch nicht gesetzt.

    Sollte sich der xilinx Modul build nicht selbst auch auf diese Umstände adaptieren?
    Ich könnte den Verantwortlichen ja mal einen entsprechenden Hinweis geben, wenn ich Dein Okay habe, dass ich damit den richtigen Baum anbelle...

    Habe jetzt erst mal CONFIG_OF und Co. aktiviert für die fehlerhafte Variante, da es der minimalinvasivste Eingriff in die Kernelbuilds war.
    Mal sehen, was dabei raus kommt, Kernel build dauern auf OBS.. ;(

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT, MAX S8 sowie TT S2-6400 (Teil 3)

    Hallo Oliver,

    ich bin einer der vermalledeiten Schmarotzer, die Deinen Build nutzen - sehr zu meinem Vorteil..

    Weil ich aber nicht nur rum schmarotzen will, baue ich media-build-experimental auf dem openSUSE build service.

    Eines meiner Targets ist der aktuelle Kernel 4.1. Und hier gibt's für 32bit Builds ein Problem:

    Code
    [ 1835s] /home/abuild/rpmbuild/BUILD/media_build_experimental-hg20150509_0729/obj-desktop/xilinx-tpg.c: In function 'xtpg_parse_of':
[ 1835s] /home/abuild/rpmbuild/BUILD/media_build_experimental-hg20150509_0729/obj-desktop/xilinx-tpg.c:728:3: error: implicit declaration of function 'of_node_cmp' [-Werror=implicit-function-declaration]
[ 1835s]    if (!port->name || of_node_cmp(port->name, "port"))
[ 1835s]    ^

    Siehe auch https://build.opensuse.org/package/live_b…nSUSE_13.2/i586

    YFYI.

    Danke für Deine fantastische Arbeit.

    Pete