[ANNOUNCE] VDR developer version 2.3.1

und hier:

Diese Plugins konnten nicht gebaut werden:  dvdswitch epgsearchclient radio tvscraper xmltv2vdr !

Mir ist ein neuer Crash aufgefallen , wenn das osdteletext-Plugin aktiv ist:
Verschiebt man einen Kanal über das VDR-Menü, wird bei ok auch ein SwitchTo auf die neue Kanalnummer gemacht, in derem Rahmen ein MsgChannelSwitch abgesetzt wird.
osdteletext nutzt diese Statusmeldung, um auf den neuen LiveChannel zu switchen. Dabei muss mit LOCK_CHANNELS_READ die Channels-Variable ermittelt werden. Allerdings hält zu diesem Zeitpunkt der Move noch einen Lock und Channels ist ein Nullpointer.
Ich kann jetzt nach dem LOCK_CHANNELS_READ Channels auf NULL prüfen, um den ersten Dump zu vermeiden, aber dann gibt es sofort einen ABORT:
ERROR: cStateKey::Remove() called without holding a lock
Ausser osdteletext verwendet auch das radio-plugin den SwitchChannel in ähnlicher Weise. Gibt es hier eine saubere Methode? Sollte der grantrecursivelocks von Klaus nicht für diesem Fall erweitert werden?

Ich antworte mir mal selber
da der cMenuChannels::Move einen Schreiblock auf Channels gesetzt hat, läuft der Versuch, im selben Thread einen Readlock zu bekommen auf EDEADLOCK hinaus und wird abgewiesen.
In dem Fall eines möglichen Schreiblocks kann ich das Makro LOCK_CHANNELS_READ nicht nutzen, weil das Makro immer einen Unlock macht. Ohne Änderungen im Makro oder ABORT-Verhalten brauche ich den langen Weg:
in txtrecv.c von osdeteletext statt

LOCK_CHANNELS_READ;
const cChannel* newLiveChannel = Channels->GetByNumber(ChannelNumber);

brauche ich

cStateKey channelsStateKey;
const cChannel* newLiveChannel;
if (const cChannels *Channels = cChannels::GetChannelsRead(channelsStateKey)) {
newLiveChannel = Channels->GetByNumber(ChannelNumber);
channelsStateKey.Remove();
}
else
return; // We got no Lock

Es könnte schwierig sein, in allen Plugins solche möglichen Konflikte zu finden.

Zitat von mini73

Und epgsearch. Aber da der Maintainer da momentan keine Lust hat und mir persönlich der Code zu umfangreich und komplex ist, plane ich, bis zum Ende des Jahres ein neues Plugin für Suchtimer zu schreiben. Das wird wesentlich weniger Funktionen haben und dadurch hoffentlich in Zukunft etwas wartbarer.

Ich hab da tatsächlich was geschafft... Und noch vor Ende diesen Jahres...
[Announce] epg2timer 0.0.1

Lars.

Zitat von TomJoad

Es könnte schwierig sein, in allen Plugins solche möglichen Konflikte zu finden.

Da hast du Recht. Aber genau diese Stellen waren früher immer gut für den einen oder anderen segfault bzw. race condition.

Lars.

Ok, komme jetzt erst dazu mir die release notes vom 2.3.1 anzuschauen. Da komme ich jetzt nicht drum herum erstmal diese polemische Email zu verfassen wegen

- The dvbsddevice and rcu plugins are no longer part of the VDR source archive. You can get the latest versions of these plugins from ftp://ftp.tvdr.de/vdr/Plugins.

Tscha. Ich kann es ja verstehen, aber es macht schon echt melancholisch. Die FF Karte war DIE originale Hardware fuer den VDR. Ohne sie haette es VDR nie oder nur viel spaeter gegeben. Also wahrscheinlich erst ca. nach dem grossen Finanzdebakel von 2008 statt in all den gluecklichen Vorkriegsjahren *sob*.

Ja, ok, die FF wurde schon im 2.x ein wenig stiefmuetterlich behandelt, aber sie jetzt so sang und klanglos ins Repository Altersheim abzuschieben ist schon ein wenig unwuerdig. Vor allem weil man sich bei all den API changes leicht ausrechnen kann, wann Oma's herzschrittmacher nicht mehr mit den neuen VDR Versionen mitkommt. Ein kleiner Sektempfang haette da schon sein koennen.

Ich habe immer noch eine FF produktiv im EInsatz (und eine im Schrank als HW Ersatz ;-). Ok. mehr als Backuploesung fuer die neueren Optionen, RPI und KODI, gibt aber immer noch details, die in der FF GUI vom VDR besser gehen als in den neueren Alternativen (image plugin z.b. ;-).

Vielleicht mal so als Anregung: http://www.tvdr.de/hardware.htm anpassen und vielleicht mal eine history.htm Seite basteln, wo die zeitliche Entwicklung von VDR inklusive der wichtigsten historischen Hardwarekomponenten gewuerdigt werden.

Vielen Dank fuer die intensive Arbeit.

Was evtl. sinnvoll waere, waere es eine wiki Seite zu haben fuer 2.3.1, wo man kollaborativ mal reinschreiben koennte, was mit 2.3.1 dann wirklich fuer den Benutzer besser wird, weil die Release notes ja bloss die technischen Details drinstehen, die man aber als Benutzer evtl garnicht verstehen will.

