[SkinNopacity] Aktuelle Probleme
-
-
Vielleicht lässt sich das Ein oder Andere auch in den master übernehmen.
Gerne, habe ich aber nicht getestet.
Gruss,
S:oren
-
Gibt es dazu eine Commit-ID?
Den nervigen Fehler habe ich auch ...Die Commits haben ja eine kleine Beschreibung und bauen zum Teil aufeinander auf. Bevor man da irgendwas auseinanderreißt, wuerde ich lieber warten, bis/ob kamel5 da irgendwas uebernimmt.
Gruss,
S:oren
-
Gute Frage. Hatte zwei Probleme:
a) Seit FFMEPG 4.x führt Springen in Aufnahmen zu Klötzchen.
Ist das Wiedergabefenster (Fortschritt) dabei zu, passiert nix weiter.
Ist es auf, kommt ein GPF (1), denke das ist aber ein vaapi Bug.
b) Steht das Ding in einer Aufnahme auf Pause, läuft, wenn man lange genug wegbleibt, Live-TV.
Nach Neustart natürlich. Macht er aber nie, wenn ich den gdb dranhänge... Grr.
Fehler scheint aber jetzt -- nach 30 Minuten Pause -- wohl behoben. Wird beobachtet.
Backtrace zu (1):
Code
Alles anzeigenThread 41 "vaapi video" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f21e6ffd700 (LWP 5442)] 0x00007f225c345c5d in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1 (gdb) bt #0 0x00007f225c345c5d in ?? () from /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1 #1 0x00007f225c3fbf41 in intel_batchbuffer_emit_reloc64 ( batch=batch@entry=0x7f21dc2228e0, bo=0x0, read_domains=read_domains@entry=2, write_domains=write_domains@entry=0, delta=delta@entry=0) at intel_batchbuffer.c:176 #2 0x00007f225c3b418b in bdw_veb_dndi_iecp_command ( ctx=ctx@entry=0x562758eeb770, proc_ctx=proc_ctx@entry=0x7f21dc0427e0) at gen75_vpp_vebox.c:1921 #3 0x00007f225c3b43a0 in gen8_vebox_process_picture ( ctx=ctx@entry=0x562758eeb770, proc_ctx=0x7f21dc0427e0) at gen75_vpp_vebox.c:1993 #4 0x00007f225c3ae48b in gen75_vpp_vebox (ctx=ctx@entry=0x562758eeb770, proc_ctx=proc_ctx@entry=0x7f21dc29a840) at gen75_picture_process.c:84 #5 0x00007f225c3af03f in gen75_proc_picture (ctx=0x562758eeb770, profile=VAProfileNone, codec_state=0x562759c2a7c8, hw_context=0x7f21dc29a840) at gen75_picture_process.c:479 #6 0x00007f227c62aaa0 in vaEndPicture (dpy=0x562758ec2060, context=33554433) at va.c:1629 #7 0x00007f227c76dfef in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #8 0x00007f227c76ee21 in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 --Type <RET> for more, q to quit, c to continue without paging-- #9 0x00007f227c76f221 in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #10 0x00007f227c770017 in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #11 0x00007f227c771572 in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #12 0x00007f227c7795f3 in CodecVideoDecode () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #13 0x00007f227c769951 in VideoDecodeInput () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #14 0x00007f227c772975 in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #15 0x00007f227c774ccc in ?? () from /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.6 #16 0x00007f22807fafa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #17 0x00007f22802ef4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95Wo zum Henker das vaapidevice-dbg ist? k.A.
Stefan
-
...habe mir den Devel-Branch auch mal installiert. 😉
Nutze eine FF HD 6400 auf einem Arm-Matrix (imx6 Quadcore).
Beim laden der Aufnahmeinfo bekomme ich folgendes:Insgesamt ist der Skin sehr zäh... deshalb wohl der Devel-Branch?!
-
...habe mir den Devel-Branch auch mal installiert. 😉
Nutze eine FF HD 6400 auf einem Arm-Matrix (imx6 Quadcore).
Beim laden der Aufnahmeinfo bekomme ich folgendes:Die Fehlermeldung kannst Du erst einmal ignorieren.
Im Moment geht es im Devel-Branch um das zeitversetzte Auftauchen von Informationen, z.B. bei der Programminfo oder Recordingsinfo.
Insgesamt ist der Skin sehr zäh... deshalb wohl der Devel-Branch?!
Na ja, was bedeutet zäh? Der Skin ist schon Resourcenintensiv, vor allem, wenn auch Bilder angezeigt werden.
Ich nutze auch die TT6400, allerdings mit x86, da funktioniert das schon recht ordentlich, wenn man die Einblendzeiten auf 0 stellt. In den Menüs z. B. kann ich keine Verzögerungen feststellen.
Grüße
kamel5
-
Ich habe dazu mal einen Branch Devel unter gitlab.com/kamel5/SkinNopacity angelegt.
Oh ha, das gibt es ja eine Menge Aenderungen in dem Devel-Branch.
Wenn Du mich danach fragst, kann ich ja mal ein kleines Review machen. Sind natuerlich alles unverbindliche Anregungen und sicher nicht der Weisheit letzter Schluss.
Zunaechst finde ich einen Devel-Branch gut, so ein Fix eines Fixes mit sofort einer neuen Versionsnummer sieht immer nach uebereiltem Commit aus. Meistens bringt es etwas, wenn andere Leute vor einem Release etwas ansehen oder testen.
Zu den Patches selbst:
- "Cleanup imgCache declaration" finde ich gut, wollte ich auch schon machen (in einer neuen Version nach meinen letzten Patches). Nur passen Patch-Titel und -Beschreibung (die mir irgendwie bekannt vorkommen) m.E. nicht. Hier wird ja nicht die Deklaration aufgraeumt, sondern ein Objekt global abgelegt, was vorher lokal war und immer explizit weitergereicht wurde. Im Ergebnis ergibt es aber viel Sinn, den imgCache genau wie den geoManager anzusprechen.
Nur warum gibt es 2 Patches mit dem selben Titel? Zuerst den zweiten Teil vergessen? Dafuer gibt es 'git rebase -i' und "fixup"...
- "Cleanup optimized Start()", "Fixed an error in Displaychannel - the clock wasn't updated.", "Eliminate init in nopacity.c"
Ergibt alles fuer mich Sinn. Wenn man "Erbsen zaehlen" will, Patch-Titel sind immer (sonst) im Imperativ, also "Fix error" statt "Fixed an error".
- "Rename detailview.* to view.*", "Rename menudetailview.* to detailview.*"
In Umbenennungen sehe ich keinen Wert, aber ich kenne auch die anderen Skins nicht, zu denen man hier offenbar kompatibel sein will.
- "Some cosmetic changes"
An sich sinnvoll. Wie ich es gelernt habe, gehoeren Whitespace-Cleanup und funktionale Aenderungen (long -> int in for-Schleifen) nicht in einen Patch.
- "Cleanup menuView declaration"
Das halte ich fuer einen Fehler. Globale Variablen sind immer eher schlecht. Hier wird auch noch eine Klasse DisplayMenuView, die nur in DisplayMenu benutzt wird, global abgelegt. Ergibt fuer mich wenig Sinn. Fuer mich gehoert die ganze Klasse DisplayMenuView komplett in die Klasse DisplayMenu integriert. Macht alles viel einfacher und erlaubt weitere Codeoptimierungen.
- "Eliminate cNopacityDisplayMenuView::SetAvrgFontWidth", "Make cView::SetFonts privat"
Ergibt fuer mich Sinn.
- "Some simplifications"
Hab ich nicht im Detail angesehen, vereinfacht aber den Code, ergibt somit Sinn.
- "Eliminate detailView in cNopacityDisplayMenu"
Das verstehe ich nicht, da fehlt mir zumindest eine Erklaerung. Auch bläht es den Code extrem auf, erscheint mir nicht sinnvoll. Scheint auch neue Threads zu erzeugen, was ich fuer einen großen Fehler halte (langsam, fehleranfaellig, unuebersichtlich).
- "Faster display info"
Auch wieder ein zusaetzlicher Thread, wobei ich gar nicht sehe, wo der gestartet wird.
Nach der "reinen Lehre" soll ein Skin nur darstellen, was der VDR vorgibt. Dabei soll ein Skin keine zusaetzlichen Flush()-Operationen erfinden (was bei der S2-6400 extrem langsam ist), sondern nur dann einen osd->Flush() ausfuehren, wenn vom VDR ein Flush() angefordert wird. Das ist hier, was die Performance-Verbesserung bringt.
Auch soll ein Skin eigentlich keine eigenen Threads haben. Wie schon vorher geschrieben, im Hintergrund Bilder laden, die vielleicht skalieren und und in Pixmaps wandeln, OK, wenn man es richtig macht und die Threads richtig synchronisiert. Aus mehreren Threads auf ein OSD schreiben, m.E. immer verkehrt.
Ja, das Faden geht nur mit eigenen Thread, aber dann bitte nach dem kompletten Aufbau des OSD nur noch das Alpha aendern. Wobei ich nie ein Fade-In verwendet habe (nur ein Fade-Out frueher mit skinelchi, kann skinnopacity gar nicht), und auch das ist mittelmäßig unschoen, wenn man von einem Menue auf ein anderes umschaltet, was man als Skin leider nicht (einfach) erkennen kann. Auch zum Scrollen von Menueeintraegen braucht man vermutlich Threads, habe ich mir noch nicht im Detail angesehen. Ansonsten machen zusaetzliche Threads nichts schneller, nur komplizierter.
Es wäre schön, wenn Du das mal auf Deiner Hardware testen könntest.
Hab die selbe Hardware, die Uwe beschrieben hat.
Wie schon vorher geschrieben, den 1.1.x-Branch mit den ganzen Threads halte ich fuer kaputt. Der 1.0.x-Branch funktioniert fuer mich ohne "Powerpoint-Effekt", nur diesen Branch finde ich als Ausgangspunkt fuer weitere Entwicklungen geeignet (ein paar Ideen haette ich da noch).
Ich hoffe, ich habe mich jetzt nicht zu unbeliebt gemacht...
Gruss,
S:oren
-
Ich hoffe, ich habe mich jetzt nicht zu unbeliebt gemacht...
Also nicht bei mir. Als Hobby-Programmierer, der sich das in Self Made Manier angeeignet hat, ist man für jeden konstruktiven Hinweis dankbar.
Nur warum gibt es 2 Patches mit dem selben Titel? Zuerst den zweiten Teil vergessen? Dafuer gibt es 'git rebase -i' und "fixup"...
Das habe ich kommen sehen...
Nicht vergessen, nur vor dem Upload vergessen, zusammenzuführen...In Umbenennungen sehe ich keinen Wert, aber ich kenne auch die anderen Skins nicht
Das mag im Allgemeinen richtig sein. Bei Louis Plugins wiederholt sich allerdings Vieles, so habe ich es dann einfacher, Dinge zu vergleichen.
Wie ich es gelernt habe, gehoeren Whitespace-Cleanup und funktionale Aenderungen (long -> int in for-Schleifen) nicht in einen Patch.
Das habe ich nicht ganz verstanden.
- "Cleanup menuView declaration"
Das halte ich fuer einen Fehler. Globale Variablen sind immer eher schlecht. Hier wird auch noch eine Klasse DisplayMenuView, die nur in DisplayMenu benutzt wird, global abgelegt. Ergibt fuer mich wenig Sinn. Fuer mich gehoert die ganze Klasse DisplayMenuView komplett in die Klasse DisplayMenu integriert. Macht alles viel einfacher und erlaubt weitere Codeoptimierungen.
Das ist auch mein Ziel. Im Moment wollte ich damit nur die Zusammenhänge besser verstehen.
- "Eliminate detailView in cNopacityDisplayMenu"
Das verstehe ich nicht, da fehlt mir zumindest eine Erklaerung. Auch bläht es den Code extrem auf, erscheint mir nicht sinnvoll. Scheint auch neue Threads zu erzeugen, was ich fuer einen großen Fehler halte (langsam, fehleranfaellig, unuebersichtlich).
Neue Threads macht das nicht, es ist immer nur einer aktiv. Und dient erst einmal auch zum besseren Verständnis.
- "Faster display info"
Auch wieder ein zusaetzlicher Thread, wobei ich gar nicht sehe, wo der gestartet wird.
Auch kein neuer Thread.
Hier ist eigentlich nur die Änderung in displaymenu.c wichtig. Die eigentliche Ursache für das "Powerpoint" ähnliche Verhalten lag an diesem Flush.
In dem es jetzt bei laufenden Threads nicht mehr aufgerufen wird, wird dieser Effekt eliminiert.
Jetzt sehe ich auch, was Du mit den neuen Threads meinst. Das sind keine neuen Threads, das dient nur zur eindeutigen Identifikation in den Logs, diese Threads gab es vorher auch schon.
Nach der "reinen Lehre" soll ein Skin nur darstellen, was der VDR vorgibt. Dabei soll ein Skin keine zusaetzlichen Flush()-Operationen erfinden (was bei der S2-6400 extrem langsam ist), sondern nur dann einen osd->Flush() ausfuehren, wenn vom VDR ein Flush() angefordert wird. Das ist hier, was die Performance-Verbesserung bringt.
Wie schon vorher geschrieben, den 1.1.x-Branch mit den ganzen Threads halte ich fuer kaputt. Der 1.0.x-Branch funktioniert fuer mich ohne "Powerpoint-Effekt", nur diesen Branch finde ich als Ausgangspunkt fuer weitere Entwicklungen geeignet (ein paar Ideen haette ich da noch).
Ja, in einer idealen Welt... Leider wollen viele Anwender halt ein Bling-Bling.
Deshalb kann ich diese zusätzlichen Sachen auch nicht einfach wieder ausbauen, dann beschwert sich bestimmt jemand.
So werde ich das Ganze wohl konfigurierbar machen müssen...
Grüße
kamel5
-
... ist man für jeden konstruktiven Hinweis dankbar.
Freut mich! Wirklich.
Das habe ich nicht ganz verstanden.
Da kommen die Reflexe als U-Boot-Board-Maintainer und Linux-Progammierer durch.
Dort ist es absolut verpoent, Aenderungen von Whitespace (Leerzeichen, Tabs) und funktionale Aenderungen in einem Patch zu mischen. Das wird nicht akzeptiert. So eine Policy gibt es hier natuerlich nicht. In eigenen Projekten versuche ich dennoch, mich an die Linux-Regeln zu halten, weil ich die sehr gelungen finde.
Die eigentliche Ursache für das "Powerpoint" ähnliche Verhalten lag an diesem Flush.
Wie bereits gesagt, jeder im Skin erfundene Flush ist einer zuviel. Die aus meiner Sicht einzig richtige Loesung waere, den Code so umzustellen, dass sowas nicht noetig ist.
Jetzt sehe ich auch, was Du mit den neuen Threads meinst. Das sind keine neuen Threads, das dient nur zur eindeutigen Identifikation in den Logs, diese Threads gab es vorher auch schon.
Muss ich zugeben, habe ich nicht genau hingesehen. Da lag ich falsch.
Das generelle Problem aber bleibt. Das Anlegen von Threads ist eine sehr teure Operation. Warum in aller Welt startet man staendig dynamisch neue Threads, laesst die ueberwiegend gar nicht parallel laufen, handelt sich Synchronisationsprobleme damit ein und spart am Ende gar nichts, im Gegenteil?
Ja, in einer idealen Welt... Leider wollen viele Anwender halt ein Bling-Bling.
Und die Anwender, die einfachen und schnellen Code wollen, muessen sich mit dem ganzen Overhead herumaergern!?
Ganz im Ernst, was ist denn eigentlich die Zielgruppe fuer die verschiedenen louis -Skins? (Welche gibt es ueberhaupt mittlerweile?)
Aus meiner Sicht:
Zuerst war skinnopacity, tolles Design, frische Ideen (z.B. schmale Menues), großartig! Das war fuer mich ein HD-VDR!
Ein bisschen behaebig, (z.B. durch dynamische Objekte sogar fuer jeden menuitem, Verwendung von imagemagick), noch benutzbar auch auf sparsamer/langsamer Hardware. Den damals fuer mich größten Performancekiller konnte ich durch Einbringen eines einfachen und schnellen Image-Skalers beseitigen. So habe ich das jahrelang verwendet und verwende es heute noch.
Dann kam skinnopacity-1.1.0, der Versuch, alles denkbare in dieses Plugin hineinzuquetschen. Fuer mich das Ende von Performance und Wartbarkeit. Zu irgendwelchen Aufraeumarbeiten am Code kam es nicht mehr, weil auch louis nichts mehr mit dem Code zu tun haben wollte (so sah es zumindest fuer mich aus).
Stattdessen kam skindesigner. Viel zu langsam fuer mich, aber die Feature-Spielwiese, die viele Leute mit potenter Hardware haben wollten. Fein.
Wie soll nun die Zukunft aussehen?
Ich wuensche mir ein Skin mit look&feel von skinnopacity, ohne viel Bling-Bling (nur Channel-Logos), aber ohne Kompromisse bei Codequalitaet und Geschwindigkeit. Das sehe ich durch Weiterentwicklung (vielleicht auch Abspecken) des 1.0.x-Branch gegeben. (Vorher wuerde ich gerne noch den letzten verbliebenen Bug fixen: die durch das nicht vdr-konforme Handling der Menueeintrage fehlende Möglichkeit, im remote-Plugin eine Fernbedienung anzulernen.)
Das vertraegt sich leider nicht mit Deinem Ansatz, noch mehr Konfigurierbarkeit einzubauen und alle bestehenden Erker beizubehalten. Und dann sogar den Code der schon jetzt verschiedenen Plugins wieder zu vereinheitlichen. Das kann die vorhandene Komplexitaet nur weiter steigern.Wie loest man diesen Widerspruch am besten? Gute Frage!
Waere interessant, welche Features der verschiedenen Skins wirklich aktiv genutzt werden.
Gruss,
S:oren
-
Wie loest man diesen Widerspruch am besten? Gute Frage!
Waere interessant, welche Features der verschiedenen Skins wirklich aktiv genutzt werden.
Ja, das wird man aber wohl nicht erfahren. Es gibt hier im Forum einfach zu wenige, die dazu mal was posten, da die meisten sicher eine fertige Distribution benutzen.
Ich selber nutze diesen Skin auch nicht, auch keinen Skindesigner Skin, nur das TVGuide-Plugin (das funktioniert mittlerweile auch recht gut mit der TT6400) von Louis. Als Skin habe ich mir einen etwas angepassten LCARS-Skin gemacht, ja das ist nicht jedermanns Sache, aber für meine Zwecke mit der TT6400 ideal. Da hätte ich aber gern noch ein paar Sachen und das hier ist dazu meine Spielwiese, mal zu schauen, was geht und was nicht so toll geht.
Das vertraegt sich leider nicht mit Deinem Ansatz, noch mehr Konfigurierbarkeit einzubauen und alle bestehenden Erker beizubehalten. Und dann sogar den Code der schon jetzt verschiedenen Plugins wieder zu vereinheitlichen. Das kann die vorhandene Komplexitaet nur weiter steigern.
Das war nur so eine Idee. Ich hätte auch kein Problem damit, die Light-Version abgespeckt separat fortzuführen und den master noch etwas zu optimieren, aber grundsätzlich so zu lassen. (Der letzte Stand vom Devel-Branch läuft auf meiner x86 Hardware mit der TT6400 doch recht zügig.) Für beide Varianten gibt es sicher eine Zielgruppe.
Den damals fuer mich größten Performancekiller konnte ich durch Einbringen eines einfachen und schnellen Image-Skalers beseitigen.
Das würde mich auch interessieren, was Du da gemacht hast.
Wenn Du also noch Patches hast für den light_version Branch, immer her damit.
Grüße
kamel5
-
Das würde mich auch interessieren, was Du da gemacht hast.
Der Code ist in imagescaler.[ch], es gibt einen Eintrag in der HISTORY (wieso ist da die Reihenfolge der Versionen jetzt so merkwierdig?) dazu. Die Idee hatte ich mit einem Freund in der Kaffeepause im Buero diskutiert, er hat das dann schnell zusammengehackt und dankenswerterweise zur Verfuegung gestellt. Die Einbindung koennte verbessert werden, aber ich wuerde dann gleich noch den Rest der *magick 'rauswerfen, die m.E. viel mehr Probleme verursacht, als loest.
Wenn Du also noch Patches hast für den light_version Branch, immer her damit.
Bisher mehr Ideen als Patches. Aber wenn ich mich da austoben darf, kann ich mir vielleicht mal Zeit nehmen. Die spannenden Sachen sind natuerlich nicht die vernuenftigen, also erstmal Bug fixen. Andererseits kann ja jeder auch die existierenden Versionen benutzen, wenn die neuen nicht gefallen. Der nervigere Bug war der segfault bei den Messages.
Vermutlich werden die Distri-Leute recht ungluecklich, wenn es 2 aktive Branches in einem Plugin gibt. Nicht so ideal.
Gruss,
S:oren
-
es gibt einen Eintrag in der HISTORY (wieso ist da die Reihenfolge der Versionen jetzt so merkwierdig?) dazu.
Ich hatte mal angefangen, die neuesten Einträge nach oben zu nehmen, damit man beim Öffnen gleich den letzten Stand sieht. Das muss ich mal vollenden.
Vermutlich werden die Distri-Leute recht ungluecklich, wenn es 2 aktive Branches in einem Plugin gibt.
Da würde ich mir im Moment nicht so viel Gedanken darüber machen. Das gibt es bei anderen Plugins auch schon.
Wenn nötig, kann die light Version auch einen neuen Namen bekommen, zB. skinnopacitylt.
Bisher mehr Ideen als Patches. Aber wenn ich mich da austoben darf, kann ich mir vielleicht mal Zeit nehmen.
Immer zu. Dann kümmere ich mich erst einmal weiter um den master Branch und übernehme passende Sachen auch in die light Version.
Heute ist mir auch noch ein Bug mit Grafiken in beiden Versionen aufgefallen, den muss ich mal endgültig fixen.
Grüße
kamel5
-
kamel5: Ich finde es toll, dass Du Dich um das Plugin kümmerst. Vielleicht magst Du Dir auch mal folgendes Problem anschauen: Wenn man bei geöffnetem OSD mit den separaten Tasten für Programm rauf/runter die Kanäle wechselt, wird das kurz stehen bleibende Bild des alten Kanals im Vorschaufenster immer ein Stück schmaler und zittert.
siehe Beispiel hier
Rahmenbedingung: softhddevice von lnj mit aktiviertem ClearOnSwitch und Blackpicture.
Eigentlich sollte beim Umschalten das Vorschaufenster das gleiche anzeigen wie bei geschlossenem OSD - das Bild wird sofort schwarz und danach kommt das neue Bild. Ich könnte auch damit leben, wenn es ohne Berücksichtigung des Blackpicture wäre - aber dann sollte das alte Bild beim Freeze nicht zittern und auch nicht abgeschnitten werden.
Spaßeshalber habe ich das ganze mal mit deaktivierten ClearOnSwitch/Blackpicture ausprobiert. Nach ein paar mal Zappen, wobei der Kanalwechsel zeitverzögert, aber zitterfrei abläuft, ist da ganze OSD eingefroren, ohne dass man im Log etwas sieht.
Hinweis: Zum Testen brauchst Du eine FB mit separaten Tasten für Up/Down sowie Channel+ /Channel- da ansonsten bei geöffnetem OSD die Up/Down-Tasten nur die Navigation im OSD bewirken.
-
mit der Änderung ist es das gleiche.
Das Problem tritt auch nur auf, wenn Blackpicture aktiviert ist. Da das im softhdcuvid von jojo61 nicht mehr funktioniert (die Einstellung hat dort keine Funktion mehr) habe ich auch keinen Vergleich.
Habe nun aber mal softhddevice von lnj mit cuvid statt vdpau ausprobiert - da tritt das Problem nicht auf! Also ein Bug im vdpau-Teil von soifthddevice, und der Skin ist unschuldig.
-
I'll check vdpau.
-
Vorher wuerde ich gerne noch den letzten verbliebenen Bug fixen: die durch das nicht vdr-konforme Handling der Menueeintrage fehlende Möglichkeit, im remote-Plugin eine Fernbedienung anzulernen.
Hab ich am Wochenende mal gefixt, siehe hier.
Heute ist mir auch noch ein Bug mit Grafiken in beiden Versionen aufgefallen, den muss ich mal endgültig fixen.
Was funktioniert da nicht richtig? Mir ist bisher nichts aufgefallen...
Gruss,
S:oren
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!