[Announce] nOpacity 0.1.1

Zitat von Zoolook

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]

Zitat von Zoolook

[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.

Zitat von Zoolook

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]

Alles anzeigen

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]

Zitat von louis

Moin,

na dann liefere doch einen Patch, der das Problem behebt. Ich habe das ganze Xine gedöns nicht mehr am laufen und werde es auch nicht mehr zum laufen bringen...deshalb bin ich da auf Input angewiesen.

Prinzipiell musst du eigentlich nur konsequent in allen public Methoden der jeweiligen Skin Klassen (inklusive der Konstruktoren / Destruktoren), die vom VDR aufgerufen werden, prüfen, ob das osd Objekt NULL ist und falls ja, direkt ein return einbauen. Hier findest du eine ganz gute Übersicht, wie ein Skin aufgebaut ist. Dann sollte der VDR auf jeden Fall nicht abstürzen. Ich denke, wenn du das in displaychannel, displaymessage und displaymenu anwendest, sollte es passen.

Ciao Louis

Alles anzeigen

Das werde ich mir die Tage mal anschauen, sollte dann ja nicht so aufwendig sein

Gemäss hier, zeigt das Stereo Symbol ja nicht an, ob es Stereo ist, sondern ob es sich um eine MPEG1/2 Tonspur handelt:

Symbole für Stereo/DD funktionieren nicht richtig

Daher schlage ich vor, dass Symbol in mpegon/off umzubennen und

