[ANNOUNCE] VDR developer version 2.3.1

    Quote from kls


    Magst du bitte mal beliegenden Patch probieren?


    Crasht immer noch, Backtrace sieht nun so aus:


    Edit:
    Der erste Patch ist dabei auch noch drin - spielt jedoch vermutlich keine Rolle, oder?


    CU
    Oliver

    Quote from kls

    Sorry, da fehlte noch eine Zeile.
    Anbei ein neuer Versuch.


    Der erste Patch soll ruhig drin bleiben.


    Crasht immer noch:


    CU
    Oliver

    Quote from 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 :(


    Da wäre es hilfreich zu erfahren, bei welcher Aktion und unter welchen Umständen das passiert. Und ein Backtrace könnte auch nicht schaden ;-).


    Klaus


    Hier mal ein Backtrace. Und hier der Patch: https://github.com/VDR4Arch/vd…earch-vdr2.3.1compat.diff
    Ich bin mir sicher, dass ich das mit meinen Halbwissen verpfuscht habe.

    Copperhead:


    Zum konkreten Crash kann ich noch nichts sagen.
    Aber grundsätzlich ist sowas natürlich nicht schön:


    Anstatt hier das 'const' wegzucasten sollten lieber channelMin und channelMax zu 'const cChannel *' gemacht werden. Gilt auch für alle anderen entsprechenden Stellen, wie etwa


    Auch hier


    sollte der Parameter von TimerRecDevice() zu 'const cTimer *' geändert werden.


    Bei sowas hier


    sollte der Funktion OrigTimer() die Timers-Liste vom Aufrufer übergeben werden, da dieser den Lock halten sollte. Und es sollte auch überlegt werden, ob es wirkllich ein Write-Lock sein muß. Mit denen sollte man möglichst sparsam umgehen.


    DerTypecast hier

    Code
    -   cTimer *ti = Timers.First();
