[ANNOUNCE] VDR Version 2.7.1 freigegeben

Eine Frage noch an kls: Ich werde aus der Beschreibung der Funktion cControl::Control nicht klug.

Quote

Fixed a possible crash in case replay is started and stopped in rapid sequence, by

adding missing locking to cControl::Control(). The caller of this function must now

provide a cMutexLock which stays alive as long as the result of this call is used.

The old version of this function is still there for backwards compatibility with

plugins, because this problem appears to occur only under very rare circumstances.

Authors of plugins that use this function should switch to the new version, because

the old one is deprecated and will be removed in a future version.

The version numbers (both VDRVERSNUM and APIVERSNUM) have been bumped to 2.4.2, so

that plugins can detect the presence of the new cControl::Control().

Display More

Normalerweise schützt man eine kritische Ressource, die exklusiven Zugriff benötigt, wie etwa einen Datensatz während des Lesens oder Schreibens, mit einem Mutex. Das macht aber doch nur Sinn, wenn der Mutex im VDR global und für alle Zugriffe derselbe ist.

Die Funktion cControl::Control nutzt aber lokale Mutexe, in jedem Plugin entweder einen globalen oder einen lokalen in jeder aufrufenden Funktion.

Wenn ich die History ober richtig verstanden habe, dienen die Mutexe aber eher so etwas wie der "Entprellung"? Fragen über Fragen...

Danke für ein paar klärende Worte

Stefan

Quote from kls

Der Mutex ist ja auch für alle global und derselbe, nämlich "static cMutex cControl::mutex".

Beim Aufruf von cControl::Control() wird lediglich ein cMutexLock mitgegeben, über das cControl seinen Mutex lockt:

OK, dann habe ich die lokalen Mutexe ja offensichtlich völlig unnötigerweise erzeugt, weil diese gar nicht verwendet werden. War gestern wohl schon zu spät bzw. zu lange vor dem Rechner, schätze ich.

Quote from kls

Der Aufrufer sorgt durch passende Lebensdauer des cMutexLock dafür, dass der Lock so lange bestehen bleibt, wie das Ergebnis von cControl::Control() benutzt wird.

Ich habe die Patches weiter oben entsprechend aktualisiert und dabei auch gleich die Prüfung der API-Version ergänzt.

Schaut bitte nochmal drüber, ob sich da nicht doch noch der Fehlerteufel eingeschlichen hat…

Danke & Grüße

Stefan

vdr-plugin-xmltv2vdr habe ich für vdr 2.7.1 angepasst...

Quote from shofmann

Ich habe die Patches weiter oben entsprechend aktualisiert

So ganz glücklich bin ich mit dem Patch oben für epgsearch nocht nicht. Wie seahawk vorgeschlagen hat, sollte in switchtimer.c auch mit der startTime gesucht werden, aber besser so wie im alten GetEvent() erst mit der StartTime, da man ansonsten ja das Verhalten ändert:

in switchtimer.c ab Zeile 127:
         if (!Schedules) return NULL;
         const cSchedule *Schedule = Schedules->GetSchedule(channelID);
         if (Schedule) {
+#if APIVERSNUM > 20501
+            if (startTime > 0)
+                event = Schedule->GetEventByTime(startTime);
+            else
+                event = Schedule->GetEventById(eventID);
+#else
             event = Schedule->GetEvent(eventID, startTime);
+#endif
             if (!event)
                 event = Schedule->GetEventAround(startTime);
         }

Kaum ist man im Urlaub, schon gibt es eine neue VDR-Version mit Handlungsbedarf .

Ich passe die git's "meiner" Plugins dann danach, ab Anfang Oktober, an.

Grüße

kamel5

Quote from FireFly

Wie seahawk vorgeschlagen hat, sollte in switchtimer.c auch mit der startTime gesucht werden, aber besser so wie im alten GetEvent() erst mit der StartTime

Habe ich geändert und den alten Patch entsprechend ersetzt.

Läuft auf meinem Testsystem. Danke an kls und SHofmann für die Anpassungen.

Quote from kls

M-Reimer Weil du bzgl. APIVERSION == VDRVERSION mit "Sad" gestimmt hast: die Mechanismen bleiben ja alle erhalten, du kannst also jederzeit (auf eigene Gefahr) die APIVERSION wieder zurücksetzen, falls sich tatsächlich nichts am API geändert hat ;-).