if (Channel->Apid(1)) {

in

if (Channel->Apid(0)) {

zu ändern, damit es auch angezeigt wird, wenn nur eine Tonspur vorhanden ist.

Meinungen?

Hm, ich dachte Dpid wären dann die Dolby Spuren. Kann aber auch sein, dass ich falsch liege und Apid alle spuren inkl. Dolby enthält, dann bringts natürlich nichts. Dann müsste man gemäss channels.conf im Wiki prüfen, welchen Wert Apid enthält.

3 für MPEG1 (z. B. ...:101=deu@3;103=deu@106:...)
    106 für Dolby (z. B. ...:101=deu@3;103=deu@106:...)
    4 für MPEG2 (z. B. ...:101=deu@4;103=deu@106:...)

Ob das immer zutreffend ist, weiß ich auch nicht.

Zitat von louis

Sicher bin ich mir auch nicht...aber ansonsten wäre die Aussage von Klaus im anderen Thread falsch. Ich schaue mir das irgendwann mal an, wenn ich dazu komme...ich finde das aber nicht sooo wichtig, hauptsache es kommt überhaupt ein Ton Vielleicht mag ja auch mal jemand anderes das genauer unter die Lupe nehmen und einen Patch vorschlagen...

Welcher Thread? Ich hatte mal angefangen, mir das in den VDR-Sourcen anzusehen, ich denke da muss angesetzt werden, die Interpretation von Dpid so wie sie Klaus vor vielen Jahren definiert hat ist vermutlich unzureichend...

Ciao, Lucian

Also apids nur MPEG, dpids nur Dolby

Zitat von louis

...ich finde das aber nicht sooo wichtig, hauptsache es kommt überhaupt ein Ton Vielleicht mag ja auch mal jemand anderes das genauer unter die Lupe nehmen und einen Patch vorschlagen...

Na ja, wichtig ist das ganz bestimmt nicht, aber ich bin halt der Meinunung, dass wenn es angezeigt wird, dass sollte die Anzeige auch stimmen.

Wenn man weiß, was sie derzeit bedeutet, stimmt sie ja auch. Macht halt nur keinen Sinn

Und was für eine Bedeutung hat sie derzeit?

Das erste zeigt an, ob es mehr als eine Audiospur hat und das zweite, ob es eine DD Spur hat. Hab ja weiter oben einen Vorschlag gemacht, dies zu ändern. Mal sehn, wann louis Zeit dazu hat.

Wenn ich das jetzt richtig verstehe, dann gibt es gar keine Anzeige für Stereo, sondern nur, ob es MPEG1, oder MPEG2, oder keines von beiden gibt?

Falls ja, dann ist die Lösung doch recht einfach.

Ein Logo für MPEG1, ein Logo für MPEG2 und ein Logo für keines von Beiden.

Eigentlich wurden da Aepfel (welches Tonformat) mit Birnen (wieviele Tonkanaele vorhanden sind) schon tiefer im Core-VDR zusammengematscht. Ich denke es waere noetig, hierarchisch zwischen verfuegbaren "Tonspuren", dann innerhalb der Tonspur, welches Format und gleichzeitig wieviele Tonkanaele verfuegbar sind, zu untrerscheiden. Danach kann man sich schicke Logos ausdenken, eines fuer welche von den verfuegbaren Tonspuren gerade selektiert ist (es kann auch die Flagge der Sprache sein, aber manchmal laesst sich nicht auf die Sprache eindeutig rueckschliessen, vielleicht ist eine Textangabe doch sinnvoller an der Stelle, es sei denn, die besonders als "narrative" gekennzeichneten Spuren sind auch standardisiert...), erst danach das Format und die Anzahl (und gleichzeitig kann man auch abhaengig davon, oder aus dem Stream-Typ auch auf die raeumliche Anordnung der Tonkanaele schliessen, das liesse sich auch wunderbar symbolisch abbilden, macht es doch die Mehrheit der Consumer-Elektronik) der Tonkanaele der gewaelten Tonspur...

Ciao, Lucian

Hallo..

Zitat

Die zweite Änderung hat BooStar sich gewünscht...damit kann jetzt konfiguriert werden, dass im Kanalmenü zusätzlich zum Kanal nicht die Transponderinformationen, sondern das aktuelle Programm angezeigt wird. In diesem Modus wird nicht rechts das vollständige EPG eingeblendet, das fand ich dann irgendwie doppelt gemoppelt

Vielen lieben Dank..Sieht schon ganz gut aus..Die Option die Menüelemente anzuziegen sollte vllt. noch optional sein Außerdem wäre es klasse wenn man nur das "Aktuelle Programm", also nicht die Zeit anzeigen lassen könnte.. Die Zeit sorgt hier für einen Zeilenumbruch.. das finde ich nicht so schön..

Vielleicht liest ja ein Entwickler von extrecmenu hier mit. Das Problem mit der fehlenden Anzeige der Verzeichnisse ist, dass dort in mymenurecordings.c SetItemRecording() nicht mit dem level aufgerufen wird, mit dem
myMenuRecordingsItem() selber erzeugt wird. Ein quick-and-dirty Patch sieht so aus:

--- a/mymenurecordings.c
+++ b/mymenurecordings.c
@@ -160,6 +160,7 @@ eOSState myMenuRecordingInfo::ProcessKey
 // --- myMenuRecordingsItem ---------------------------------------------------
 myMenuRecordingsItem::myMenuRecordingsItem(cRecording *Recording,int Level)
 {
+  int savedlevel = Level;
 #if VDRVERSNUM >= 10733
   recording=Recording;
 #endif
@@ -446,6 +447,7 @@ myMenuRecordingsItem::myMenuRecordingsIt
         title=strdup("");
     }
   }
+  level=savedlevel;
   SetText(title);
 }

Also entweder in den Bugtracker von extrecmenu oder einen Thread aufmachen. So geht das mit aller Wahscheinlichkeit unter.

Danke, der Patch funktioniert!

Ich schlage vor, die default Ordnericon Grösse auf 96 zu stellen.
Das macht das Aufzeichnungsmenü übersichtlicher.
Bei kleineren Grössen, z. B. 64 schieben sich die Texte ineinander.
Ist es wirklich sinnvoll, die Dauer und die Aufnahmedauer gesondert
anzuzeigen? Ich denke, die Aufnahmedauer alleine reicht völlig aus.