Posts by cyjoe

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hallo,

    ich habe auf Kernel 4.15 geupdatet (arch mit vdr4arch). Seitdem beschwert sich ddci2 mit:
    DDCI-Inf: no DD CI adapter found

    bei modprobe ddqbridge (redirect wurde noch nie durchgeführt):

    Pakete:


    vdr 2.3.3-1

    vdr-ddci2 1.0.1-2

    vdr-streamdev-server 0.6.1.r33.gb84b7d8-3

    vdr-vnsiserver 2:1.5.2-3

    vdr-xineliboutput 1.1.0.119.g2889fd9-5


    Wäre für Hilfe dankbar.

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

    Ich hatte ein ähntliches Problem vor längerer Zeit schon einmal:

    http://www.linux-kvm.com/content/pci-pa…devices-cine-s2

    Zwischenzeitlich habe ich die Hardware gewechselt, Danach funktionierte es.

    Ich habe nun wie in Thread (viel später) empfohlen im Gastsystem die Kerneloption pcie_pme=nomsi übergeben.

    Jetzt läuft das System seit gut 2 h stabil.

    Offensichtlich hat es also etwas mit MSI zu tun, jedoch erscheint es mir jetzt widersprüchlich, dass es anscheinend hilft, im Kernel MSI deaktivieren, obwohl die neuere Treiberversion MSI ohnehin nicht nutzt.


    Wenn Interesse besteht (und ich die Zeit finde), versuche ich eine paar Kombinationen einmal aus.

    Die letzte funktionierende Treiberversion weiß ich leider nicht. Es könnte Ende 2013 gewesen sein.

    Edit:
    Kernellog vom Original 3.2.0 Media-Stack: http://pastebin.com/nHwWtYFR mit I2C-timeout
    Kernellog vom zuletzt noch funktionierenden experimental Media-Stack: http://pastebin.com/4WST3mEs
    kein I2C-timeout

    Kernellog von aktueller Revision, mit I2C-timeout: http://pastebin.com/LE7CqaMw
    Kernellog von aktueller Revision, mit Kerneloption pcie_pme=nomis, seit mehr als 2 h stabil: http://pastebin.com/xDbZ2Zt4

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

    Hallo,

    bei mir läuft eine Octopus in einer virtuellen Maschine (kvm) mit intel vt-d, Host-Kernel 3.2.0-4-amd64 Debian wheezy, Gastsystem Ubuntu 1204 LTS 3.2.0-60 i686. Der VDR ist yavdr-unstable.

    Eigentlich lief die Karte seit 2012 stabil mit den media-build-experimental-Modulen.

    In KW13 habe ich aber yavdr upgedatet und auch das Treiberrepository. Seit dem läuft die Karte nicht mehr rund.

    Der Empfang funktioniert zunächst einwandfrei ohne Ruckler o.Ä. Nach einigen Minuten kommt dann auf dem Gastsystem die Kernelfehlermeldung:

    Mar 28 17:56:59 vdr kernel: [ 626.112147] DDBridge I2C timeout, card 0, port 0
    Mar 28 17:56:59 vdr kernel: [ 626.112343] drxk: i2c write error at addr 0x2a
    Mar 28 17:56:59 vdr kernel: [ 626.112525] drxk: Error -5 on SetQAM64
    Mar 28 17:56:59 vdr kernel: [ 626.112677] drxk: Error -5 on SetQAM
    Mar 28 17:56:59 vdr kernel: [ 626.112822] drxk: Error -5 on Start
    Mar 28 17:56:59 vdr kernel: [ 626.556538] drxk: SCU not ready
    Mar 28 17:56:59 vdr kernel: [ 626.556681] drxk: GetQAMLockStatus status = fffff


    Die Fehlermeldungen
    Mar 28 17:57:00 vdr kernel: [ 627.788884] drxk: Error -5 on GetLockStatus
    Mar 28 17:57:01 vdr kernel: [ 628.096606] drxk: SCU not ready
    Mar 28 17:57:01 vdr kernel: [ 628.096737] drxk: GetQAMLockStatus status = fffffffb

    wiederholen sich fortan sehr kurzen Intervallen und spammen das log zu.


    Irgendwann stürzt dann auch der Treiber ab.

    Hat sich irgend etwas verändert? Ist der Treiber zickiger geworden, was die interrupts angeht?

  • [ANNOUNCE] UPnP-AV/DLNA-Plugin für den VDR (0.0.2-alpha)

    Ich suche gerade eine Lösung um günstig ein Badezimmer- oder Küchenradio mit VDR als Server zu realisieren. Da erscheint mir das UPNP-Plugin von VDR als geeignet. Allerdings sieht es so aus, als würde die Entwicklung weitgehend stillstehen. Hat dieses Plugin eine Zukunft oder gibt es eine Alternative?

    Ich wollte es zunächst einmal ausprobieren und versuche, auf meinem VDR-Rechner unter Debian testing AMD64 und vdr-1.7.20 das Plugin zu kompilieren.

    Dabei stieß ich zunächst auf den Fehler, dass das Makro UINT64_C nicht deklariert ist. Dies ließ sich durch
    #define __STDC_CONSTANT_MACROS
    in den entsprechenden Quelldateien umgehen.

    Jetzt kommt der Fehler CodecType has not been declared in avdetector.h
    und in den includierten Headern finde ich auch keinen CodecType...

    Ich bin selber kein erfahrener Entwickler, aber ich würde gern etwas mithelfen, Interesse und Unterstützung vorausgesetzt.

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

    Ich nochmal,

    Auch in einer Ubuntu-VM mit yaVDR-vdr testing das gleiche Problem. Nach ein Paar Minuten z.B.

    I2C timeout
    IRS 00000201
    drxk: i2c write error at addr 0x2a

    drxk: write_block: i2c write error at addr 0x831ffd


    wobei die Adressen variieren

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

    Hallo,
    habe ein Problem mit der ngene duo-flex c-t

    verwende den aktuellsten Treiber wie im ersten Posting beschrieben unter debian wheezy, Kernel 2.6.39 in einer virtuellen Maschine mit kvm (hardware pass-through vt-d)

    Es gab immer wieder Abstürze mit der Fehlermeldung i2c timeout. Seit update auf wheezy und neueste Treiberversion sind diese jedoch nicht weniger sondern deutlich mehr geworden. Ich kann einige Minuten fernsehen, dann stürzt der Treiber ab und der Bildschirm wird schwarz. Der VDR läuft weiter. Nach einem reboot der VM geht es wieder für ein paar Minuten, dann ist wieder Schluss

    Die Fehlermeldung lautet:
    [ 1167.604052] I2C timeout
    [ 1167.605902] IRS 00000301
    [ 1167.606487] drxk: i2c write error at addr 0x2a
    [ 1167.607177] drxk: write_block: i2c write error at addr 0x831ffd

    ich habe einen Blick in den Code geworfen. Die Funktion wait_event_timeout erreicht ihr timeout während sie auf i2c->done wartet. Vorher wird ddbwritel aufgerufen. Ich habe das Timeout bereits auf 50*HZ erhöht, das bringt jedoch keine Änderung. Das Kommando cmd war bei den Abstürzen, die ich beobachtet habe 1 oder 2. Leider kann ich sonst nicht viel mehr mit dem code anfangen.

    Grüße
    J

    Ah ja:
    wenn kein Signal kommt, stürzt der Treiber auch nicht ab. Evtl handelt es sich auch um ein I/O-Performanceproblem.

    Noch ein Update:
    habe nun return -EIO durch return 0 in der Abfrage if(stat<=0) ersetzt. Jetzt kann man nach einem timeout einfach weiterschauen.

  • nach Umzug leider nur noch DVB-C - welche Karte?

    Vergibt Kabel Deutschland explizit Karten für ein AlphyCrypt? Bislang brauchte man dazu eine (generierte) Seriennummer eines zertifizierten Receivers, der darüberhinaus nur die D02-Karten unterstützt, da die D09-Karten mit den Alphacrypts nicht funktionieren.

    Zu dem ganzen Aufwand gibt es eine illegale Softwarealternative, die jedoch wunderbar und recht unkompliziert funktioniert.

    Leider scheint aufgrund der Grundverschlüsselung der Privatsender und der Weigerung KDs, die CA-Module zu zertifizieren, der Markt an DVB-C-Karten weitgehend tot zu sein. PCIe-Karten sind laut Anfrage bei Satelco zwar "geplant" aber ich glaube nicht mehr daran. Ich bin überhautp sehr besorgt um die Zukunft frei und legal empfangbaren Fernsehens via Computerhardware.

  • IGP Geforce 8x00 vs. 9x00

    Gibt es eine Möglichkeit, dass xine randr nutzt um die Auflösung sowie Bildwiederholfrequenz des Displays der des Quellmaterials anzupassen?

    Dann bekäme der Fernseher bei SDTV eben ein interlacetes oder auch deinterlacetes Filmmaterial und die TV-eigenen Bildbearbeitungsschritte könnten greifen.

    Denn wenn der Fernseher ein 1080p/60Hz-Signal erhält, wird er diese natürlich nicht anwenden. Wahrscheinlich sollte man diese dann sogar abstellen, denn der Fernseher kännte es für das Signal eines Blu-ray-Players halten, den 3:2-Pulldown herauszurechnen versuchen und und und ...

  • IGP Geforce 8x00 vs. 9x00

    Anhand von Screenshots wird es schwer möglich sein, die Darstellungsqualität auf einem LCD-Fernseher zu beurteilen.

    Was derzeit in Software wohl gut geht ist Deinterlacing und ggf. Upscaling.

    Nicht vermeidbar ist momentan jedoch die Bewegungsunschärfe. Die liegt in der Art der Bilderzeugung von LCDs und der Wahrnehmung durch das menschliche Auge begründet. Um dies zu vermeiden, benötigt man wohl die Bildaufbereitung durch Zwischenbildberechnung moderner 100Hz-Fernseher (oder einen Plasma-TV). Derartiges gibt es (noch) nicht in frei verfügbarer Software.

  • IGP Geforce 8x00 vs. 9x00

    Blu-ray ist und bleibt in absehbarer Zeit Standard für HD-Inhalte.
    Technisch ist es zur Zeit möglich, Blu-rays auch unter Linux abzuspielen - allerdings illegal und ganz sicher nicht komfortabel.

    Es ist nicht abzusehen, dass zukünftige Grafikkarten-Generationen HD-Inhalte in irgend einer Art und Weise besser darstellen können als die aktuelle Generation. Schnell genug sind sie und die alle nötigen Features sind enthalten - insofern ist es nicht sinnvoll, zu warten.

    Allerdings bleibt abzuwarten, welche Lösung sich unter _LINUX_ als die ideale herauskristallisiert.

    Momentan scheint nvidia mit VDPAU die Nase vorn zu haben.
    ATI wird jedoch nachziehen.
    Was mit intel ist, weiß ich nicht.

    Wenn man auf Open-Source besteht, ist nvidia aus dem Rennen - jedoch gibt es _momentan_ keine zufriedenstellende OS-Alternative zu VDPAU. ATI steht Meiner Meinung nach Open-Source-mäßig am besten da. Insofern kann es durchaus sinnvoll sein, abzuwarten.

    Ich tendiere momentan zu einem AMD 690G-Board mit Onboard-HDMI sowie einer günstigen nVidia-Karte mit VDPAU-support. Das macht vielleicht 20 Extra-Watt in der Leistungsaufnahme, ist aber am flexibelsten.
    Und sobald die ATI-Lösung ausgereift ist, fliegt die nVidia-Karte einfach raus und gut ist.

    Was mich jetzt noch interessiert ist, was mit der SD-Bildaufbereitung für die Wiedergabe bei 60Hz und 1080p-Auflösung ist. Deinterlacing unterstützt VDPAU ja in Hardware. Wie sieht es mit Upscaling aus?
    Gibt es soetwas wie eine Zwischenbildberechnung?

    Moderne Fernseher betreiben intern ja sehr hohen Aufwand dazu und sind dabei mittlerweile durchaus erfolgreich (Auf den neuen Sonys soll analoges Kabel auf 52" durchaus ansehnlich sein).

    Wenn man jedoch ohnehin einen PC zur Signaleinspeisung nutzt, sollte meiner Meinung nach auch dort das Bild bestmöglich aufbereitet werden.

  • IGP Geforce 8x00 vs. 9x00

    Ich habe gehört, dass sich die geforce 8x00 und 9x00 Mainboard-Chipsätze in ihrer Graphik-Einheit nicht unterscheiden - ich glaube jedoch der 9x00er ist in einem kleineren Fertigungsprozess ausgeführt, da bin ich mir aber nicht sicher.

    Fakt ist, dass derzeit die schwächste, VDPAU unterstützende Grafiklösung ausreicht, um mit einer billigst-CPU für gewisse HD-Inhalte gerüstet zu sein (http://www.phoronix.com/scan.php?page=article&item=nvidia_vdpau_gpu&num=1).

    VDPAU ist jedoch anscheinend noch nicht uneingeschränkt einsatzfähig. Es gibt wohl Video-Formate, die sich nicht beschleunigt abspielen lassen. Daran wird zwar gearbeitet, aber niemand garantiert, dass VDPAU irgendwann wirklich alles denkbare abdeckt - insbesondere deshalb, weil es eine Closed-Source-Lösung ist.

    Beim Open-Source-Treiber ist ATI nVidia weit voraus und es ist zu erwarten, dass es bald Videobeschleunigung (jedoch nicht so umfangreich wie bei VDPAU) im radeon-Treiber geben wird (ein Entwickler äußerte sich dazu letzt im Phoronix-Forum). Momentan sieht es jedoch noch ganz schlecht aus, da nichteinmal der HDMI aktueller ATI-Karten und Onboard-Chips voll einsatzfähig ist (http://www.phoronix.com/scan.php?page=article&item=linux_hdmi&num=1).

    Für den Closed-Source-Ati-Treiber gelten dieselben Bedenken wie für den nVidia-Treiber. Es wird entwickelt, aber keiner weiß so recht, wohin das führen wird.

    Ich bin da auch in einer Zwickmühle.
    Ich brauche demnächst einen neuen VDR, bevorzugt "HD-Ready".
    Es gibt die - sagen wir - dreviertel-gare nVidia-Lösung, die sich jedoch als Sackgasse herausstellen kann. Und es gibt die nur ansatzweise verfügbare, jedoch vielversprechende Open-Source-ATI-Lösung.

    Daher schließe ich mich meinem Vorredner an. Abwarten.