Danke für die schnelle Antwort, ja ist alles aus unstable-vdr (trusty). Aber daher stammt auch das vdr src Paket (welches dann beim bauen vdr, vdr-dev, vdr-dbg usw erzeugt). Ich werde mal mit testing-vdr (precise) testen...
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.:Quotemake[1]: Leaving directory '/usr/src/vdr-plugin-suspendoutput-2.0.0'
dh_auto_test
debian/rules binary
dh binary --with vdrplugin
dh_testroot
dh_prep
debian/rules override_dh_auto_install
make[1]: Entering directory '/usr/src/vdr-plugin-suspendoutput-2.0.0'
dh_auto_install --destdir=debian/vdr-plugin-suspendoutput
make[2]: Entering directory '/usr/src/vdr-plugin-suspendoutput-2.0.0'
install -D libvdr-suspendoutput.so /usr/src/vdr-plugin-suspendoutput-2.0.0/debian/vdr-plugin-suspendoutput/usr/local/lib/vdr/libvdr-suspendoutput.so.2.1.6
install -D -m644 po/fi_FI.mo /usr/src/vdr-plugin-suspendoutput-2.0.0/debian/vdr-plugin-suspendoutput/usr/local/share/locale/fi_FI/LC_MESSAGES/vdr-suspendoutput.mo
install -D -m644 po/it_IT.mo /usr/src/vdr-plugin-suspendoutput-2.0.0/debian/vdr-plugin-suspendoutput/usr/local/share/locale/it_IT/LC_MESSAGES/vdr-suspendoutput.mo
make[2]: Leaving directory '/usr/src/vdr-plugin-suspendoutput-2.0.0'
make[1]: Leaving directory '/usr/src/vdr-plugin-suspendoutput-2.0.0'
dh_install
dh_vdrplugin_enable
dh_vdrplugin_migrate
dh_installdocs
dh_installchangelogs
dh_perl
dh_usrlocal
dh_usrlocal: debian/vdr-plugin-suspendoutput/usr/local/share/locale/fi_FI/LC_MESSAGES/vdr-suspendoutput.mo is not a directory
rmdir: konnte »debian/vdr-plugin-suspendoutput/usr/local/share/locale/fi_FI/LC_MESSAGES“ nicht entfernen: Das Verzeichnis ist nicht leer
dh_usrlocal: rmdir debian/vdr-plugin-suspendoutput/usr/local/share/locale/fi_FI/LC_MESSAGES returned exit code 1
debian/rules:17: recipe for target 'binary' failed
make: *** [binary] Error 1
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules binary war 2
Build-Befehl »cd vdr-plugin-suspendoutput-2.0.0 && dpkg-buildpackage -b -uc« fehlgeschlagen.
E: Kindprozess fehlgeschlagen
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- [ 10.376060] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
- [ 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)
- [ 11.087934] usbcore: registered new interface driver dw2102
Natürlich gibt es die Datei:
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
-
Wenn Du gleichzeitig auf Kernel 3.13 gegangen bist, liegt es daran, dass Du keine Kernel-Header für 3.13.0-49 hast. Dadurch kann DKMS dann auch keinen zum Kernel passendes nvidia-Modul bauen, obwohl er installiert ist.
-
Streamen wollte ich eigentlich nix, aber den Verbrauch werde ich tatsächlich mal messen.
Favorisiere im Moment die hier: http://geizhals.de/inno3d-ichill-geforce-gtx-960-x3-air-boss-ultra-c960-2sdn-e5cnx-a1220631.html?hloc=at&hloc=de
Ich werde aber wohl noch auf Broadwell-K warten... -
I also had strange problems with my Cubietruck while I was using a 500mA power supply. All sorts of strange problems, sometimes when compiling, sometimes runtime. So the system seems to behave a bit odd when underpowered.
-
Letzteres, also VDR-Client (Aufnahmen vom Server, Live-TV direkt) + Gaming. Zum Aufzeichnen habe ich vdr direkt auf dem NAS laufen. Sowohl NAS als auch vdr clients werden per SAT>IP gefüttert.
Habe übrigens noch eine interessante Leistungsmessung gefunden: http://ht4u.net/reviews/2015/n…ng_2g_im_test/index18.php
11W Verbrauch bei BD Wiedergabe (aber natürlich unter Windows mit besser optimierten Treibern...) -
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...
-
ja tatsächlich, muss wohl mal die Batterie meiner Tastatur wechseln
-
Konnte schon jemand den "GC5" Stromsparmodus der Maxwell GPUs testen? Bringt das in Kombination mit VDPAU eine deutliche Verringerung der Leistungsaufnahme/Abwärme?
-
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. -
Das läuft aber beides nicht auf SteamOS, außer du möchtest es von einem weiteren PC streamen.
Deswegen ja den Kommentar Dual/Triple-Boot: Windows
Auf SteamOS gehen dann immerhin Klassiker wie Counterstrike etc.Aber hier soll es erstmal nur um die Hardware gehen.
-
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 GTX960Fü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.
-
This suggestion came from manio for the dvb*** plugin. I went up to 60s but unfortunately in my particular case it did not help, but I thought in this context it may be beneficial to give it a try.
-
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.
-
Which firmware version of the OctopusNET is recommended right now? I'm still running 1.0.29 as I read about problems with later versions, have these been confirmed/addressed already?
-
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 -> VDSBI 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...