Posts by micclass

    Kurzes Update:


    Problem gefixt:


    engine.decoder_priorities.ffmpegvideo:1


    in .xine/config_xineliboutput war mein Freund. Manchmal sind's doch die einfachen Dinge ;-)


    Also zumindest kann ich nun bestätigen, dass vdr-1.7.17 mit xineliboutput auf einem Sandybridgesystem grundsätzlich funktioniert. Finetuning steht nun natürlich noch an.


    Gruß Micha

    Danke für die Antworten!


    Mir ist schon klar, dass Sandbridge System noch rar sein dürften. Für 'nen reinen VDR wäre das System hier auch etwas Overkill. Das ist mein Arbeitsplatz PC (mit 16GB Speicher und 4TB Platten) auf dem immer 2-3 virtuelle Maschinen laufen, an dem 2 Monitore hängen und an dem eben auch mal via VDR etwas Glotze läuft (zumeist werden die Aufnahmen dabei von einem anderen vdr system via NFS gemountet).


    Mein Problem des schwarzen Schirms (oder "scharzen Fensters" wenn nicht im Fullscreen mode) zieht sich mit vaapi über xine.-ui, xineliboutput und xine-plugin in der gleichen Weise. Ich gehe deshalb davon aus, dass etwas auf der xine-lib Schicht oder darunter schief läuft. Nachdem mplayer-vaapi mit -vo vaapi aber funktioniert, denke ich mal, dass drm, dri, und libva o.k. sein sollten. Hier bin ich mir jedoch nicht sicher. Verwendet mplayer-vaapi hier was anders, als die xine-lib Schiene?


    Irgendwie such ich nach eriner Strategie wie ich das Problem auf (hoffentlich) eine Komponente einkreisen könnte.


    Gruß Micha

    Hallo,


    da ich gerade ziemlich am straucheln bin hier mal 'ne Frage:


    Hat schon jemand vaapi mit vdr und xineliboutput auf einem Sandy Bridge System erfolgreich zum Laufen bekommen?


    Was ich bisher versucht habe:


    HW: Asus P8H67-V Motherboard mit I7-2600K CPU und einer alten FF-Karte. Bisher hatte ich das System mit einer Nvidia Grafikkarte betrieben und vdr/xineliboutput/vdpau arbeitete ziemlich gut.
    Nun will ich das System ohne zusätzliche GraKa betreiben:


    Software: Fedora 14 mit folgenden Komponenten von Fedora 15 Alpha:
    - Xserver (1.10)
    - kernel (2.6.38 )
    - mesa (7.10)


    Zusätzlich habe ich folgende Komponenten direkt mit den neuesten (16.03.2011) SW ständen aus den Repositories gebaut:
    - libx264 (V114)
    - ffmpeg
    - xine-lib-1.2-vaapi
    - libva (1.10)
    - xineliboutput
    - vdr-1.7.17
    - von der Intel mesa-intel hab ich den aktuellen i965-dri genommen (aber auch mit dem orginalen mesa 7.10 ist das Verhalten gleich)


    Zwei Probleme:


    1. vdr-sxfe --video=xv funktioniert zwar prinzipiell, aber HD Aufnahmen (die auf einem anderen Systen erstellt wurden und per NFS gemountet sind) zeigen nur Ton, aber kein Bild
    "video_decoder: no plugin available to handle 'Advanced Video Coding (H264)'"


    2. vdr-sxfe --video=vaapi erzeugt Ton aber nur ein schwarzes Bild.



    Ein probeweise gebautes mplayer-vaapi läuft mit vaapi Ausgabe!


    $/opt/xine/bin/vainfo
    libva: libva version 0.32.0
    libva: va_getDriverName() returns 0
    libva: Trying to open /opt/xine/lib/dri/i965_drv_video.so
    libva: va_openDriver() returns 0
    vainfo: VA API version: 0.32
    vainfo: Driver version: i965 Driver 0.1
    vainfo: Supported profile and entrypoints
    VAProfileMPEG2Simple : VAEntrypointVLD
    VAProfileMPEG2Main : VAEntrypointVLD
    VAProfileH264Baseline : VAEntrypointVLD
    VAProfileH264Main : VAEntrypointVLD
    VAProfileH264High : VAEntrypointVLD
    VAProfileVC1Simple : VAEntrypointVLD
    VAProfileVC1Main : VAEntrypointVLD
    VAProfileVC1Advanced : VAEntrypointVLD



    Wo könnt ich denn noch suchen, bzw. hat das schon mal jemand mit einem Sandy Bridge system laufen sehen?


    Gruß Micha

    Hallo,


    ich hätt da mal ein kleines Problem:


    Situation: Ich hab 'nen vdr (1.7.16) gebaut und der tut auch ganz wunderbar. Wenn ich nun eine Aufnahme machen will und den vdr über die Fernbedienung 'runterfahre, startet der vdr für die Aufnahme und legt sich nach der Aufnahme wieder brav schlafen. So weit so gut. Wenn ich mich aber über ssh auf das vdr-system einlogge und den vdr dann via "shutdown -h now" abschalte, wird er zwar für die nächste Aufnahme gestartet, aber der VDR schält sich nach der Aufnahme nicht mehr aus. Ich hab das automatische Ausschalten für den interaktiven Modus auf "0" gesetzt. Wenn ich das auf 180 Minuten lasse, dann schält sich der VDR halt nach der Aufnahme erst 3 Stunden (180 Minuten) später aus - auch nicht optimal.


    Das ganze Verhalten rührt daher, dass beim manuellen Shutdown in setup.conf die "NextWakeupTime" nicht gesetzt wird (sprich null ist) und dann der VDR beim aufwachen meint er wäre im interaktiven modus.


    Beim 'runterfahren über die Fernbedienung wird ja in shutdown.c folgende Sequenz ausgeführt:


    Setup.NextWakeupTime = WakeupTime; // Remember this wakeup time for comparison on reboot
    Setup.Save();
    isyslog("NextWakeupTime was set to '%d'", WakeupTime);


    Also nun meine Frage: was gibt es für Lösungen, dass ich den VDR auch mal mit "shutdown" 'runterfahren kann ohne dass bei der nachfolgenden Aufnahme der VDR angeschaltet bleibt. Das Ganze sollte hoffentlich ohne Patchen des VDR sourcecodes gehen (so eine Lösung krieg ich auch selbst hin, möchte aber ungern eigene Patches im VDR pflegen müssen ...)


    Gruß Michael

    Hallo!


    Ich hätt da mal ein Problem: Früher (sprich mit vdr Version 1.6.0 und PES Aufnahmen) habe ich immer problemlos über SAT kommende Radioprogramme aufnehmen können. Den Content hab ich dann mit einem kleinen Script in MP3 gewandelt und fertig war das Hörspiel für den MP3-Player.


    Nun hab ich meinen VDR auf 1.7.14 upgegraded (wegen HD und so). Seither bekomme ich zwar weiterhin die Radiosendungen im EPG angezeigt, aber die Aufnahmen (in TS) sind immer 0-Bytes groß.


    Ist das ein Bug oder ein Feature? Gibt's Lösungsmöglichkeiten?


    Grüße Micha


    Vdr 1.7.14 auf Fedora 13 Beta mit TT-S1600 Karte und den standard Treibern des Kernels 2.6.33.3

    Hallo,


    hier mal ein kurzer Bericht bezüglich meiner Versuche mit der TT S2-1600 Karte und VDR. Dank der Infos in diesem Thread spielt sie nun:


    Fedora 13Alpha (kernel 2.6.33.1-19.fc13.x86_64) wollte nicht mal booten mit der Karte. Erst nachdem ich die aktuelle Treiber von video4linux (dvb_v4l) verwendet habe ist's gegangen. Vdr ist Version 1.7.14. Allerdings bekomm ich bei den meisten Sendern nur zuverlässig ein Bild, wenn ich die Frequenz in der channels.conf um 2 erhöhe. Dann klappt sowohl SD, wie auch HD (getestet mit ARD, ZDF, Arte und ServusTV - also mit 720p, als auch 1080i).


    Versteht denn irgend jemand warum ich an den Frequenzen was ändern muß? Meine SAT-Anlage kann es ja nicht sein, da ich für eine FF-Karte die ich mit der 1600er ersetzt habe dies nicht tun musste. Auch läuft in einem anderen PC eine S2-3200 ohne eine Veränderung der Frequenz am gleichen (Quad-)LNB.


    Gruß Michael

    Ja, der Parameter kann's nicht sein. Ich hab gerade mal (mit etwas Gewalt ;-) ein dvb-ttpci.ko Modul gebaut, das die Firmware beinhaltet. Damit geht das Problem aber auch nicht weg.
    Die Ursache muss schon weiter "vorne" liegen. Ich denk mal, daß irgend eine Komponente nicht erkannt wird und deshalb auch die ganze Initialisierung nicht abläuft ... aber noch versteh ich den Mechanismus wie das funktionieren sollte noch nicht ... ich arbeite daran ;-)


    Gruß Micha

    Hallo Zusammen!


    DIes ist nur ein "me too" ;-) Ich hab bei zwei Rechnern (einer Fedora 9 i386, ein zweiter Fedora 9 x64) beide mit Hauppauge Nexus-S (Technotrend Version 2.3). Genau das gleiche Problem! Kernel 2.6.25.14 funktioniert alles (etwa so wie oben beschrieben) und mit 2.6.26.3 (hab inzwischen auch schon 2.6.26-5-42 probiert: selbes Problem) krieg ich auch nur


    saa7146: register extension 'dvb'.


    Und dann herrscht Ruhe. d.h. keine Firmware wird geladen. Ich hab inzwischen mal das dvb-ttpci Modul selbst zusammengebaut und mit etwas debugging versehen. Also die Funktion die die Firmware laden sollte wird nicht mal aufgerufen.


    Gibt's inzwischen irgendwelche Neuigkeiten zu diesem Thmea?


    Gruß Micha