Posts by binduli

    Hallo Thomas,


    leider tritt die Sache sehr sporadisch auf, meist aber wenn zuvor Speicher intensive Sachen gemacht wurden, wie z.B. compilieren.


    Ab wann das Problem auftratt kann ich nur ungefähr sagen. Vermutlich funktionierte es mit der Version 1.0.0 noch. Kann aber auch sein das die aktuelle Firmware (b2ee39c7a6dc8a73ee7b559c7a833271eb10ca11) mit Schuld ist. Zu Zeiten von 1.0.0 hatte ich eine ältere Firmware (c6ae1d69860c0915cca303475abc0b4efb83ad08 ) drauf.


    VG Uli

    Hi Thomas,


    es passiert immer nur beim Start vom VDR. Wenn er mal läuft hatte ich das Problem noch nie.


    Hab jetzt wieder auf den Moment gewartet, wo der Fehler beim Start auftritt und dann den GPU-Speicher ausgelesen:



    Nach einem erfolgreichem Restart des VDR's ohne die Fehlermeldung, dann diese Ausgabe:



    VG Uli

    Hallo Zusammen,


    ich habe immer wieder sporadisch beim staren des VDRs folgende Fehler:


    Code
    1. May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to create window surface: bad native window!
    2. May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to set surface attributes: bad surface!
    3. May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to connect context to surface: bad match!


    Ein vermutlicher Folgefehler:


    Code
    1. May 25 17:57:15 kurt vdr: [10527] ERROR: cOsd::SetAreas returned 5 (wrong alignment)
    2. May 25 17:57:15 kurt vdr: [10527] skindesigner: Error initiating displaychannel view - aborting
    3. May 25 17:57:16 kurt vdr: [10605] [libfritz++/CallList.cpp:190] CallList -> read 399 entries.
    4. May 25 17:57:16 kurt vdr: [10527] ERROR: attempt to open OSD while it is already open - using dummy OSD!


    Es passiert nicht immer beim Starten des VDRs, sondern nur manchmal.


    Der zugeordnete GPU-Speicher beträgt 512MB.


    Die Plugins rpihddevice und skindesigner sind aktuell aus dem GIT.


    Früher hatte ich hier nie Probleme. Mir scheint als hätte es mit einer der letzten Updates des Plugins rpihddevice oder skindesigner zu tun.


    VG Uli

    Hallo Louis,

    Jedoch gibt es im epg2vdr Plugin eine Option, ob der VDR am "epgd Timerverbund" teilnehmen soll. Das muss aktiviert sein. Hast du das ggf. auf "aus"?

    genau das wars.Jetzt funktioniert das :tup


    Vielen Dank!


    Eine Frage noch:


    Das plugin tvguide funktioniert aktuell noch nicht beim Timer erstellen. Das ist wahrscheinlich noch nicht für epg2vdr angepasst?


    Oder mache ich da auch was falsch?

    Vg Uli

    Hi Louis,

    d.h. wenn du beide Plugins (epg2vdr und remotetimers) aktiv hast, dann funktioniert es nicht? Hm, ich habe remotetimers nicht aktiv, ggf. ist da noch ein Bug, wenn beide Plugins aktiv sind. Geht es denn, wenn nur epg2vdr aktiv ist?

    Nein, es funktioniert NICHT wenn ich NUR epg2vdr aktive habe. Mit remotetimers aktiv, funktioniert es tadellos.


    Muss ich noch irgendwas im Plugin epg2vdr einstellen außer "Timerübersicht ersetzen"?


    VG Uli

    Hallo Louis,


    mal eine Frage, ist remotetimers trotz epg2vdr nötig?


    Wenn ich remotetimers aus den Plugins entferne funktioniert die Übersicht über die letzten Timer im Menü nicht mehr.


    Sobald das Plugin wieder aktiviere, ist alles wieder in Ordnung.


    VG Uli

    Hi 3PO,


    Code
    1. +--------------------------------------------------+
    2. | version |
    3. +--------------------------------------------------+
    4. | vdr 2.2.0 epg2vdr 1.0.38-GITb553a07 (13.05.2016) |
    5. | vdr 2.2.0 epg2vdr 1.0.38-GITb553a07 (13.05.2016) |
    6. | epgd 1.0.61-GIT1959d6a (15.05.2016) |
    7. +--------------------------------------------------+


    VG Uli

    Hallo Louis,


    gerade nochmals getestet. Leider Nein.


    Die Timerübersicht kommt aus der DB. Da schaut soweit alles gut aus. Nur in der Menüansicht werden keine letzten Timer (0) angezeigt.


    Eventuell hat das auch mit der letzten Änderung von Jörg zu tun?


    VG Uli

    Hallo Jörg,

    habe den lookup der timer bzw. den Aufbau des caches etwas optimiert (sie wurden bereits für die dauer des Menüs in einem Cache gehalten) und die timer Tabelle um einen index erweitert, schau mal bitte ob es etwas gebracht hat.

    Das schaut schon mal viel besser aus. VIELEN DANK. Nicht ganz so performant wie mit remotetimers, aber definitiv besser als vorher!



    Quote

    Wie viele timer hast du in der Tabelle (alle nicht nur die 'sichtbaren')

    Code
    1. mysql> select count(1) from timers;
    2. +----------+
    3. | count(1) |
    4. +----------+
    5. | 101 |
    6. +----------+
    7. 1 row in set (0.00 sec)



    was bedeutet pro Sender, dauert es auch nach dem initialen öffnen des Menüs wenn du blätterst, sie Zeiten durch schaltest oder auf Schedule einzelner Sender gehst?

    Das initiale Öffnen dauert länger, nicht das blättern im EPG.


    Eine Sache ist mir noch aufgefallen. Wenn man bei einem Timer z.B. die Endzeit ändert und speichert, ändert sich leider nichts.


    Kannst du das nachvollziehen?


    VG Uli

    Hi Louis,

    Die Daten werden aus der DB geholt. Hier ist der lahme Netzwerkport vom Raspi wohl der Flaschenhals.

    Ich habe in diesem RPI zwar eine USB 1Gbit Karte drin. Besser als die Boardkarte, aber den vollen Durchsatz wird sie wohl nicht erreichen.


    Ich kann mir aber vorstellen, dass alle Server / Client User dieses Problem haben werden.


    Was ich mich frage ist, wieso hier die Daten aus der DB genommen werden und nicht die lokalen Daten. Die sollten ja gleich sein...


    VG Uli

    Hallo Zusammen,


    ich benutze die aktuelle Version von epgd und epg2vdr (http Version).


    Wenn ich die Programmüberischt durch die von epg2vdr ersetze, ist die Ladezeit des EPGs pro Sender extrem hoch.


    Woran liegt das?


    Werden hier die Daten direkt von der DB geholt?


    Eventuell gibt es Möglichkeiten zur Optimierung?


    VG Uli