[ANNOUNCE] VDR developer version 2.3.1

amair · 21. September 2015

Hi seahawk1986,

Zitat von 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

UFO · 21. September 2015

Zitat von kls

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:

Code

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

kls · 21. September 2015

Zitat von UFO

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

mini73 · 30. September 2015

~~Wie ersetze ich denn:~~

Code

Channels.Count()

~~um die Anzahl der vorhandenen Kanäle zu bekommen?~~

~~Durch alle durchiterieren und mitzählen ist ja sicherlich nicht gewollt, oder?~~

Lars.

mini73 · 30. September 2015

~~Ich vermisse auch den Zugriff über den Index:~~

Code

const cChannel *c = Channels.Get(index);

Lars.

mini73 · 30. September 2015

Vergiss es, ich hab's verstanden, ich Dummerchen...

Lars.

mini73 · 30. September 2015

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.

mini73 · 30. September 2015

Den cPUTEHandler hab ich natürlich auch genutzt.
Der ist nun nach svdrp.c gewandert...

Lars.

mini73 · 30. September 2015

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.

hannemann · 3. Oktober 2015

Sooo... Restfulapi ist auch fertig.

LordJaxom · 4. Oktober 2015

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?!?!?!?

Moorviper · 4. Oktober 2015

seine letzten commits bei robotv und xvdr waren im juli

kls · 4. Oktober 2015

Zitat von LordJaxom

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

kls · 5. Oktober 2015

Zitat von mini73

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

mini73 · 6. Oktober 2015

Ok.

Lars.

LordJaxom · 6. Oktober 2015

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 · 9. Oktober 2015

Zitat von LordJaxom

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

horchi · 14. Oktober 2015

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

CKone · 14. Oktober 2015

Zitat von Copperhead

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

horchi · 15. Oktober 2015

falls es noch jemand brauchen kann
... to be tested

Grüße
Jörg

[ANNOUNCE] VDR developer version 2.3.1

Jetzt mitmachen!

Teilen