Posts by HolgerR

  • [0.3] Schnee in dunklen Flächen

    Bevor hier der allgemeine Jubel ausbricht und das wilde Downgraden beginnt:


    Einige werden sich noch an die Probleme mit den "Bildhängern" erinnern: Kurzes Standbild mit anschließendem schnellen Bildvorlauf bis Bild und Ton wieder synchron sind. Dieses Problem wurde in der 260er Reihe behoben und ist natürlich nach einem Downgrade auf den 256er Treiber wieder da.


    Von diesem Problem waren zwar viele nicht betroffen (oder haben es nicht so wahrgenommen) ich wollte aber trotzdem mal generell davor warnen, den Downgrade "ohne Not" vorzunehmen: Wer in der Vergangenheit das "Hänger-Problem" hatte, wird es mit dem alten Treiber wieder bekommen.


    Gruß
    Holger

  • GELÖST [0.3] kein Bild nach Wakeup aus Suspend to Ram

    Quote

    Original von Ranga
    Mit der Option SLEEP_MODULE="uswsusp" geht er nicht in den sleep modus, bleibt scheinbar vorher irgendwo hängen.


    s2ram war nicht installiert habe es nun mit apt-get installl uswsusp nachinstalliert.


    Die "kernel" methode ist aber auf jeden Fall eine Sackgasse, du solltest dich eher darauf konzentrieren, "uswsusp" zum Fliegen zu bekommen. Wir haben das nicht ohne Grund jetzt in der 0.3 ;) Probier doch mal die verschiendenen Settings bei "add_parameters" durch.


    Das Log für den Sleep Vorgang findest du unter "/var/log/pm-suspend.log". Im Zweifelsfall hier posten, evtl. können wir was erkennen.


    Gruß
    Holger


    PS: Ein apt-get dist-upgrade würde auch helfen wegen des zurückgehaltenen essentials.

  • GELÖST [0.3] kein Bild nach Wakeup aus Suspend to Ram

    Quote

    Original von Ranga
    Erneute Konfiguration im Webfrontend hat nichts gebracht :(


    Miene /etc/pm/config.d/00module sieht folgendermaßen aus.

    Code
    SLEEP_MODULE="kernel" 
ADD_PARAMETERS="-f"


    Hi Ranga,


    ändere das mal bitte zu SLEEP_MODULE="uswsusp" bzw. poste mal bitte was "which s2ram" auswirft.


    Gruß
    Holger

  • yavdr-0.3

    Quote

    Original von smurfb
    1. Wouldnt it be nice if a option to sleep before VDR is started is added? Now I added a sleep 10 in the vdr upstart script, but it would be nice if this was a option so I dont have to change everytime the script is updated.


    Hi,


    we changed a lot of things in yaVDR 0.3 to make sure that the vdr is only started when everything's ready (i.e. all DVB devices are up). This works quite well so far.


    Question is: Do you really need the "sleep 10"? Did you try without it?


    regards
    Holger

  • [suche] beta-tester für zukünftige updates

    Die Idee kann ich nur gut heißen! Aber: Es sollten Leute sein, die:


    A) gezielt nach Fehlern suchen können und wollen.
    B) Fehler qualifiziert beschreiben können.
    C) Idealerweise für die Fehler direkt Lösungsvorschläge unterbreiten können.


    Die Punkte A) und B) wären für mich zwingende Vorraussetzung. Ich denke auch, dass man diese Art von Beta-Test auch als solchen betreiben sollte, das heißt "nicht öffentlich" also nicht(!) hier im VDR-Portal. Die Details können wir klären, wenn es so weit ist.


    Gruß
    Holger

  • Damit ist 720p wohl gegessen

    Quote

    Original von Morone
    Zu den GEZ lasse ich mich garnet erst aus..
    1. eh OT
    2. schon lange net mehr son Quatsch gelesen..


    ... ich wollte mich natürlich -wie die meisten hier- aus eurem Kleinkrieg raushalten. Aber da muss ich mich dann doch anschließen. Hübscher Gedanke, wenn die Rundfunkgebühr eingeführt worden wäre, um freien und unabhängigen Jounalismus zu ermöglichen. Sie dient aber vielmehr der Finanzierung des Staatsrundfunks. Genau genommen ist sie das exakte Gegenteil von deiner Idee fnu und "unsere Großväter" haben dem Reichspropagandaminister die Kohle bereitwillig gezahlt (Anfänge der Rundfunkgebühr)


    Gruß
    Holger (der brav GEZ zahlt und das auch in Ordnung findet)

  • [0.3] nvidia 195.30

    Quote

    Original von presskopf
    ...oder es mag keiner Antworten.


    Korrekt ;) Ich würde euch wirklich bitten, die Finger davon zu lassen und euch stattdessen im Thread bei nvnews einzubringen.


    Nur um ein Ausufern dieses Threads zu vermeiden, hier ein paar Eckpunkte für eine Installation:


    - Das ganze geht nur nach vorherigem "untie-packages"
    - Das Paket "nvidia-current" deinstallieren.
    - Original Installer von Nvidia besorgen, X-Server stoppen mittels "stop openbox" und den Installer ausführen.
    - In der "/etc/init/displaydevice.conf" "nvidia-current" durch "nvidia" ersetzen und Rechner neu starten(!).


    Zurück geht's einfacher:
    Den Nvidia Treiber mittels "--uninstall" wieder von System entfernen, "nvidia-current" wieder installieren und die Änderung an der "displaydevice.conf" wieder rückgängig machen.


    Wie gesagt:
    Ungeübten rate ich dringend davon ab. Bereits das "untie-packages" ist als "unsupported" einzustufen, vom Rest mal ganz zu schweigen. Also verschont mich/uns bitte mit irgendwelchen Folgefehlern.


    Gruß
    Holger

  • VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?

    Quote

    Original von durchflieger
    Den 195.30 werde ich dann auch mal probieren.


    Und? Wie sieht's bei dir damit aus?


    Ansonsten:
    yaVDR 0.2 Nutzer finden im "unstable-vdr" Repository jetzt eine libxine inkl. Profiling Patch. Danke dafür hotzenplotz5 (der selber nicht mal von dem Problem betroffen ist). Damit sollte die Hemmschwelle zum munteren gemeinsamen Bughunting ein wenig niedriger sein.


    Gruß
    Holger

  • VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?

    Quote

    Original von avanix


    Wäre es dann nicht möglich einfach diesen Treiber zu verwenden? In yavdr oder anderen Distris ließe sich der doch sicher einfach einbauen. Oder ist der zu alt für die aktuelle xinelib?


    Klar. Immer, wenn ich in Ruhe einen Film schauen möchte, verwende ich den 195.30 ja auch. Aber damit wäre das Problem ja nicht aus der Welt ;)


    Gruß
    Holger

  • VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?

    kaminkehrer
    Dann bist du vermutlich (wie scheinbar viele) nicht von dem beschriebenen Problem betroffen. Fakt ist -wie bereits geschrieben- : Mit dem 256.35 treten die Probleme nach wie vor auf. Der letzte problemlose Treiber ist der 195.30. Alles danach hat dieses Problem.


    durchflieger
    Du hast völlig recht: "Lösen" kann das Problem wohl nur Nvidia und für einen Bugreport, der sich auf eine schon seit einigen Treiberversionen existierende Regression bezieht, brauchen wir wohl jede Menge Stichhaltiges. Was schlägst du vor? Profiling Patch mit oder ohne LOCKDISPLAY?


    Gruß
    Holger

  • VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?

    Hi,


    @all
    Jetzt bitte nicht gleich eingeschnappt sein. Es stimmt schon: Reine "me too" postings bringen uns nicht weiter. Alles, was nähere Details liefert allerdings schon. Im übrigen habe ich diesen Post auch absichtlich nicht im yaVDR-Unterforum eröffnet, da es kein yaVDR-Problem ist, sondern ein allgemeines.


    jrie
    Das war jetzt Quatsch. Hier geht es sowohl um xinelibouput als auch um vdr-xine. Es sind beide betroffen und durchfliegers Patch bezieht sich auf den gemeinsamen "Unterbau" die xine-lib 1.2


    durchflieger
    momentan wird scheinbar an zwei "Fronten" nach dem Fehler gesucht. Ich gebe mal eine Aussage von rnissl frei wieder (was hoffentlich o.k. ist). Evtl. ist das auch interessant für dich:


    In der Datei "/src/video_out/video_out_vdpau.c" hat er seinerzeit auf eine fehlerhafte "libxcb" reagiert, indem er guarded functions eingesetzt hat. Im Code der xine-lib 1.2 erkennbar an: "#define LOCKDISPLAY /*define this if you have a buggy libX11/xcb*/". Die in deinem Patch überwachte Funktion ist eine dieser guarded functions. Zwischenzeitlich haben wir eine libxine gebaut, die darauf verzichtet, da zumindest in Ubuntu Lucid der Fehler in der "libxcb" nicht mehr existiert. Die "Hänger" treten leider immer noch auf, aber der Watchdog bleibt jetzt stumm. Kannst du das bei dir nachvollziehen?


    Wie gesagt, wollt's nur mal weitergeben ;)


    Gruß
    Holger