Eg: Wenn ich das so lese, dann scheint es leichter & besser zu werden, mehrere VDRs miteinander zu verbinden, eg: client-server VDR. Ich habe z.b. RPI als VDR/streamdev clients mit all den patches und plugins (wie wir das im wiki fuer 2.2 beschrieben haben), damit solche clients alle einen gemeinsamen VDR server verwenden (tuner, programmierungen, aufzeichnungen).

Fuer den Benutzer mit mehrern Clients wird die Erfahrung besser, weil man ja wohl keine Aussetzer mehr bei Menus kriegt die derzeit bei gleichzeitiger Nutzun wegen SVDRP single-instance auftauchen. Das ist super. Ist ja echt ein rattenschwanz von code der dafuer geschrievben werden musste (per-client SVDRP, locking, etc. pp). Respekt.

Fuer den Entwickler ist mir nicht so ganz klar, welche wenn nicht alle der plugins/patches fuer solche Clients jetzt im 2.3.1 standard oder unnoetig sind.

Ansonsten: 24 FPS autodetection. Super, aber so als Benutzer wuerde ich gerne mal ein Beispiel wissen, wo es denn schon 24p zu sehen gibt.

Zitat

Was evtl. sinnvoll waere, waere es eine wiki Seite zu haben fuer 2.3.1, wo man kollaborativ mal reinschreiben koennte

Leg doch eine Seite an und schreib dein Wissen rein, wir haben doch ein wiki.

klar, wenn ich denn mal zeit finde, mich mit der 2.3.1 zu beschaeftigen..

Schön wäre es, wenn es demnächst eine Version 2.3.2 geben würde, die zumindest schon mal die nötigen Änderungen drin hat, die schon gefunden wurden. Ist ja bald Weihnachten...

Lars

Zitat von te36

- The dvbsddevice and rcu plugins are no longer part of the VDR source archive. You can get the latest versions of these plugins from ftp://ftp.tvdr.de/vdr/Plugins.

Tscha. Ich kann es ja verstehen, aber es macht schon echt melancholisch. Die FF Karte war DIE originale Hardware fuer den VDR. Ohne sie haette es VDR nie oder nur viel spaeter gegeben. Also wahrscheinlich erst ca. nach dem grossen Finanzdebakel von 2008 statt in all den gluecklichen Vorkriegsjahren *sob*.

Ja, ok, die FF wurde schon im 2.x ein wenig stiefmuetterlich behandelt, aber sie jetzt so sang und klanglos ins Repository Altersheim abzuschieben ist schon ein wenig unwuerdig. Vor allem weil man sich bei all den API changes leicht ausrechnen kann, wann Oma's herzschrittmacher nicht mehr mit den neuen VDR Versionen mitkommt.

Das Plugin wird bei mir auch weiterhin immer mit übersetzt, so daß mir ein Problem mit geänderten APIs sofort auffallen würde.

Zitat

Vielleicht mal so als Anregung: http://www.tvdr.de/hardware.htm anpassen

Für die aktuelle "stable" Release 2.2.0 stimmt die Aussage ja noch ;-).

Zitat

und vielleicht mal eine history.htm Seite basteln, wo die zeitliche Entwicklung von VDR inklusive der wichtigsten historischen Hardwarekomponenten gewuerdigt werden.

Es gab mal den VDR-Zeitstrahl, aber wenn ich den jetzt aufrufe, dann sehe ich nur eine relativ leere Seite. In der Versionsgeschichte ist zwar anscheinend noch alles drin, aber man kommt irgendwie nicht rein.
Vielleicht kann sich das ja mal jemand anschauen, der sich damit auskennt...

Klaus

Zitat von mini73

Schön wäre es, wenn es demnächst eine Version 2.3.2 geben würde

Bin dran...

Klaus

Zitat

Schön wäre es, wenn es demnächst eine Version 2.3.2 geben würde

Da muss man immer an:

Zitat

Allan Bradley: "Gemessen an dem Preis, den Studenten und auch Schulen für das Produkt zahlen sollen: was für Verbesserungen wurden in Flynn ... äh, ich meine, ENCOM OS-12 gemacht?"
Richard Mackey: "Dieses Jahr steht eine zwölf auf der Schachtel."

Zitat von kls

Bin dran...

Danke!

Lars.

Zitat von TomJoad

da der cMenuChannels::Move einen Schreiblock auf Channels gesetzt hat, läuft der Versuch, im selben Thread einen Readlock zu bekommen auf EDEADLOCK hinaus und wird abgewiesen.

Da gibt es offensichtlich ein paar Stellen, an denen der Core-Code den Schreiblock auf die Liste unnötig lange hält.
Bin dabei, das zu ändern.

Klaus

Zitat von TomJoad

Es könnte schwierig sein, in allen Plugins solche möglichen Konflikte zu finden.

Versuch doch bitte mal den Fix von hier.

Klaus

Der Fix beisst sich leider mit dem vdr-2.3.1-grantrecursivewritelocks.diff von dir (thread.c ab Zeile 490), der sollte aber drin bleiben?

vdr-2.3.1-grantrecursivewritelocks.diff kann entfallen, denn das Problem waren nicht rekursive Write-Locks, sondern Read-Locks innerhalb von Write-Locks.
Rekursive Write-Locks sind sowieso zu gefährlich, weill der "innere" Lock ja etwas verändern könnte, von dem der "äussere" Lock nichts mitbekommt.

Klaus

Ohne den "grantrecursivewritelocks" hat man aber wieder den Crash von Beitrag #40

Das Problem schaue ich mir demnächst nochmal an. Verschachtelte Write-Locks kann einfach nicht die richtige Lösung sein, da muß ich wohl eher was am Ablauf ändern...

Klaus