Beiträge von sebixvi

  • Medion/Pollin X10 - yaVDR0.4

    Moin,


    bei mir muss das Paket ati-remote-dkms installiert sein (und nach der Aktualisierung der Treiber mit apt-get install --reinstall ati-remote-dkms aktualisiert werden), sonst will die X10 nicht. Mag aber damit zusammen hängen, dass ich wegen der Cine CT die Treiber aus linux-media-build-experimental verwenden muss, dies bringt ein eigenes ati-remote-Modul mit, was nicht funktioniert.


    Allerdings hat meine X10 ein anderes Problem: der Empfänger weckt den Rechner per USB, auch ohne dass ich per Fernbedienung das Signal dazu gebe. Ständig läuft der VDR, ohne dass jemand den GEist gerufen hat. Bisher konnte ich das Problem nur durch Abschalten des USB-Wakeup lösen.


    Merkwürdigerweise habe ich im Betrieb keine Fehlbedienungen, sodass ich Funkstörungen etc. als Ursache ausschließen möchte. Hat noch jemand dieses Phänomen? Ich habe ja schon oft gehört, dass der X10-Empfänger unter LInux nicht zum USB-Wakeup taugt, aber alleiniges Einschalten habe ich bisher nirgends gelesen.


    Grüße,
    Sebi

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

    Hallo,


    auch bei mir hat sich die CI-Unterstützung als problematisch erwiesen.


    Ein paar Wochen funktionierte es. Nach einem Update des Treibers vor ca. 3 Wochen funktioniert das CAM zwar grundsätzlich, die Kanäle werden hell. Nach ein paar Minuten (manchmal nur Sekunden) friert aber das Bild ein, und ich bekomme die Meldung "Sie haben keine Berechtigung, dieses Programm zu empfangen". Setze ich das CAM im Menü zurück, kann ich wieder für ein paar Sekunden bzw. Minuten gucken, danach ist wieder schluss.


    Irgendwas scheint da im Treiber noch nicht zu funktionieren.


    Sebi

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

    Hallo,


    irgendwie scheint der CI-Support noch etwas hakelig. Da ich häufiger PRobleme mit der Fehlermeldung "Error: video data stream broken" hatte, habe ich anfang der Woche mal wieder den aktuellen Treiber installiert (media_build_experimental gelöscht, neu ausgecheckt und installiert). Seither läuft das CI nicht mehr zuverlässig. Beim Empfang der privaten bekomme ich erst ein Bild, nach 2-3min. friert das Bild ein und ich bekomme die Meldung "Sie haben keine Berechtigung, dieses Programm zu empfangen". Wenn ich das CAM resette, habe ich wieder für 2min ein Bild, danach geht das Ganze von vorne los.


    Weitere Fehlermeldungen im Log gibt´s nicht, auch dmesg gibt nichts her. Karte ist eine Cine CT V6.1, das CI hängt am Tab 3.


    Hat jemand dasselbe Problem?


    Sebi

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

    Moin,


    ich hatte mich ein Wenig zu früh gefreut. Beim Test hat's zwar geklappt, aber Timeraufnahmen funktionieren trotzdem nicht.


    Das Problem war, das mein Programm nicht wartet, ob /sys/class/ddbridge/ddbridge0/redirect existiert, sodass die Umleitung nicht wirklich eingerichtet werden kann. Ich habe den Code wie folgt erweitert:



    Damit wird zunächst getestet, ob /sys/class/ddbridge/ddbridge0/redirect existiert. Falls nicht, wird 1s gewartet und ein neuer Versuch gestartet, max. werden 10 Versuche gemacht. Bei Erfolg wird die Redirection aktiviert.


    Damit funktioniert es auch nach einem Suspend/resume, zumindest beim Testen. Bin mal gespannt, ob damit Timeraufnahmen funktionieren.


    Übrigens habe ich herausgefunden, dass Redirection auch eingeschaltet werden kann, wenn auf die Karte zugegriffen wird. Ich habe die Änderungen oben bei laufendem vdr durchgeführt, vdr brachte "Kanal nicht verfügbar". Sobald ich fertig war und mein Programm testweise gestartet habe, wurde der Kanal sofort hell.


    Sebi

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

    Hallo,


    inzwischen habe ich einen Weg gefunden, das Redirect automatisch zu aktivieren. Größte Hürde war dabei, dass RUN+= offenbar bei Skripts nicht (immer) funktioniert. Warum, habe ich noch nicht rausgefunden.


    Als Regel habe ich eine Datei mit dem Namen /etc/udev/rules.d99-ddbridge.rules erzeugt mit folgendem Inhalt:


    Code
    KERNEL=="dvb0.ca0",SUBSYSTEM=="dvb",RUN+="/usr/sbin/redirect"


    Ursprünglich war als Befehl "/bin/sh /usr/sbin/redirect.sh" eingetragen, redirect.sh sah dann so aus:


    Bash
    #!/bin/sh
echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect


    Allerdings konnte ich udev nicht dazu bewegen, dieses Skript zu starten. Beim Test mittels

    Code
    udevadm test --action=add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/dvb/dvb0.frontend0


    wurde zwar angezeigt, dass die Regel angewandt und der Befehl ausgeführt wurde, aber dem war nicht so. Also habe ich den gcc angeworfen und folgende Zeilen compiliert:



    Nach "gcc -o redirect redirect.c" das entstehende Binary nach /usr/sbin kopieren und voilá - nach "modprobe ddbridge" steht im dmesg als letzte Zeile "redirect: 00, 02" und das Cam läuft 1a.


    Gute Nacht,
    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Hallo fnu,

    Zitat

    Testweise habe ich gestern auf Ausgabe per SPDIF bzw. analog umgestellt,
    ohne dass das etwas geändert hätte. Damit hat es wohl nichts zu tun.

    Das hatte ich schon probiert, brachte aber keine Änderung. Die asound.conf hatte ich außerdem komplett gelöscht, um wirklich nur ein Ausgabedevice zu haben. Erst die Umstellung der xorg.conf brachte die Lösung.


    Seltsam finde ich, dass die xorg.conf ja bei vdr-sxfe und xbmc identisch ist, da wird ja kein X-Server neu gestartet. Trotzdem kam xbmc mit der Konfiguration offenbar zurecht, während vdr-sxfe seit dem letzten Update strauchelte.


    Grüße,
    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Hallo Gerald,


    da der TV derzeit nicht benutzt wird, habe ich schlicht nicht daran gedacht. Das ist so eine typische Geschichte, die man irgendwann mal konfiguriert und dann nie wieder anfasst, weil es einfach funktioniert.


    Und 60Hz sollten lt. Forum zu Mikrorucklern, nicht aber zu 75% CPU-Last und ähnlichen Problemen führen.


    Trotzdem versuche ich, nächstes Mal dran zu denken!


    Gute Nacht,
    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Guten Abend,


    mein Problem ist gelöst, vdr-sxfe läuft mit ca. 3% Prozessorlast auf einem HD-Sender.


    Grund war meine xorg.conf. Ich habe eine TwinView-Konfiguration (Beamer und HD-ready-Fernseher). Ersten Erfolg hatte ich, nachdem ich in der "Option ConnectedMonitors" den (nicht angeschlossenen) Fernseher zunächst rausgenommen habe. Sofort war das Bild i.o. und die CPU-Last unten.


    Dann fiel mir auf, dass der Beamer 60Hz meldet, für PAL-Sendungen ebenfalls nicht optimal. Also habe ich erstmal folgende Modeline eingefügt:


    Code
    ModeLine "1920x1080_50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync


    Damit lief der Beamer mit 50Hz, wie er soll. Da der TV maximal 1080i kann, habe ich für den TV noch


    Code
    ModeLine "1920x1080_50i" 74.25 1920 2448 2492 2640 1080 1084 1094 1122 +hsync +vsync interlace


    ergänzt, in der Einstellung ConnectedMonitors DFP-0 wieder eingesetzt und MetaModes wie folgt gesetzt:


    MetaModes "DFP-1:1920x1080_50, DFP-0:1920x1080_50i"


    Jetzt läuft der Beamer mit 50Hz progressive, die Ruckler sind weg und die CPU-Last liegt unter 5%. Gelegentlich muss ich noch nachsehen, ob der TV im Nebenraum ein Bild zeigt, aber ich gehe davon aus. Die Modelines habe ich dem erweiterten Log entnommen (startx -- -logverbose 6).


    Bleibt die Frage, wieso die 60Hz bisher nicht gestört haben, optimal ist es natürlich so oder so nicht.


    Schönen Abend,
    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Zitat von fnu


    Interessante Information, aber da das wohl läuft ist das kaum hilfreich. Log-Informationen aus der Zeit wo etwas nicht korrekt funktioniert könnten bei der Problemlösung helfen.

    IMHO kann man damit jedenfalls ausschließen, dass das Problem im Treiber bzw. im X-Server liegt, nur darum ging es mir. Wenn die vdpau-Komponenten einen Schlag hätten, würde xbmc ebenfalls nicht korrekt laufen. Und dass eine Aufnahme in xbmc funktioniert, die im vdr stottert, schließt aus, dass es Empfangsprobleme bzw. "schlechte" DVB-Daten sind. Das wurde oben ja auch diskutiert.


    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Zitat von fnu


    Mich würde das syslog und ein "htop" Screenshot interessieren und zwar in der Zeit wo Du auf einem HD Sender bist?


    Regards
    fnu

    Syslog:


    htop:


  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    So, ich habe mal testweise xbmc angeworfen und eine HD-Aufnahme, die im vdr ruckelt, abgespielt - alles einwandfrei, Systemlast von xbmc unter 10%. Das Logfile von xbmc meldet:



    Hier wird also ebenfalls vdpau benutzt, die Ausgabe klappt einwandfrei. Auch wenn ich als Deinterlacer temporal-spatial wähle, steigt die CPU-Last von xbmc.bin nicht über 10%. Nur wenn ich als Skalierungsmethode noch "bicubic" auswähle, habe ich ca 12-15% CPU-Last und das Bild wirkt leicht unruhig, aber kein Vergleich zu den Problemen bei vdr.


    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Zitat von fnu


    Doch genau das passiert so, weil die Grafikkarte ein Peripherie-Gerät der CPU ist. Die Hauptarbeit des Systems übernimmt immer die CPU, die Grafikkarte unterstützt diese und übernimmt im Falle von VDPAU eben etwas mehr Aufgaben, wie z.B. Decoding, Bildaufbereitung, Deinterlacing etc. Die Grafikkarte ist aber nichts ohne CPU ...


    Ein Grafikkarte ist keine AddOn Karte wie eine FF, DXR3, FF-HD, eHD, die an sich autark vor sich hinwerkeln und den Rest vom System als "Wirt" nutzen, wobei eine FF-HD inzwischen schon auch eine ordentliche CPU benötigt um befeuert werden zu können.


    Regards
    fnu


    Eben, die Grafikkarte übernimmt das Deinterlacing, Decoding und Bildaufbereitung. Das Anreichen der Daten sollte aber aber ein C2Duo ohne nennenswerte Schwierigkeiten hinbekommen.


    Außerdem habe ich mir gerade nochmal das Log nach dem Umschalten auf einen HD-Kanal angesehen. Dort steht:


    Code
    vo_vdpau: deinterlace: bob
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=1 studio_levels=0
vo_vdpau: skip_chroma = 1


    Damit sollte der PC noch weniger ein Problem haben. Temporal wird nur bei SD benutzt (Voreinstellung von yavdr).


    Testweises Umstellen des Frontends auf xine-plugin hat übrigens hier keinen Effekt, die HD-Sender ruckeln auch da.


    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Hallo,

    Zitat von DocViper

    Wenn es diese Maschine ist: Ubuntu 12.04ß MCP78S [Geforce 8200]
    dann könnte schon sein das temporal zu viel ist für die 8200'er Geforce

    die Logs waren von meinem Rechner, dort werkelt ein Core2Duo E2500 mit einer GF210-Grafikkarte. Das sollte also mit temporal passen.


    Außerdem erklärt eine Überforderung der Grafikkarte nicht die hohe CPU-Last beim Abspielen von HD-Material. Auch dann sollte allenfalls die Grafikkarte schwitzen, nicht aber der Prozessor.


    Last not least wurde die Konfiguration, insbesondere der Deinterlacer, beim Update nicht angefasst (es sei denn, das Update hat automatisch was umgestellt, was ich aber nicht glaube). Bis zum letzten apt-get dist-upgrade lief HD auf diesem Rechner einwandfrei.


    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Zitat von sebixvi

    Ich werde heute abend mal einen aktuelleren Nvidia-Treiber probieren. Auf der Website von Nvidia habe ich gesehen, dass 295.33 aktuell ist. In der feature-list heißt es:

    Zitat von sebixvi

    Vielleicht ist das ja die Ursache. Ich werde berichten!

    So, habe den Treiber gerade aktualisiert, brachte leider keine Änderung. Nach Umschalten auf den HD-Kanal (hier Das Erste HD) direkt 74% CPU-Last und stotterndes Bild. :(


    Sebi

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Moin,


    es scheint, als wäre vdpau nicht der Bösewicht:


    Code
    root@dumbledore:/home/sebastian# uname -a
Linux dumbledore 2.6.38-13-generic #57-Ubuntu SMP Mon Mar 5 18:29:54 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


    Code
    root@dumbledore:/home/sebastian# dkms status | grep nvidia
nvidia-current, 285.05.09, 2.6.38-13-generic, x86_64: installed


    Code
    root@dumbledore:/home/sebastian# grep nvidia /var/log/Xorg.1.log
[	32.724] (II) LoadModule: "nvidia"
[	32.724] (II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so
[	32.724] (II) Module nvidia: vendor="NVIDIA Corporation"
[	33.102] (II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so



    Das sieht für mich so aus, als wenn vdpau schon aktiviert ist. Bei Widergabe von sd-Inhalten hat vdr-sxfe ca. 2% CPU-Last. Beim Umschalten auf einen HD-Kanal steigt die Last sofort auf ca. 70% an und fällt beim weiteren Umschalten sofort wieder ab.


    Ich werde heute abend mal einen aktuelleren Nvidia-Treiber probieren. Auf der Website von Nvidia habe ich gesehen, dass 295.33 aktuell ist. In der feature-list heißt es:


    "Fixed a VDPAU bug where decoding some H.264 streams would cause hardware errors on lower-end products, resulting in corruption and poor performance."


    Vielleicht ist das ja die Ursache. Ich werde berichten!

  • Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

    Hallo,


    ich habe dasselbe Problem, allerdings mit vdr-sxfe@vdr-plugin-xineliboutput. Das Bild ruckelt stark, der Empfang ist ok (Ausgabe per Streamdev auf entferntem Rechner ist kein Problem), Der Effekt tritt auch beim Abspielen von Aufnahmen ab, sowohl bei neuen als auch bei alten, die definitiv ok sind.


    Außerdem setzt nach einer gewissen Zeit der Ton aus, evtl., weil die Synchronisation flöten geht.


    Per top meldet vdr-sxfe eine Prozessorlast von 70% auf einem Core2 Duo-System, Grafikkarte ist eine GF210. Bis zum letzten Update (Freitag) war alles gut.


    Sebi

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

    Hallo zusammen,


    erstmal danke an alle, die mitgeholfen haben, dass das DuoFlex-CI grundsätzlich unter VDR einsetzbar ist. Gerade für die geplagten Grundverschlüsselten (wie mich z.B.) ist es endlich möglich, die analoge Karte aus dem System zu werfen.


    Ich habe heute erstmal den ddbridge-Treiber nach der Anleitung im ersten Post aktualisiert, um nur ein Frontend zu bekommen. Unter /etc/modprobe.d/ddbridge.conf habe ich


    options ddbridge adapter_alloc=3


    eingetragen, sodass ich beim Laden direkt ein Verzeichnis mit nur zwei Frontends bekommen. Jetzt suche ich nach einer Möglichkeit, das Redirecting automatisch nach dem Laden des Moduls auszuführen, zumal das ja passieren muss, bevor vdr startet. Bei den alten modutils gab es eine post-install-Option, mit der man nach dem Laden automatisch einen Befehl ausführen konnte. Mit den aktuellen Modutils habe ich diese Möglichkeit nicht mehr gefunden.


    Wie habt Ihr das gelöst?


    Danke,
    Sebi

  • yavdr 0.4 - Netzwerkprobleme (dhcp) und verwaiste dhcp-Prozesse

    Hallo zusammen,


    mein VDR auf Scaleo EVI-Basis läuft bis auf eine Kleinigkeit sehr gut: ich schicke den Rechner nur in den S3-Modus. Nach dem Aufwachen funktioniert bisweilen das Netzwerk nicht. Starte ich dann xterm, stelle ich fest, dass es tonnenweise dhclient-Prozesse gibt. Wenn ich die alle abschieße und ifup eht1 aufrufe, habe ich sofort wieder Netz.


    Zur Fehlersuche habe ich mir die Sleep-Skripte mal näher angesehen. In /etc/pm/sleep.d/20vdr_sleep wird das Netzwerk nach dem resume neu gestartet:



    Bei diesem Code ist es logisch, dass es nach ein paar Suspend-Zyklen massig dhclient-Prozesse gibt - denn dhclient wird nirgendwo beendet. Füge ich im obigen Skript unter "hibernate" zwischen "echo" und "initctl" ein "killall dhclient" ein, habe ich nach einem Suspend-Zyklus nur genau einen dhclient-Prozess. Ich werde mal abwarten, ob das Besserung bringt.


    Mich wundert, dass offenbar nur ich das Problem habe - die Suchfunktion hat jedenfalls keine Ergebnisse gebracht. yaVDR ist nicht verbastelt, sondern eine Standard-Installation.


    Kann man das Verhalten von dhclient irgendwo noch beeinflussen?


    Danke,
    Sebastian