Probier mal als workaround softhddevice im "suspended + detached" mode mit in die gestarteten Plugins aufzunehmen (-s -D), ich denke dann laesst sich nOpacity dazu ueberreden, keine Probleme mehr zu machen. Ich glaube mich zu erinnern, als ich versuchte, fuer xineliboutput das neue Scaling-API zu patchen (habe es letztendlich wegen der komplizierten client/server Implementierung aufgegeben, weil es nicht rund lief) das so hinbekommen zu haben, also softhddevice inaktiv geladen und trotzdem xineliboutput (mit vdr-sxfe) genutzt.
Danke für den Tipp, das werde ich morgen mal ausprobieren, auch wenn das mehr als ein Workaround ist
[Schon wieder OT]
[Noch ein bisschen weiter mit OT]
Willst Du keinen Dekoder im VDR-Kern aus irgend einem praktischen, oder bloss ideologischen Grund?
Zum einen finde ich Software sollte immer soweit getrennt und modularisiert werden wie es einfach möglich ist, vor allem aber gehört immer Frontend und Backend getrennt (da das Frontend immer fehleranfälliger und schwieriger zu testen ist), aber da denke ich vermutlich auch zu stark als Java-Webentwickler... (Ich überlege immer noch ob ein REST-Plugin für VDR Sinn macht ;))
Aber davon abgesehen ist meine Erfahrung dass vdr-sxfe deutlich öfter abstürzt als der VDR selber... und wenn ich überlege dass jedes mal eine Aufnahme kaputt gehen könnte weil mal ein Stream nicht in Ordnung ist oder der Grafikkarten-Treiber spinnt oder so... der VDR-Prozess sollte sich auf das konzentrieren wofür er da ist: Aufnehmen und Streams rausgeben.
Ich z.B. waere auch Freund von open source Treibern, aber wenn es die nicht "in brauchbar" gibt, nutze ich halt nVidia und deren wirklich gute closed-source Treiber ohne das es mich weiter juckt. Genauso habe ich mich mal dazu entschlossen (nutzte frueher auch vdr-sxfe weil ich das Frontend auschalten konnte um XBMC bei fortlaufendem VDR starten konnte), trotz fehlender expliziter Client/Server Unterstuetzung in Softhddevice, dieses auszuprobieren als es reifer wurde und seither brauche ich kein anderes natives VDR-Frontend, alles vernetzte kann an Streamdev oder den XBMC-spezifischen Protokollen des VDR-Servers connecten. Ich bin auch fuer die Trennung der VDR-Instanz die fast immer laueft, weil sie auch dann wenn man nicht live guckt fuer Aufnahmen zustaendig ist und auf keinen Fall unnoetige Energie mit Dekodieren verbraten soll (und ganz nebensaechlich, zufaelligerweise oft Server genannt wird), und das Frontend zum gucken (ob nun ein tatsaechlicher Client, oder auch "nur" Softhddevice aktiviert bloss wenn man es braucht. Es kommt also vielmehr auf das Ergebnis als soches an, und mit Softhddevice kann man das auch erzielen.
Wie meinst Du das, was an den Moeglichkeiten die Softhddevice alleine bietet, stellt Dicht nicht zufrieden in deinem Anwendungsszenario (welches wenn ich es richtig verstehe, nicht weit von meinem sein kann)
[/Noch ein bisschen weiter mit OT]
Ob die Treiber Open Source oder Closed sind ist mir auch egal, wie gesagt ich verwende fglrx... Ich sehe es nur nicht ein wenn ich Hardware besitze die das kann mir neue zu kaufen, nur weil die Software nicht passt... und mein VDR läuft mit xineliboutput und Xv ja auch zufriedenstellend, nur halt nicht mit diesem Skin und die Probleme des Skins hier sind auf jeden Fall reine Software-Probleme...
Und was mir softhddevice nicht bietet sind halt die oben angesprochene strikte Prozesstrennung und evtl. auch die Netzwerkfähigkeit... Ich finde es schon praktisch auch in der Küche oder auf dem Balkon mit dem Laptop rumzappen zu können... Und seit ich ein Tablet habe überlege ich auch schon mir dafür was zu basteln... nur zur komfortablen Nutzung brauche ich das OSD, und da reicht dann streamdev schon nicht mehr... und die PVR-Unterstützung in XBMC habe ich ehrlich gesagt noch nie wirklich gemocht, zu wenig intuitiv zu benutzen, zu eingeschränkt und zu viele Kinderkrankheiten als ich sie das letzte mal testete...
[/Schon wieder OT]