Hallo Zusammen,
hat jemand zufällig schon die Dateien für das Plex Plugin im Theme estuary4vdr erstellt?
Vielen DANK
Hallo Zusammen,
hat jemand zufällig schon die Dateien für das Plex Plugin im Theme estuary4vdr erstellt?
Vielen DANK
Hallo Thomas,
so wie es bisher aussieht ist der Stand von rpihddevice aus GIT mit dieser Firmeware c6ae1d69860c0915cca303475abc0b4efb83ad08 stabil.
Bleibt die Frage warum mit der aktuellen Firmeware der Fehler auftaucht.
VG Uli
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:
/opt/vc/bin/vcdbg reloc stats
Relocatable heap version 4 found at 0x1f000000
total space allocated is 492M, with 490M relocatable, 2.3M legacy and 0 offline
1 legacy blocks of size 2359296
small_allocs : 26
allocs : 303
alloc_fails : 0
legacy_block_fails : 0
compactions : 0
discard_compactions : 0
aggressive_compactions : 0
aggressive_compaction_waits : 0
aggressive_compaction_timeouts: 0
locks : 0
small_locks : 0
free list at 0x3c736600
468M free memory in 2 free block(s)
largest free block is 460M bytes
Display More
Nach einem erfolgreichem Restart des VDR's ohne die Fehlermeldung, dann diese Ausgabe:
/opt/vc/bin/vcdbg reloc stats
Relocatable heap version 4 found at 0x1f000000
total space allocated is 492M, with 490M relocatable, 2.3M legacy and 0 offline
1 legacy blocks of size 2359296
small_allocs : 311
allocs : 897
alloc_fails : 0
legacy_block_fails : 0
compactions : 0
discard_compactions : 0
aggressive_compactions : 0
aggressive_compaction_waits : 0
aggressive_compaction_timeouts: 0
locks : 0
small_locks : 0
free list at 0x3d756ac0
439M free memory in 59 free block(s)
largest free block is 424M bytes
Display More
VG Uli
Hi,
ich benutze ein minimales Raspbian.
Vg uli
Hallo Zusammen,
ich habe immer wieder sporadisch beim staren des VDRs folgende Fehler:
May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to create window surface: bad native window!
May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to set surface attributes: bad surface!
May 25 17:56:57 kurt vdr: [10547] rpihddevice: [EGL] failed to connect context to surface: bad match!
Ein vermutlicher Folgefehler:
May 25 17:57:15 kurt vdr: [10527] ERROR: cOsd::SetAreas returned 5 (wrong alignment)
May 25 17:57:15 kurt vdr: [10527] skindesigner: Error initiating displaychannel view - aborting
May 25 17:57:16 kurt vdr: [10605] [libfritz++/CallList.cpp:190] CallList -> read 399 entries.
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
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 Louis,
ich installier jetzt nochmal beide Plugins (skindesigner, epg2vdr) frisch. Vielleicht hilfts.
VG Uli
Hi Louis,
metrixhd.
VG Uli
Hi 3PO,
+--------------------------------------------------+
| version |
+--------------------------------------------------+
| vdr 2.2.0 epg2vdr 1.0.38-GITb553a07 (13.05.2016) |
| vdr 2.2.0 epg2vdr 1.0.38-GITb553a07 (13.05.2016) |
| epgd 1.0.61-GIT1959d6a (15.05.2016) |
+--------------------------------------------------+
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 Louis,
Das gilt sowohl für die Darstellung der Timer im Hauptmenü
epgd, epg2vdr, skindesigner aktuell aus dem GIT funktioniert die Timeransicht im Menü leider nicht
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!
QuoteWie viele timer hast du in der Tabelle (alle nicht nur die 'sichtbaren')
mysql> select count(1) from timers;
+----------+
| count(1) |
+----------+
| 101 |
+----------+
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 iNOB,
Wo läuft den die DB?
DB läuft auf dem Server mit ASRock Q2900-ITX.
Der Client ist ein RPI 2.
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
Hallo Zusammen,
es gibt auch noch mSATA SSD Erweiterungs-Platine für den Raspberry Pi
Funktioniert prima.