Hi seahawk1986,
extrecmenu baut in der letzten Version bei mir nicht mehr gegen den VDR 2.2.0:
Danke für den Hinweis, hatte ich übersehen. Im aktuellen Stand behoben.
Gruß
Andreas
Hi seahawk1986,
extrecmenu baut in der letzten Version bei mir nicht mehr gegen den VDR 2.2.0:
Danke für den Hinweis, hatte ich übersehen. Im aktuellen Stand behoben.
Gruß
Andreas
Daß es am Ausgabedevice liegt kann ich mir schlecht vorstellen, denn das dvbsddevice hat mit den globalen Listen nichts zu tun.
Ich habe leider keinen VDR mit dvbsddevice mehr in Betrieb, daher kann ich es damit nicht ausprobieren.
An Skins habe ich alle drei Standardskins probiert, aber keine hat Probleme gemacht. Ich sehe aber durchaus im Code, daß es da ein Locking-Problem geben könnte. Nur ist es mir bisher noch nicht gelungen, es zu forcieren.
Kannst du bitte mal testen, ob das auch mit der LCARS-Skin auftritt?
Tritt mit allen drei Standardskins auf, bei LCARS sieht der Backtrace etwas anders aus:
Program terminated with signal 11, Segmentation fault.
#0 0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
573 const T *First(void) const { return (T *)objects; }
(gdb) bt
#0 0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
#1 0x0815afb5 in cRecordings::MBperMinute (this=0x0) at recording.c:1573
#2 0x081b9134 in cVideoDiskUsage::HasChanged (State=@0x9f52db0: 3)
at videodir.c:214
#3 0x0817b09e in cSkinLCARSDisplayMenu::DrawDisk (this=0x9f52a80)
at skinlcars.c:1087
#4 0x0817c152 in cSkinLCARSDisplayMenu::DrawFrameDisplay (this=0x9f52a80)
at skinlcars.c:1154
#5 0x0818213f in cSkinLCARSDisplayMenu::Flush (this=0x9f52a80)
at skinlcars.c:1753
#6 0x0818963b in cSkins::Flush (this=0x828bd00) at skins.c:394
#7 0x08111790 in cInterface::GetKey (this=0x95199f0, Wait=true)
at interface.c:34
#8 0x081b592c in main (argc=12, argv=0xbfcd3d64) at vdr.c:1154
(gdb)
Alles anzeigen
Zitat
Und vielleicht zur Sicherheit mal ohne 'remote' Plugin, damit wir auch das ausschließen können.
Macht keinen Unterschied. Bei obigem Backtrace war dvbsddevice das einzige Plugin.
Zitat
Machst du eine Sofortaufnahme oder eine normale Timer-Aufnahme?
Moment mal - hast Du mich evtl. falsch verstanden?
Ich mache keine neue Aufnahme, sondern ich lösche eine existierende Aufnahme, während sie wiedergegeben wird:
- Irgendeine Aufnahme "X" abspielen.
- Aufzeichnung "X" löschen, während die Wiedergabe läuft.
-> Crash, hier 100%ig reproduzierbar.
CU
Oliver
Moment mal - hast Du mich evtl. falsch verstanden?
Ich mache keine neue Aufnahme, sondern ich lösche eine existierende Aufnahme, während sie wiedergegeben wird:
- Irgendeine Aufnahme "X" abspielen.
- Aufzeichnung "X" löschen, während die Wiedergabe läuft.
-> Crash, hier 100%ig reproduzierbar.
Na gut, daß wir darüber gesprochen haben! Das hatte ich wohl tatsächlich falsch verstanden (obwohl du es freilich genau so beschrieben hattest - da hab ich wohl nicht genau genug gelesen, sorry). Wenn ich es so mache, wie du oben beschreibst, dann stürzt es bei mir auch ab.
OK, damit kann ich debuggen...
Klaus
Vergiss es, ich hab's verstanden, ich Dummerchen...
Lars.
Zitat
+ cSchedules::ClearAll() has been removed. The functionality is now implemented directly in cSVDRPServer::CmdCLRE().
Das ist etwas schade, da ich mit dbus2vdr ja ähnliche Befehle wie SVDRP zur Verfügung stelle, nur eben über einen anderen IPC-Mechanismus. Das sind jetzt nicht viele Zeilen Code, aber nun ja...
Falls ich mal Zeit habe, würde ich sonst mal versuchen, den Code der SVDRP-Befehle zu extrahieren, so dass sie leichter von Plugins wiederverwendet werden können. Spricht da was gegen? Sowas wie die Reply-Funktion müsste dann abstrahiert werden, spontan hab ich auch noch keine Idee. Bloß wenn es gar keine Chance auf Übernahme hätte, werde ich nicht zu viel Zeit investieren.
Ich werde mal sehen, ob ich in den nächsten Wochen mal ein Beispiel liefern kann.
Lars.
Den cPUTEHandler hab ich natürlich auch genutzt.
Der ist nun nach svdrp.c gewandert...
Lars.
Ok, wer will, darf dbus2vdr nun mit dem vdr 2.3.1 testen:
https://github.com/flensrocker…dbus2vdr/releases/tag/v26
Einzig epg.PutEntry funktioniert noch nicht, wegen des fehlenden cPUTEHandler.
Aber da finde ich schon noch eine Lösung...
Lars.
Sooo... Restfulapi ist auch fertig.
Weiss jemand ob Alexander Pipelka noch aktiv ist? Sonst würde ich mich morgen mal mit XVDR befassen...
kls:
Sehr, sehr schön, dass Du konkurrierende Zugriffe auf Timers, Schedules und Recordings abzusichern ermöglichst, aber warum in Gottes Namen muss ich auf StateKey Remove aufrufen und bekomme einen Abbruch, wenn ich das bis zum Destruktor von cStateKey noch nicht gemacht habe? Warum wird Remove nicht einfach im Destruktor aufgerufen? Genau dafür ist ein Destruktor doch da?!?!?!?
seine letzten commits bei robotv und xvdr waren im juli
warum in Gottes Namen muss ich auf StateKey Remove aufrufen und bekomme einen Abbruch, wenn ich das bis zum Destruktor von cStateKey noch nicht gemacht habe? Warum wird Remove nicht einfach im Destruktor aufgerufen? Genau dafür ist ein Destruktor doch da?!?!?!?
Ich meine mich zu erinnern, daß ich da auf ein Problem gestoßen bin, wenn man das erst im Destruktor macht. Kann aber auch sein, daß das in der Frühphase der Entwicklung war, wo alles noch recht provisorisch war.
Probier doch mal, ob es irgendwo hakt, wenn du statt der esyslog() und ABORT Zeilen Remove() aufrufst. Zum Testen könntest du auch mal alle "normalen" Remove()-Aufrufe auskommentieren, damit das auch gleich wirklich Stress bekommt. Falls es keine Probleme damit gibt werde ich das gerne übernehmen.
Klaus
Das ist etwas schade, da ich mit dbus2vdr ja ähnliche Befehle wie SVDRP zur Verfügung stelle, nur eben über einen anderen IPC-Mechanismus. Das sind jetzt nicht viele Zeilen Code, aber nun ja...
Da gab es ein Problem mit dem Locking, das da dann irgendwie "durchgereicht" hätte werden müssen.
Es war einfacher, die Funktionalität direkt vor Ort zu implementieren, da cSchedules::ClearAll() eh nur von cSVDRPServer::CmdCLRE() aufgerufen wurde.
Zitat
Falls ich mal Zeit habe, würde ich sonst mal versuchen, den Code der SVDRP-Befehle zu extrahieren, so dass sie leichter von Plugins wiederverwendet werden können. Spricht da was gegen? Sowas wie die Reply-Funktion müsste dann abstrahiert werden, spontan hab ich auch noch keine Idee. Bloß wenn es gar keine Chance auf Übernahme hätte, werde ich nicht zu viel Zeit investieren.
Ich werde mal sehen, ob ich in den nächsten Wochen mal ein Beispiel liefern kann.
Ungern...
Für eigene SVDRP-Befehle gibt es ja eine definierte Plugin-Schnittstelle. Und alles andere sollte das jeweilige Plugin lieber völlig eigenständig machen.
Klaus
Ok.
Lars.
Ich habe mich jetzt mal ans streamdev gewagt und teste das ganze auf einem RPI2 als Client und einem PC mit Tunern als Server. Patch folgt noch.
Ich kann nur schonmal sagen, wenn das Handling mit Timern, Recordings, Kanälen und Schedules etwas komplexer wird, kann man da durchaus etwas mehr Hirnschmalz reinstecken als "nur" die Makros an den Anfang eines Blocks zu setzen. Es braucht sich also niemand zu schämen, wenn die eigenen Anpassungsversuche nicht gleich beim ersten Mal fruchten
kls:
Sorry für meinen kurzen Ausbruch, ich habe garnicht gesehen, dass die Makros genau das machen, was ich bemängelt hatte - Löschen am Ende des Blocks. Deinen Vorschlag werde ich beizeiten trotzdem nochmal ausprobieren, da man so einen StateKey auch an ein kurzlebiges Objekt hängen kann ohne im Destruktor StateKey.Remove aufrufen zu müssen.
kls:
Sorry für meinen kurzen Ausbruch...
Kein Problem. Du hast ja prinzipiell Recht. Ich weiß leider nicht mehr, warum ich das nicht so gemacht habe. Irgendwas war da. Aber vielleicht ist das ja inzwischen hinfällig. Der Code hat sich seit den ersten Ansätzen ja doch einigermaßen verändert...
Klaus
Moin zusammen,
vdr-plugin-squeezebox
vdr-plugin-epg2vdr
vdr-plugin-seduatmo
vdr-plugin-pin
vdr-plugin-scraper2vdr (auf github, nicht auf vdr-developer.org)
sind fertig, bislang nur rudimentär in einer VM ohne Frontend getestet.
Für vdr-plugin-skindesigner hab ich ein Patch an Louis geschickt, übernimmt er sicher bald in sein git.
Grüße Jörg
Nachdem ich jetzt auch mal VDR 2.3.1 installiert habe hat sich herausgestellt, dass "es kompiliert" nicht gleich "es funktioniert" heißt. Zumindest mit dem Patch für epgsearch habe ich jetzt Segfaults
hat denn jemand anderes schon mal nach epgsearch geschaut? So weit ich weiß kommt winni da im Moment nicht zu und wäre nicht traurig wenn sich jemand der Sache annimmt - Epgsearch gehört ja wohl zu quasi jeder laufen vdr Installation...
Christian
falls es noch jemand brauchen kann
... to be tested
Grüße
Jörg
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!