Posts by Razorblade

    Ich versuche gerade mir die yavdr-Pakete aus den Sourcen zu kompilieren (da einerseits armhf gar nicht und Vivid noch nicht als binary verfügbar sind). Mit vdr (und vdr-dev) klappt das auch ganz gut, aber bei allen Plugins die ich probiert habe bekomme ich eine Fehlermeldung wie:
    dh_usrlocal: debian/vdr-plugin-xxx is not a directory, also z.B.:


    Und dann bricht der Build ab.


    Getestet bis jetzt mit live, suspendoutput und dummydevice

    Ja ist es. Ich habe jetzt mal die Module (nebst Firmware) manuell in den Kernel kompiliert und siehe da, es geht... ist natürlich keine Dauerlösung (man kann bei Problemen nicht mal eben das Modul Laden/Entladen), aber ich weiß, dass die Firmware, der Treiber und das Gerät funktionieren.

    Ich sehe im Kernl keine Referenz auf andere Firmware location als Standard und das ist laut KernelDoku zumindestens in letzter Instanz /lib/firmware. Habe auch schonmal die Kernel option "firmware_class.path=/lib/firmware" probiert, aber da stimmt wohl auch etwas nicht, die Kiste bootete nicht mehr.


    Initramfs/Initrd wird nicht genutzt, damit auch kein pivot_root oder sonstiger "Umzug" des rootfs, wüßte nicht wo er noch suchen sollte. Hatte sogar ein inotifywait auf "/" zu laufen um das zu verifizieren, ich sehe *gar keinen* Versuch die Firmware von irgendwo zu laden.

    Ich habe Probleme mein Tevii S660 USB DVB-S2 Adapter auf einem Cubietruck zum Laufen zu bekommen. Ich glaube nicht, dass das ein ARM-spezifisches Problem ist, deswegen hier:

    Code
    1. [ 10.376060] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
    2. [ 11.045931] dvb-usb: did not find the firmware file. (dvb-usb-s660.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
    3. [ 11.087934] usbcore: registered new interface driver dw2102


    Natürlich gibt es die Datei:

    Code
    1. # ls -la /lib/firmware/dvb-usb-s660.fw
    2. -rw-r--r-- 1 root root 8192 Jun 2 17:08 /lib/firmware/dvb-usb-s660.fw


    Hab schonmal einen inotifywait laufen lassen um zu sehen, ob die Firmware überhaupt angefragt wird, aber Fehlanzeige!


    Ich bentutze den neuesten (3.4.107) Danand Kernl in der Kernel.config sieht Firmware-seitig alles "normal" aus, aber ich kompiliere gerade mal einen eigenen Kernel um das gegenzuprüfen. Hat sonst noch jemand eine Idee? (udev habe ich schon debugged, die FW requests kommen aber, aber da släuft ja inzwischen alles direkt im Kernel ohne Userspace-Helper, so dass man da weder etwas drehen noch manuell laden kann) EDIT: Gleiches Ergebnis

    Die GTX960 ist ja nun draußen und mich interessiert der "Zero-Fan-Modus" (evtl reicht es dank GC5 für vdpau Decoding ohne GraKa Lüfter). Weiß jemand ob dieser Zero-Fan-Modus auch unter Linux out-of-the-box funktioniert oder nur unter Windows mit entsprechenden Tools? Die Profile (Temp zu Drehzahl) sollten ja eigentlich im BIOS abgelegt sein, aber da die meisten Karten noch irgendwelche Tuning-Tools mitbringen, könnte es auch sein, dass man da seine Präferenzen erst einstellen muss...

    Vielleicht ist das eine Überlegung:


    Standard stromsparenden VDR und daneben einen Gaming PC stellen, der bei Bedarf eingeschaltet wird.


    Hab mir ähnliche Gedanken gemacht, aber mit einer GTX960-980 würde mir der Rechner im VDR Betrieb zu viel Strom verbrauchen.


    Ja klar, habe ich auch schon überlegt, aber irgendwie sehe ich nicht ein bei 80-90% identischen Komponenten das ganze zwei mal hinzustellen. Zumal die max (!) TDP vom GTX960 "nur" noch 120W ist und dank GC5 (spezieller PowerSave State bei Video-Dekodierung) vermutlich viel Luft nach unten ist.


    Was 4k angeht, so würde ich beim VDR noch zuwarten, bis es entsprechende LowEnd Karten mit HDMI 2.0 und HEVC gibt.


    Naja, ich mußte damals bei HDTV auch als erster mitspielen, bei 4k wirds ähnlich. Ich sehe keine Maxwell (Bedingung für VDPAU, HDMI 2.0 und HEVC) Low-End Karte vor Ende 2015 gibt. Habe gelesen NVidia kommt schon nicht hinterher Chips für die 980/970 zu produzieren, weswegen auch die 960 so lange herausgezögert wurde. Gleichzeitig finde ich dass die 960 eben einen guten Kompromiss zwischen Nicht-End aber trotzdem spielefähiger Leistung darstellt.

    Nachdem mein mittlerweile 5,5 Jahre altes Atom 230 / ION (1) System nun langsam sein Lebensende erreicht, denke ich über ein aktuelles System nach, welches dann auch gleichzeitig (mal sehen ob Dual/Triple-Boot oder alles auf einer Distribution) als SteamMachine zum gelegentlichen Spielen dienen soll. Wohlgemerkt nicht für High-End Games, sondern mal eine Runde FIFA oder World of Tanks. Außerdem soll der VDR 4k-fähig sein um beim nächsten TV-Austausch (1-2 Jahre?) auch 4k-Content abzuspielen. Deswegen ist Maxwell 2ndGen (GM2xx) für mich Pflicht.


    Im Moment sehe ich dazu zwei Alternativen:
    Zotac ZBox EN860
    Selbstbausystem auf Broadwell-Basis mit GTX960


    Für die Z-Box sind die verwendeten Mobile-Komponenten gleichzeitig ein Plus (Effizienz, Abwärme -> Lautstärke) als auch ein Minus (Leistung), allerdings ärgert es mich ein bißchen, dass bei einem 2015 angekündigten Produkt noch so alte Technik drin steckt (GTX960M anstatt GTX965M, Haswell anstatt Broadwell).
    Bei einem Selbstbausystem habe ich wie immer das Problem mit dem Gehäuse. Von der GTX960 wird es sicher keine Low-Profile oder gar Single-Slot Karte geben, bei horizontalem Einbau per Winkel würde dann auch der Lüfter aufs Board blasen, bleibt also nur ein "Full-Size" Gehäuse für vertikalen (nicht-LP) Einbau. Damit ein Gehäuse welches es entweder nur in hässlich oder jenseits €200 gibt. Das steht imho in keinem vernünftigen Verhältnis zum Rest des Systems... Hat da jemand noch Alternativorschläge?

    Das Problem hatte ich neulich bei dem yaVDR eines Freundes auch. Bei ihm (keine Ahnung, ob das bei Dir das gleiche ist) lag es am Update des NFS Paketes: im Rahmen des Updates muss der Daemon neu gestartet werden, das funktioniert aber nicht automatisch. Nach einem kill -9 auf den Prozess (weiß nicht mehr was genau es war? rpc.portmapper?) ging dann ein manueller Restart per init-Script und erst danach lief das Upgrade durch.

    For everyone having problems with streamdev and decryption, please try if increasing TS_SCRAMBLING_TIMEOUT in the VDR's device.c makes a difference. I had a problem with EMM processing some time ago and it turned out vdr stopped sending data to the decryption plugin too early.

    I would expect you have to loop over the Read, as one call to Read only receives One UDP packet where in this situation we want to receive up to elementCount ones.


    try this (did not compile or test it):


    It compiles and runs, but doesnt work, no data at all -> VDSB


    I tried reverting the change as suggested TheChief (with some manual corrections due to other changes) and this is working fine.


    I'll try to come up with a patch that uses "if __GLIBC_PREREQ (2,12)" and works in the next days...