Beiträge von sebixvi

    Also nach der Ausgabe von vdr -Psofthddevice -h lautet die Syntax "-w <workaround>", wobei <workaround> die von Dir genannten Werte annehmen kann. Allerdings konnte ich weder mit "-P softhddevice -wno-mpeg-hw-decoder noch mit -w no-mpeg-hw-decoder irgendeinen Unterschied feststellen. Hd fluppt, SD hat ein stark verwaschenes Zeitlupenbild.


    Zum ausführlichen Testen komme ich frühestens am Wochenende, dann vielleicht mehr.


    Ciao,
    Sebastian

    Hi johns,


    den von Dir genannten Thread hatte ich gelesen. Dabei ist mir aufgefallen, dass Du bei Deinen Tests SD sehen konntest, andere User aber ebenfalls von schwarzen Bildschirmen oder ähnlichen Problemen bei SD berichtet haben - eine Lösung war leider nicht dabei.


    Vdpauinfo gib jedenfalls an, dass MPEG1/2-Support aktiv wäre. Wie kann ich denn einzelne Hardware-Decoder am schnellsten selektiv ausknipsen?


    Danke,
    Sebastian


    Das liest sich für mich, als würde das alles passen. Softhddevice meldet auch keine Fehler. Das einzige, was mir aufgefallen ist, ist die Meldung "libav buggy, use ffmpeg". Aber das dürfte ja erstmal unabhängig von der Ausgabe sein.


    Sebastian

    Hallo zusammen,


    ich habe gestern mal ausprobiert, wie gut ATI-Hardware (HD6310) inzwischen mit vdr / softhddevice klarkommt. Hier meine Vorgehensweise:


    Hardware: Asrock E350 M1, 2GB RAM, DVB: streamdev-client, 32GB SSD


    Installation über USB-Stick vom yaVDR 0.5a-Hybridimage. Nach dem Neustart Kernel 3.10 installiert:


    Code
    $ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/linux-headers-3.10.0-031000_3.10.0-031000.201306301935_all.deb
    $ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/linux-headers-3.10.0-031000-generic_3.10.0-031000.201306301935_amd64.deb
    $ wget -c kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/linux-image-3.10.0-031000-generic_3.10.0-031000.201306301935_amd64.deb
    $ dpkg -i *.deb


    (Quelle: http://linuxg.net/how-to-insta…int-debian-and-derivates/)


    und den Rechner neu starten. Jetzt müssen noch die neuen Grafiktreiber installiert werden:


    Code
    $ sudo add-apt-repository ppa:oibaf/graphics-drivers
    $ sudo apt-get update
    $ sudo apt-get dist-upgrade
    $ sudo service vdr restart
    $ sudo service openbox restart


    Jetzt habe ich noch den streamdev-client installiert und eine bekannte channels.conf eingefügt. Und voilá - ich kann HD-Sender (ARD bzw. ZDF HD, also 720p) ohne Probleme und mit niedriger CPU-Last (vdr hat ca. 20-30%, X.org hat 5%) sehen.


    Allerdings ärgern die SD-Sender: Das Bild ist verwaschen und mit Blockartefakten versehen, außerdem läuft es in Zeitlupe. Eine Änderung der Einstellungen für 576i, 720i brachte nix (Deinterlace aus, Scaling "normal"). Stelle ich auf vdr-sfxe um, habe ich den umgekehrten Fall - SD läuft leidlich, HD gar nicht.


    X.1.log meldet im Übrigen sowohl DRI2, VDPAU als auch UVD als funktionierend, ich gehe also davon aus, dass die Beschleunigung funktioniert. Und die HD-Last unter Softhddevice bestätigt das.


    Habe ich noch Stellschrauben übersehen? Die Kiste wäre für eine kleine Streaming-Box ideal....


    Schönen Abend,
    Sebastian

    Ich werde mal sehen, ob ich mich da reinfuchsen kann. Vermutlich werde ich erstmal eine Kiste mit gen2vdr aufsetzen, damit die ganzen Quellen und dev-Pakete installiert sind. Mein gestriger Versuch, das Softhddevice-Plugin auf einem frischen yaVDR zu installieren, zog erstmal eine Orgie von dev-Paket-Installationen nach sich...


    Ich habe übrigens keine besondere XBMC-Version installiert, sondern ein aktualisiertes yaVDR 0.5 mit dem enthaltenen Frodo benutzt. Darauf habe ich lediglich den aktuellen Catalyst-Treiber installiert und eine Verbindung per xvdr (für XBMC) bzw. streamdev-client zum derzeit aktuellen Wohnzimmer-PC hergestellt, um dessen CineCT anzuzapfen.


    Ansonsten Overscan einstellen und die Tearing-Option, danach war die Bildqualität (mit XBMC) subjektiv vergleichbar zur NVidia-Lösung.


    Sebi

    Hallo,


    die Probleme mit ATI und deren Treiber sind ja hinlänglich bekannt. Ich kann auch gut verstehen, dass die Entwickler (Danke Johns!) keine Lust haben, da ständig hinterher zu rennen, zumal xvba-video ja nun schon länger nicht mehr aktualisiert wird.


    Ich habe deiser Tage auf einem schnuckligen kleinen Asrock E350 mit SSD mal yaVDR installiert. Mit einer Nvidia-Karte zusätzlich lässt sich ein schöner kleiner STreaming-Client aufbauen. Natürlich musste ich auch mal die Onboard-Lösung testen.


    Dabei ist mir aufgefallen, dass mit xine / xineliboutputplugin gut fern gesehen werden kann, allerdings mit mittelmäßiger Bildqualität. Dafür funktioniert selbst HD.


    Beeindruckt war ich aber von XBMC. Hier konnte ich - am Monitor, nicht am Beamer - keine nennenswerten Unterschiede zur NVidia-Lösung feststellen. Ein bißchen Nachlesen ergab, dass die XBMC-Developer offenbar xvba direkt unterstützen und auf den Wrapper xvba-va verzichten.


    Könnte man sich da nicht dranhängen?


    Sebi

    Hallo,


    ich möchte die Tastenbelegung beim Abspielen von Videos ändern. Die FB selbst (MCE remote) funktioniert einwandfrei. Die Tasten (up/down, left/right) ebenfalls.


    Wenn ich eine Aufzeichnung wiedergebe, wird links/rechts als "fast forward" bzw. "fast rewind" interpretiert. Ich würde das gerne so ändern, dass hier "skip fwd" bzw. "skip back" (also Springen im Video vor/zurück) ausgeführt wird.


    Wenn ich die Belegung komplett ändere, kann ich im Menü nicht mehr eine Seite vor und zurück springen, deswegen würde ich das gerne vermeiden.


    Vielen Dank,
    Sebi


    Hm - Wackelkontakt/ungünstige Verlegung des Datenkabels käme auch noch in Frage.

    Hallo,



    auch ich habe diesee I2C-Fehler, danach ist die Karte bis zum nächsten Neustart unbrauchbar. Nachdem ich erst die Verbindung zum CAM in Verdacht hatte, weil es (hauptsächlich) grundverschlüsselte Privatsender (Unitymedia) betraf, habe ich mein Setup jetzt geändert:


    - Cine CT V6
    - kein CAM, daher auch keine Kabelverbindung


    Jetzt treten die Fehler hier - nachvollziehbar - hauptsächlich bei ZDF HD auf, da aber recht regelmäßig. Ich nehme Samstags und Sonntags morgens immer ZDF tivi auf, in ca. 60% der Fälle bricht die Aufnahme nach wenigen Minuten ab.


    Gibt denn "IRS 00000301" einen Hinweis, wo es kracht?


    Die weiteren Meldungen bzgl. drxk habe ich nicht im Log. Kernel ist 3.2.0-30-generic, Treiberversion aktuell aus dem linux-media-dkms-Paket (0~20120810.git285.323772~precise).


    Sebi

    Hallo,


    ich benutze seit einigen Wochen die 0.5 und bin begeistert! Lediglich der Ton bereitet mir Kopfzerbrechen.


    Die Ausgabe erfolgt auf alle angeschlossenen Devices (Standardeinstellung per Webfrontend), dies sind SPDIF (optisch) und HDMI (GF210).


    Das funktioniert soweit, allerdings gibt es nach einiger Zeit Aussetzer. Das Log sagt:


    Jun 25 23:29:51 dumbledore vdr: video: 0:52:34.293 +19 1098 0/\ms 100 v-buf
    Jun 25 23:30:51 dumbledore vdr: video: 0:53:34.293 +19 1130 0/\ms 101 v-buf
    Jun 25 23:31:51 dumbledore vdr: video: 0:54:34.313 +39 1066 0/\ms 98 v-buf
    Jun 25 23:32:51 dumbledore vdr: video: 0:55:34.293 +19 1098 0/\ms 100 v-buf
    Jun 25 23:33:51 dumbledore vdr: video: 0:56:34.293 +19 1098 0/\ms 100 v-buf
    Jun 25 23:34:51 dumbledore vdr: video: 0:57:34.293 +19 1130 0/\ms 101 v-buf
    Jun 25 23:35:00 dumbledore vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'
    Jun 25 23:35:51 dumbledore vdr: video: 0:58:34.093 +40 1094 0/\ms 98 v-buf


    am Receiver sehe ich aber, dass der optische Ausgang teilweise abgeschaltet wird (es blinkt "Unlock" im Display). Erst ist es nur ein kaum hörbares Kratzen, dann gibt es kurze Aussetzer von knapp 1s, dann werden die Pausen länger und der Ton ist nur noch abgehackt zu hören. Nach ein paar Sekunden ist der Ton dann wieder normal (nach der "wait underrun error"-Meldung).


    Pause/Play oder Umschalten behebt das Problem, bis es nach ein paar min. wieder auftritt (ca. 10-20min).


    Hardware ist ein Scaleo Evi, die Soundkarte benutzt den snd_hda_intel-Treiber.


    Hat nochjemand das Problem?


    Danke,
    Sebi

    Nachdem ich irserver.conf abgeändert und nur


    Code
    start on start-irserver


    stehengelassen habe, wird irserver nicht mehr gestartet und ich habe ruhe. Allerdings weiß ich natürlich nicht, ob's damit auch bei denjenigen funktioniert, die die entsprechende Hardware haben.


    Grüße,
    Sebi

    Also irserver sollte eigentlich nur aufgrund des Upstart-Signals "start-irserver", das von der udev-Regel in /lib/udev/rules.d/98-eventlircd4irserver.rules ausgelöst wird, gestartet werden.


    Mir ist da nicht ganz klar, warum da bei dir ein Startversuch gemacht wird - die udev-Attribute sollte ja eigentlich nicht passen...
    Aber du kannst gerne mal mittels udevadm info nachsehen: http://www.yavdr.org/documenta…e/ch02s03.html#udev-tools


    Hmm, könnte das mit /etc/init/irserver.conf zusammenhängen? Dort steht ja


    Code
    start on start-irserver or resume


    D.h., nach dem Resume (bei mir S3) wird irserver in jedem Fall gestartet, was natürlich blödsinn ist. Wenn irserver über 98-eventlircd4irserver.rules gestartet wird, müsste doch ein Eintrag in /etc/init überflüssig sein, denn die udev-Regeln müssten ja auch beim Resume ziehen, oder? Zumindest sollte "start on start-irserver" ausreichen.


    Sebi


    Verstehe ich das richtig, dass du obwohl du keinen irserver-kompatiblen Empfänger hast, den Dienst in der /etc/yavdr/force-reload-services.list eingetragen hast?

    Nein, /etc/yavdr/force-reload-services.list gibt es bei mir gar nicht. Ich habe an den Fernbedienungs-Services nichts geändert. Ich benutze eine X10, allerdings hat mein Scaleo EVi-Gehäuse auch einen IR-Empfänger, der von yavdr offenbar erkannt und eingebunden wird. Vermutlich kommt daher das Problem? Der Empfänger wird per mceusb erkannt und initialisiert:


    Code
    [33155.389420] Registered IR keymap rc-rc6-mce
    [33155.389547] input: Media Center Ed. eHome Infrared Remote Transceiver (1509:9242) as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/rc/rc4/input4844
    [33155.389621] rc4: Media Center Ed. eHome Infrared Remote Transceiver (1509:9242) as /devices/pci0000:00/0000:00:1d.2/usb7/7-2/7-2:1.0/rc/rc4
    [33155.390255] input: MCE IR Keyboard/Mouse (mceusb) as /devices/virtual/input/input4845
    [33155.390415] rc rc4: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
    [33155.535203] input: lircd as /devices/virtual/input/input4846
    [33155.624021] mceusb 7-2:1.0: Registered FIC eHome Infrared Transceiver with mce emulator interface version 1
    [33155.624027] mceusb 7-2:1.0: 2 tx ports (0x1 cabled) and 2 rx sensors (0x1 active)
    [33155.624069] usbcore: registered new interface driver mceusb


    Sebi

    Hmm,


    bei mir nicht. Logfile sagt:


    IRServer64 Version 6.03.08
    No IRTrans Devices found.
    Aborting ...


    Yavdr 0.5 default installation, FB ist eine X10 (Pollin-FB), die funktioniert (auch ohne irserver). Ist also nur kosmetisch, da das Logfile zugemüllt wird.


    Sebi


    Afaik habe ich am Kartentreiber im fraglichen Zeitraum nichts geändert, was Einfluß auf das CI haben könnte:
    Vgl. http://linuxtv.org/hg/~endriss/ngene-octopus-test/


    Könnte natürlich sein, daß es upstream in dvb-core eine Änderung gegeben hat. Diese müßte allerdings auch andere Karten mit CI betreffen.


    Kannst Du probehalber den alten Treiber noch einmal aktivieren, um zu testen, ob das Problem damit tatsächlich verschwindet?


    CU
    Oliver
    Hallo Ufo,


    ich kenne mich leider mit GIT zu wenig aus, um auf einen bestimmten Stand zurückrollen zu können. Da ich das Repository komplett gelöscht und mit den Anweisungen im ersten Post den Treiber komplett neu ausgecheckt habe, müsste ich die alte Version auschecken, um diese dann einbauen zu können. Und ich habe inzwischen auf yavdr 0.5 aktualisiert. Das Problem sollte aber vom Kernel unabhängig sein, da es IMHO den I2C-Link zwischen ddbridge und CI betrifft. Dieser dürfte ja nur vom ddbridge-Treiber verwaltet werden.


    Möglich wäre allerdings auch, dass ein WLAN-Treiber o.ä. sich geändert hat. Ich habe das CI im Scaleo Evi-Gehäuse hinter dem CI-Schacht eingebaut. Direkt unter dem Schacht liegt die WLAN-Karte, ein Antennenanschluss ist ungenutzt und strahlt daher offen in Richtung CI ab. Diese Karte habe ich nun entfernt, seither ist ruhe (die Kiste hängt eh per LAN am Netz). Evtl. hat sich also hier etwas geändert, was zu einem anderen Störspektrum geführt hat. Das Treiber-Log hatte ich mir auch schon angesehen in Bezug auf Änderungen des Treibers und dabei nichts gefunden.


    Sebi


    Moin,


    wie im anderen Thread schon geschrieben, ist mein Problem wohl ein empfindlicher Link zwischen Cine CT V6 und CI-Modul. Die Verbindung über das Flachbandkabel fängt sich Störungen ein, was zum Abbruch des Links führt. Nach einem Reset des CI funktioniert es wieder für kurze Zeit, dann wird die Verbindung erneut gesört und bricht ab. Das erklärt auch, warum das CAM ungültige Daten bekommt und darauf mit einer Fehlermeldung (keine Berechtigung) reagiert. Die Störungen betreffen auch nicht nur verschlüsselte Probleme, sondern alle Kanäle, die per Redirect über das CI laufen. Vor allem ZDF HD ist hier betroffen (vermutlich auch wegen der im Vergleich höheren Datenrate).


    Gab es hierz eine Änderung am Treiber (Datenrate des Link erhöht etc.), oder ist das Zufall, dass bei mir das Phänomen erst mit dem besagten Treiberupdate auftrat? Ich habe das CI ca. Mitte April eingerichtet, danach hat es ca. 4 Wochen ohne größere Probleme funktioniert.


    Sebi

    Hi Pelvis,


    auch ich kenne das Problem. Hinzu kommt noch, dass sich einer der Tuner bei mir manchmal aufhängt, gerne bei Aufnahmen auf einem HD-Kanal.


    Nach einigem Hin und Her habe ich das Problem glaube ich gefunden: die Verbindung zwischen Tuner bzw. Cine CT und dem CI-Modul ist etwas empfindlich. Ich hatte in meinem Rechner ein ähnliches Problem, bis ich eine ungenutzte WLAN-Karte, die direkt unter dem CI lag, entfernt und die Kabelführung des Flachbandkabels geändert habe. Seither kann ich auch verschlüsselte Sender länger als 2min empfangen und ich habe keine Verbindungsabbrüche mehr.


    Bei mir traten diese Fehler aber erst seit etwa anfang Mai auf, nachdem ich ein Treiberupdate gemacht habe. Weiß evtl. jemand, ob sich da etwas am Timing (z.B. Datenrate des Links zwischen CI und ddbridge) geändert hat, was die Verbindung empfindlicher gegen Störungen macht?


    Auf der Website habe ich gesehen, dass die neun Kabel mit Ferriten verkauft werden. Dienen diese nur der (besseren) Einhaltung von EMV-Werten oder auch der Entstörung der Karte? Kann man die Verbindung sonst irgendwie stabiler gestalten? Ich habe das Gefühl, als wenn das alles etwas an der Grenze ist.


    Grüße,
    Sebi

    Schade, zu früh gefreut. Es ist wieder alles wie vorher: die Kanäle werden entschlüsselt, nach ein paar Minuten bis Sekunden friert das Bild ein und ich bekomme "Sie haben keine Berechtigung".


    Nutzen tatsächlich so wenige das CI mittels Redirect? Funktioniert es bei allen anderen? Welche Provider habt ihr (hier Unitymedia mit UM02).


    Sebi

    Kurzes Update: nach einer Aktualisierung des AlphaCrypt von 3.19 auf 3.23 hat heute Nacht eine 2-stündige Aufnahme per CI (Pro7, UnityMedia-Grundverschlüsselung) funktioniert. Mal sehen, ob das Update die Probleme dauerhaft behebt. Ich werde berichten!


    Übrigens habe ich das Update mit einem problematischen TI-Cardbus-Controller hinbekommen. Diese mögen das AlphaCrypt nicht, weil es einen der Pins für die Spannungserkennung anders beschaltet und so der PCMCIA-Controller nicht erkennen kann, welche Spannungen das Modul haben möchte, der PC erkennt die Karte daher als MTD-Gerät und kann nichts damit anfangen. Ich habe daher die Pins VS1 (43) und VS2 (57) auf Masse (1, 34, 35, 68, einer reicht natürlich) gelegt, danach erkannte mein PC (Thinkpad T61) das Modul sofort, ich konnte den Treiber installieren und das Update erfolgreich durchführen. Damit ich das Laptop nicht aufschrauben musste, habe ich 3 dünne Kupferlackdrähte am Ende ca. 5mm abisoliert, in die entsprechenden Kontaktlöcher geschoben und umgebogen. Das Ganze dann mit einem Streifen Tesafilm fixiert und die Drahtenden aus dem Slot herausgeführt. Dann die 3 Drähte auch am anderen Ende ein bißchen abisolieren und mit einer Klemme o.ä. verbinden. Modul einschieben und voilá - es funktioniert!


    Natürlch muss der Kupferlackdraht dünn sein, meiner hat 0,1mm oder so. Und es muss Lackdraht sein, damit´s keine Kurzschlüsse gibt. Fotos kann ich gerne nachliefern.Dünne Litze geht evtl. auch, wichtig ist, dass die Pins des PCMCIA-Schacht nicht beschädigt werden und dass die Karte trotz der Leitungen noch in den Schacht passt. Mit dünnem Draht ist das aber kein Problem.


    Grüße,
    Sebi