Das bringt mir exakt gar nichts denn ich kann nicht selbst bewerten ob sich was an der API geändert hat. Bisschen schade das die immer gleiche Diskussion immer wieder gebracht wird obwohl die "alten Hasen" mittlerweile echt wissen müssten wie das mit der APIVERSION funktioniert. Ich hätte mich auf die Diskussion gar nicht mehr eingelassen und nur noch einen alten Thread verlinkt wo das Thema schon durchgekaut wurde.

Ich stimme aber zu das man die längst hätte stark von der VDR-Version abweichen lassen sollen. Dann wäre die Diskussion auch um gewesen. Hätte man z.B. einfach einstellig machen können und dann hochzählen. Immer wenn sich was an der API ändert eins draufaddieren. Die könnte dann von einem Versionsschritt zum nächsten auch z.B. um 2 oder 3 hochgezählt worden sein weil zwischendurch schon Änderungen ohne Version auf GIT gelandet sind die auch inkompatible Änderungen reinbringen. Die API hat mit der Version halt eigentlich gar nichts zu tun und muss sich weder an dieser orientieren noch vom Layout so aussehen.

M-Reimer ,

Klaus hat diesen Vorschlag abgelehnt, und dafür 5 likes bekommen, unter anderem einen von Dir. Siehe

Post

RE: [ANNOUNCE] VDR version 2.6.4 freigegeben

Welchen Vorteil es bringen soll, statt der an die VDRVERSION angelehnten APIVERSION eine andere laufende Nummer zu nehmen, erschließt sich mir nicht. Ich hatte vergessen, in der Freigabenotiz darauf hinzuweisen, dass Plugins nicht neu übersetzt werden müssen. Das werde ich künftig automatisieren. Vorerst lasse ich es mal so, wie es ist.

kls

February 25, 2023 at 9:39 PM

Quote from MarkusE

Klaus hat diesen Vorschlag abgelehnt, und dafür 5 likes bekommen, unter anderem einen von Dir. Siehe

Das Like galt der Tatsache das zum damaligen Zeitpunkt eine Lösung gefunden wurde wie eine API-Versionierung möglich bleibt.

Die wenigen Plugins, die ich pflege, werden bald normal weiter laufen.

Soweit ich sehe, ist 2.7.1 kein Show-Stopper, eher eine Art 'Reminder', dass man alte VDR Versionen irgendwann abwerfen muss.

ja, und wer auf den 'reminder' nicht reagiert, zumindest innerhalb

einer angemessenen frist, dessen plugin wird eliminiert

Quote from beinhart

ja, und wer auf den 'reminder' nicht reagiert, zumindest innerhalb

einer angemessenen frist, dessen plugin wird eliminiert

außer jemand anderes pflegt es weiter

Quote from seahawk1986

Soweit mit Build-Fehlern:

• cecremote

CEC Remote Plugin ist mit der Version 1.5.1 gefixt: [ANNOUNCE] CEC Remote Plugin 1.5.1

In remux.c warnt gcc-Version 14.1.0

CC remux.o
remux.c: In Elementfunktion »void cH265Parser::ParseSequenceParameterSet()«:
remux.c:1765:40: Warnung: Schreiben von 1 Byte in eine Region der Größe 0 [-Wstringop-overflow=]
 1765 |      sub_layer_profile_present_flag[i] = GetBit(); // sub_layer_profile_present_flag[i]
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
remux.c:1743:11: Anmerkung: an Offset 8 des Zielobjekts »sub_layer_profile_present_flag« der Größe 8
 1743 |   uint8_t sub_layer_profile_present_flag[8];
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
remux.c:1766:38: Warnung: Schreiben von 1 Byte in eine Region der Größe 0 [-Wstringop-overflow=]
 1766 |      sub_layer_level_present_flag[i] = GetBit();   // sub_layer_level_present_flag[i]
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
remux.c:1744:11: Anmerkung: an Offset 8 des Zielobjekts »sub_layer_level_present_flag« der Größe 8
 1744 |   uint8_t sub_layer_level_present_flag[8];
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

remux.c:1764ff

  for (int i = 0; i < sps_max_sub_layers_minus1; i++ ) {
     sub_layer_profile_present_flag[i] = GetBit(); // sub_layer_profile_present_flag[i]
     sub_layer_level_present_flag[i] = GetBit();   // sub_layer_level_present_flag[i]
     }

gcc erkennt nicht, dass sps_max_sublayers_minus1 von 0..7 geht.

remux.c:1746

--  int sps_max_sub_layers_minus1 = GetBits(3); // sps_max_sub_layers_minus1
++  int sps_max_sub_layers_minus1 = min(GetBits(3), 7U); // sps_max_sub_layers_minus1