+   LOCK_TIMERS_WRITE;
+   cTimer *ti = (cTimer*) Timers->First();


    ist unnötig.


    Hier (und auch an anderen Stellen)


    wird Timers->SetExplicitModify() gesetzt, aber es folgt nirgendwo ein Timers->SetModified().



    Mein Rat: erstmal die ganzen Typecasts, mit denen 'const' weggecastet wird, entfernen und lieber die entsprechenden Variablen und Parameter zu 'const' machen.
    Dann genau überlegen, ob es an der ein oder anderen Stelle wirklich ein Write-Lock sein muß, oder ob nicht ein Read-Lock auch reicht. Write-Locks sollten nur gemacht werden, wenn auch wirklich etwas verändert werden soll.


    Im Backtrace wird searchtimer_thread.c:254 angegeben, aber im Diff hat sich in der Gegend anscheinend gar nichts geändert.


    Alles in Allem sollte sich vielleicht auch mal der Original-Autor dieses Plugins mit der Sache befassen, weil der vielleicht auch den besseren Überblick hat, was genau wo geschehen soll. Ich habe jetzt nur mal rein mechanisch drübergeschaut, ohne das alles im Einzelnen zu verstehen. Dafür ist der Code viel zu lang...


    Klaus

    Der Original-Autor braucht mir aber zu lange. Außerdem versuche ich daraus auch was zu lernen.


    Das ganze casten kann ich scheinbar komplett umgehen. Hätte ich mal gleich so machen sollen...
    Ich mach den neuen Patch mal fertig. Vielleicht funktioniert es ja dann schon.

    Hallo,


    der aktuelle GIT-Stand von EnigmaNG & ExtRecMenu kompilieren nun mit VDR 2.3.1. Soweit ich es testen konnte, funktionieren sie auch. Bugs bitte melden.


    @Klaus:
    cRecordings::StateChanged() und cRecordings::ChangeState() gibt's ja nun nicht mehr. Im ExtRecMenu wurde das genutzt.
    Ich bin mir nicht ganz sicher, wie man das in der neuen Version nutzen kann.


    Gruß
    Andreas

    kls
    Hast Du den letzten Backtrace Link übersehen? Passiert nach wie vor beim Löschen einer Aufnahme während der Wiedergabe.


    CU
    Oliver

    Quote from amair

    ExtRecMenu kompilieren nun mit VDR 2.3.1. Soweit ich es testen konnte, funktionieren sie auch. Bugs bitte melden.

    extrecmenu baut in der letzten Version bei mir nicht mehr gegen den VDR 2.2.0:

    Liegt das eventuell daran, dass das Argument für myRecListItem::myRecListItem auf const cRecording *Recording umgestellt wird, ohne auf die VDRVERSNUM zu prüfen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Quote from UFO

    kls
    Hast Du den letzten Backtrace Link übersehen? Passiert nach wie vor beim Löschen einer Aufnahme während der Wiedergabe.


    Hab ich gesehen, bin nur noch nicht dazu gekommen, mich ausführlicher damit zu beschäftigen.
    Ein Problem ist auch, daß es mir nich nicht gelungen ist, den Fehler hier nachzuvollziehen. Entweder ich mache da was falsch oder es ist ein Timing-Problem.
    Ich schau es mir auf alle Fälle noch an. Zur Zeit bin ich nur leider zeitlich etwas knapp, es kann also etwas dauern...


    Klaus

    Quote from amair


    cRecordings::StateChanged() und cRecordings::ChangeState() gibt's ja nun nicht mehr. Im ExtRecMenu wurde das genutzt.
    Ich bin mir nicht ganz sicher, wie man das in der neuen Version nutzen kann.



    Gilt entsprechend auch für cRecordings.
    Wenn du den cStateKey "langlebig" machst, dann bekommst du den Pointer nur dann übergeben, wenn sich was geändert hat.


    Klaus

    Quote from kls


    Hab ich gesehen, bin nur noch nicht dazu gekommen, mich ausführlicher damit zu beschäftigen.
    Ein Problem ist auch, daß es mir nich nicht gelungen ist, den Fehler hier nachzuvollziehen. Entweder ich mache da was falsch oder es ist ein Timing-Problem.
    Ich schau es mir auf alle Fälle noch an. Zur Zeit bin ich nur leider zeitlich etwas knapp, es kann also etwas dauern...


    Kein Problem. Hier noch einmal das Setup:
    - vdr 2.3.1 + vdr-2.3.1-fixcrashdelrec.diff + vdr-2.3.1-grantrecursivewritelocks-2.diff
    - dvbsddevice
    - remote 0.7
    - Classic Skin


    Laut Backtrace passiert der Crash irgendwie bei der Ausgabe im Classic Skin.


    CU
    Oliver

    An die Patch-Autoren:
    Es wäre klasse, wenn die Plugins auch weiterhin mit vdr 2.2.0 bauen. Also müssen wahrscheinlich ein paar hässliche ifdefs rein. Solange es keinen vdr 2.4 gibt, sollte vdr 2.2 noch unterstützt werden.


    Danke!


    Lars

    Ich wäre ja froh, wenn meine Patches überhaupt funktionieren würden.


    Die Fehlermeldungen von GCC sagen mir leider überhaupt nix. Mal sehen, was clang anzeigt...
    Edit: Cool. Das hilft ja wirklich.


    Edit2: Ich habe die ganze Zeit angenommen, dass es nicht kompiliert, wenn man einen Writelock braucht, aber nur einen Readlock verwendet. Wie sich heraustellt. Kann ich überall Readlocks verwenden und es kompiliert trotzdem.
    Ich mag jetzt wirklich nicht mehr. Thread Locking soll doch der Teufel holen.

    Quote from UFO

    Hier noch einmal das Setup:
    - vdr 2.3.1 + vdr-2.3.1-fixcrashdelrec.diff + vdr-2.3.1-grantrecursivewritelocks-2.diff
    - dvbsddevice
    - remote 0.7
    - Classic Skin


    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?
    Und vielleicht zur Sicherheit mal ohne 'remote' Plugin, damit wir auch das ausschließen können.
    Machst du eine Sofortaufnahme oder eine normale Timer-Aufnahme?


    Ich hab die kommende Woche ziemlich viel zu tun, daher werde ich nicht viel zum Debuggen kommen. Ich schau es mir aber näher an, sobald ich wieder mehr Zeit habe.
    Rolf Ahrenberg hat mir heute übrigens das gleiche Problem berichtet, ich weiß nur noch nicht, welche Umgebung er betreibt. Auf jeden Fall bist du mit dem Fehler nicht der Einzige.


    Klaus

    Quote from mini73

    Es wäre klasse, wenn die Plugins auch weiterhin mit vdr 2.2.0 bauen

    Ich bin ja nu noch ein Frischling was das angeht, daher die Frage:


    Um diverse ifdefs zu sparen würde ich gern Beispielsweise sowas machen:

    Code
    #if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannels& channels = *Channels;
#else
    cChannels& channels = Channels;
#endif
    const cChannel* = channels.GetByChannelID(m_channel);


    Anstatt:

    Code
    #if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannel* = Channels->GetByChannelID(m_channel);
#else
    const cChannel* = Channels.GetByChannelID(m_channel);
#endif


    Ich kann dann mit einer Referenz weiterarbeiten statt an jeder Stelle in meinem Block an denen ich etwas von den Channels will ein ifdef einzubauen nur um den Punkt gegen den Pfeil auszutauschen.
    Müffelt das für euch irgendwie komisch? Zumindest funktioniert der obere Code mit vdr-2.2.0.

    Grüße


    Hannemann

    Sehr schön. Das macht den Code dann um einiges übersichtlicher.


    Danke

    Grüße


    Hannemann

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login