nOpacity 0.0.4

  • Hi,
    ich habe mit der neuen Version immer Abstürze beim Öffnen von EPGsearch (über feste Taste KEY_EPG) und anschließendem Schließen durch dieTaste KEY_ESC. Damit schmiert hier 100%ig der VDR ab. Kann das jemand virifizieren?


    [EDIT]
    Allgemein kommt es sehr oft zu Abstürzen, auch beim normalen Öffnen des EPG über KEY_EPG... Aber irgendwie ist immer epgsearch beteiligt!

    Einmal editiert, zuletzt von Taipan ()

  • hi
    Systen/einstellungen/Plugins/skinnopactiy/Schriftart und dann ok


    Dec 6 13:09:37 scaleo-e kernel: [ 1075.421780] vdr[1107]: segfault at 46465455 ip 00007f9490772c77 sp 00007fff55b69a00 error 4 in libvdr-skinnopacity.so.1.7.32[7f949075f000+3a000]
    Dec 6 13:09:37 scaleo-e LCDd: sock_send: socket write error
    Dec 6 13:10:02 scaleo-e dbus[720]: [system] Failed to activate service 'de.tvdr.vdr': timed out
    Dec 6 13:10:27 scaleo-e dbus[720]: [system] Failed to activate service 'de.tvdr.vdr': timed out
    Dec 6 13:10:27 scaleo-e vdr-crash: vdr exit with signal SEGV . Restarting


    beim Öffnen des EPG über KEY_EPG


    Dec 6 13:18:43 scaleo-e kernel: [ 1621.698399] vdr[2716]: segfault at 2c5a1d70 ip 00007f6d86a94085 sp 00007fff40dcc4b0 error 4 in libvdr-skinnopacity.so.1.7.32[7f6d86a66000+3a000]
    Dec 6 13:18:43 scaleo-e LCDd: sock_send: socket write error
    Dec 6 13:19:09 scaleo-e dbus[720]: [system] Failed to activate service 'de.tvdr.vdr': timed out
    Dec 6 13:19:34 scaleo-e dbus[720]: [system] Failed to activate service 'de.tvdr.vdr': timed out
    Dec 6 13:19:34 scaleo-e vdr-crash: vdr exit with signal SEGV . Restarting


    mfg det

    Jeder sollte sein Leben so leben können wie er/sie es möchte, frei und
    unabhängig, in der Not anderen zur Seite stehend, nie vergessen was man
    ist, eben einfach nur Mensch sein mit allen Schwächen und Stärken
    Lieber stehend sterben als ewig gebückt leben

    Einmal editiert, zuletzt von det ()

  • Hi,
    ich habe mit der neuen Version immer Abstürze beim Öffnen von EPGsearch (über feste Taste KEY_EPG) und anschließendem Schließen durch dieTaste KEY_ESC. Damit schmiert hier 100%ig der VDR ab. Kann das jemand virifizieren?


    [EDIT]
    Allgemein kommt es sehr oft zu Abstürzen, auch beim normalen Öffnen des EPG über KEY_EPG... Aber irgendwie ist immer epgsearch beteiligt!


    Ja, habe ich schon heute morgen bestätigt: Sobald man die DetailInfo verläßt, kracht es. Hättest Du evtl ein Backtrace von den Abstürzen, damit Louis verifizieren kann, dass es sich wirklich um das gleiche Phenomen handelt?


    Gruß, Ingo

  • @all: wie schon geschrieben...ich habe genau an dieser Stelle (ersetzen der Schedules Menüs per epgsearch) sehr viel verändert. Es wäre sehr hilfreich für mich, wenn ihr von den backtraces von den Abstürzen liefern könnten, zusätzlich bitte auch den Inhalt der epgsearchmenu.conf posten falls vorhanden.


    Vielleicht nochmal zum Verständnis, wo der Kern dieses Problems liegt: normalerweise bekommt der Skin vom VDR zur Erzeugung eines Menüs einen Tab-separierten String mit maximal sechs per Tab getrennten Werten. Im VDR existiert eine Funktion, die diesen String wieder auseinanderdröselt und dem Skin sagt, wie breit jede Spalte werden soll. Soweit, so gut...in "normalen" Menüs (die sich über den ganzen Bildschrim ziehen) gebe ich diese Werte einfach aus, habe also kein Problem, und mir kann es völlig egal sein, welche Information an welcher Stelle dieser Liste steht. In den "schmalen" Menüs dagegen (z.B. auch alle Menüs unterhalb von der Programmansicht) platziere ich diese Elemente aber mehr oder weniger frei auf den dargestellten Menüelementen. Dazu muss ich aber genau wissen, an welcher Stelle in diesem Tabseparierten String welche Information steht (Sendername zur Darstellung des Logos, Zeiten, Titel, Untertitel, ...), damit ich diese Infos auch an die passende Stelle zeichnen kann.


    Und genau hier kommt die Komplexität von epgsearch ins Spiel. Ich habe einige Varianten (Originales VDR Schedules Menü, durch EPGSearch ersetzt ohne epgsearchmenu.conf, durch EPGSearch ersetzt mit Einträgen in der epgsearchmenu.conf), und die Einträge in der epgsearchmenu.conf für die einzelnen Kategorien sind auch noch mehr oder weniger frei (bzw. auf die 17 festgelegten Tokens beschränkt). Deshalb muss ich auch noch genau wissen, in welchem Untermenü von der Programmübersicht man sich befindet (davon gibt es wiederum 7 Stück), da ja über die Einträge in der epgsearchmenu.conf die Elemente aller diese Untermenüs beliebig gefüllt werden können.


    Dummerweise habe ich keine Möglichkeit einfach herauszufinden, in welchem Untermenü man sich gerade befindet, da das weder im VDR noch im epgsearch Plugin vorgesehen ist. Ich könnte zwar das epgsearch Plugin dahingehend patchen, aber das will ja auch keiner. Ich muss also anhand der Informationen, die ich habe (insbesondere was im Titel der aktuellen Menüseite steht) auf das Untermenü schließen, das ist auch eine relativ "wacklige" angelegenheit.


    Mein Ansatz ist es nun, diese ganzen möglichen Varianten abzudecken, indem ich die gesamte epgsearch Konfig beim Starten des Skins in ein fettes Array packe und anhand der Infos in diesem Array und der Info, in welchem Untermenü ich mich befinde, richtig zu "raten", welche Info nun an welcher Stelle der Tab-Separierten Liste steht.


    Das ganze wurde insgesamt recht komplex...in dem Commit dazu sind ca. 500 Zeilen neuer Code. Ich möchte mich hier nicht für die Abstürze rechtfertigen, ich möchte nur ein bisschen Verständnis dafür erzeugen...eigentlich versuche ich es zu vermeiden, Microsoft-like die User als Betatester zu missbrauchen. Aber anscheinend exisiteren in den verschiedenen Distries und Installationen da so viele Unterschiede, dass wir da jetzt durch müssen :)


    Ciao Louis

  • Warum machst du dir so einen riesigen Aufwand? epgsearch funktioniert doch auch mit den "Original-Skins" vom VDR und dort wird definitiv nicht speziell auf dessen Menüaufbau Rücksicht genommen.


    Wie so oft gilt wohl auch hier: Weniger ist mehr. Und nur für etwas "bling bling" für epgsearch (welches möglicherweise noch nichtmal jeder verwendet) finde ich 500 Zeilen doch arg viel.

  • Wie so oft gilt wohl auch hier: Weniger ist mehr. Und nur für etwas "bling bling" für epgsearch (welches möglicherweise noch nichtmal jeder verwendet) finde ich 500 Zeilen doch arg viel.


    Warum machen wir denn ueberhaupt Plugins, der native VDR ist doch auch ganz prima :)
    Ohne die Wiederholungen am Ende des EPG Textes fehlt mir z.B. ein sehr wichtiges Feature ...

  • Aber warum brauchst du für das Feature spezielle Unterstützung im Skin? Soll heißen dieses Feature funktioniert nicht, wenn der Skin gewechselt wird? Mein Verständnis war, dass epgsearch für seinen Feature-Umfang kein speziell angepasstes Skin benötigt.

  • Warum machst du dir so einen riesigen Aufwand? epgsearch funktioniert doch auch mit den "Original-Skins" vom VDR und dort wird definitiv nicht speziell auf dessen Menüaufbau Rücksicht genommen.


    Wie so oft gilt wohl auch hier: Weniger ist mehr. Und nur für etwas "bling bling" für epgsearch (welches möglicherweise noch nichtmal jeder verwendet) finde ich 500 Zeilen doch arg viel.


    Les mein Posting nochmal in Ruhe durch, du hast es anscheinend nicht verstanden. Ich baue das Menü nun mal anders auf, und das will ich auch so beibehalten...warum es in den "Original-Skins" problemlos funktioniert habe ich ausführlich versucht zu erklären.


    Ciao Louis

  • Die Frage ist, ob es nicht sinnvoller wäre wenn du da Klaus ne API Änderung vorschlägst?


    ---
    enum eMenuCategory { mcUndefined = -1, mcUnknown = 0, mcMain, mcSchedule, mcChannel, mcTimer, mcRecording, mcPlugin, mcSetup, mcCommand, mcEvent, mcText, mcFolder, mcCam };
    ---
    Evtl. fehlt hier einfach nen mcUserDefined und ne weitere Funktion mit der ein Plugin was eigenes (das du dann explizit abfragen kannst) definieren kann? Wäre zwar auch ne epgsearch Änderung notwendig, aber die wäre dann nicht speziell für dich, sondern generell gültig.


    cu

  • Ich blicke zwar immer noch nicht 100%ig durch, was du vorhast, bzw. warum eine einfache schlanke Lösung nicht geht, aber ich verstehe zumindest im groben dein Problem.


    Was du wissen müsstest, wäre, in welchem Menü du dich befindest?


    http://projects.vdr-developer.…git/commit/?id=vdr-1.7.28

    Zitat


    Skins can now inquire the menu category for which their cSkinDisplayMenu is currently being used. This can be done either through a call to cSkinDisplayMenu::MenuCategory() or by reimplementing cSkinDisplayMenu:: SetMenuCategory(). This information allows a skin to use special icons or decorations for the various types of menus in VDR.


    http://projects.vdr-developer.…kins.h?id=vdr-1.7.28#n112

    Zitat


    ///< Sets the current menu category. This allows skins to handle known
    ///< types of menus in different ways, for instance by displaying icons
    ///< or special decorations.


    Problem dabei:


    http://projects.vdr-developer.…skins.h?id=vdr-1.7.28#n75


    Klaus hat leider nicht an Plugins gedacht... ;( Diese kleine Liste von Nummern erfasst nur das, was der VDR mitbringt. Klar könnte man eigene Zahlen "erfinden", aber dann sind Kollisionen mit anderen Plugins vorprogrammiert. Um das auf Plugins auszudehnen wäre hier ein String statt eine Zahl sinnvoller. So könnte der Plugin-Autor für seine speziellen Menüs den Plugin-Namen als Präfix voranstellen und Kollisionen sind ausgeschlossen... Sollte man wohl mal Klaus befragen, was hier machbar wäre.

  • Keine_Ahnung: jo, das würde das Problem, die jeweilige Kategorie herauszufinden, entschärfen.


    @Mreimer: ja genau das ist einer der Aspekte. Leider lässt sich hierüber nur herausfinden, in welchem "Hauptmenüpunkt" man sich gearde befindet. Ob man sich im Schedules Menü gerade im "What's on now" oder "What's on next" oder sonstwo befindet, sieht man daran leider nicht.


    Ich habe auch schon daran gedacht, das ganze Übel an der Wurzel zu packen...aber ich befürchte, wegen eines popeligen Skins, der Extrawürste gebraten bekommen will, macht sich weder Klaus noch Winnie die Mühe...


    Ciao Louis

  • Klar könnte man eigene Zahlen "erfinden", aber dann sind Kollisionen mit anderen Plugins vorprogrammiert. Um das auf Plugins auszudehnen wäre hier ein String statt eine Zahl sinnvoller. So könnte der Plugin-Autor für seine speziellen Menüs den Plugin-Namen als Präfix voranstellen und Kollisionen sind ausgeschlossen...


    Oder man nimmt GUIDs. Die wurden ja genau dafür erfunden :)


    aber ich befürchte, wegen eines popeligen Skins, der Extrawürste gebraten bekommen will, macht sich weder Klaus noch Winnie die Mühe...


    Wieso? eMenuCategory wurde doch genau dafür eingeführt. Und epgsearch macht sich doch auch die Mühe das zu nutzen. Es fehlt halt nur noch etwas bei der (ansonsten guten) Grundidee.


    Ich würde ja sogar noch weiter gehen (aber das wird Klaus vermutlich nicht gefallen) und dem Menüitem nen Speicherplatz für nen Pointer spendieren. So könnte z.B. epgsearch dem seinem Shedule Menüitems noch nen Datenstruktur mitgeben die alle Infos (ChannelID, channelname, EPG Title, EPG Shorttitle, EPG Bescheibung usw.) enthält, dann entfeällt das lästige Textparsen.


    Das Graphtft Plugin und ähnliche würden sich wohl auch drüber freuen.


    cu


  • @Mreimer: ja genau das ist einer der Aspekte. Leider lässt sich hierüber nur herausfinden, in welchem "Hauptmenüpunkt" man sich gearde befindet. Ob man sich im Schedules Menü gerade im "What's on now" oder "What's on next" oder sonstwo befindet, sieht man daran leider nicht.


    Dann gehört das gleich mitgeändert...? Jedes Menü sollte eine Art "ID" haben. Im Schedules gibt es dann halt "schedules", "schedules.now" und "schedules.next" und wenn Klaus für alles mit "schedules" ein und dasselbe Icon haben will, dann halt nur die ersten 9 Zeichen lesen. Ist dann immer "schedules". Plugins dagegen sollten am besten "plugin." + Pluginname als Präfix nutzen. Also "plugin.epgsearch.WHATEVER" als ID. So hat das Plugin einen eigenen Namensraum und Skins können auf Plugins speziell Rücksicht nehmen.

  • So...ich habe jetzt mal bei mir versucht, die Bugs zu reproduzieren...den Segfault im Setup bei Wahl der Schriftart konnte ich reproduzieren. Den von nvertigo beschriebenen reproduzierbaren Crash beim Verlassen der detaillierten EPG Anzeige und die beim Auf- und Zumachen des EPG Menüs habe ich jedoch nicht?!


    Ich habe ja den Verdacht, dass da irgendein Patch in die Suppe spuckt...ich benutze auf meinem produktiven VDR 1.7.31 mit dem G2V Extension Patch und folgender make.conf:


    Auf meiner Testkiste habe ich noch YAEPG aktiv...aber der kann es wohl nicht sein.


    Ingo (und natürlich auch gerne alle anderen :) :( welche Patches sind denn bei dir aktiv? Bei den bei mir auskommentierten fällt mir eigentlich nur der graphtft auf, der vielleicht etwas damit zu tun haben könnte. Wenn du Lust und Zeit hast, könntest du das evtl. mal checken...bis ich zum debuggen komme, dauert zeittechnisch gesehen leider noch ein bisschen...und ohne es reproduzieren zu können brauche ich einige backtraces...


    Ciao Louis

  • louis:
    vdr-1.7.32 mit


    Willst Du in Zukunft full backtraces? Ich habe heute von ca. 19:30 bis 21:00 h ein Wartungsfenster beantragt, während dessen ich testen darf... ;)


    Gruß, ingo


    EDIT: Was benutzen denn die anderen, die den Absturz beim Verlassen der detailinfo haben?

  • Hallo
    nur mal so zur Info, habe exakt das gleiche Problem wie
    nvertigo. ;(
    Vielleicht sollten wir mal einen Plain VDR versuchen ?
    Gruß
    speed


    Jain... Radio Eriwan antwortet: Einerseits wäre das zur Eingrenzung vieleicht hilfreich, andereseits gehe ich davon aus, dass der extpatch (allein schon wegen der yaepg-hack-Integration) bei den skinnopacity-Benutzern nicht unverbreitet ist...


    Ich baue gleich mal mit allen Patches, die louis im 31er drin hat.


    Frage: wer betreibt skinnopacity auf einem vanilla 1.7.32?


    Gruß, Ingo

  • Hallo,


    ich habe jetzt mal so gebaut:


    Leider ohne Erfolg. Dann habe ich YAEPG heraus genommen, weil ich ein Beobachtung gemacht habe, die mir so bisher nicht bewußt geworden war: Wenn ich mit der Info-Taste das DeitailInfo des laufenden Senders aufrufe, und dieses dann auch wieder mit der Info-Taste verlasse passiert nichts. Wenn ich aber die DetailInfo mit exit verlasse, lande ich in "Übersicht jetzt", wenn ich diese dann mit erneut exit verlassen will, dann kracht es.


    louis: Sorry, ich habe das heute morgen einfach mehrfach falsch beschrieben: es kracht NIVHT direkt bei verlassen des DetailInfo, sonder erst, wenn dann das zweite mal exit kommt. Wenn ich anstatt des zweiten exit-Taste-Drücken die Menu-Taste verwende um die Jetzt-Übersicht zu verlassen, passiert ebenfalls nichts. Also zur Reproduzierbarkeit:


    - DetailInfo aufrufen (egal ob Info-Taste aktuelles Programm, oder aus der Übersicht die beliege Info irgend einer Sendung)
    - zwei mal exit (erstes exit geht in Übersicht-Jetzt, zweites exit _sollte_ zurück zum Live-Bild)
    - Nach dem zweiten Exit-Drücken: vdr kaputt.


    Nochmal sorry für meine falsche Beschreibung von heute morgen!


    Anbei ein audführliches Backtrace. (Ohne YAEPG - macht aber auch im BT keinen Unterschied)
    Evtl. noch wichtig: ich arbeite hier auf 64bit.


    Gruß, Ingo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!