[live] Weiterentwicklung v3.3.x

Falls es diese Zeile ist, werde ich heute mal nullptr anstelle von NULL versuchen.

Hallo Markus,

damit geht's. std::nullptr ist ein 1:1 Ersatz für NULL, ist aber eben ein Pointer.

diff -Nru vdr-plugin-live/pages/stream_data.ecpp vdr-plugin-live-patched/pages/stream_data.ecpp
--- vdr-plugin-live/pages/stream_data.ecpp      2024-04-25 17:16:51.740690662 +0200
+++ vdr-plugin-live-patched/pages/stream_data.ecpp      2024-04-25 17:15:24.018621670 +0200
@@ -15,7 +15,7 @@
 </%pre>
 <%session scope="global">
 bool logged_in(false);
-FFmpegThread *f_worker = NULL;
+FFmpegThread *f_worker = nullptr;
 </%session>
 <%cpp>
 if(f_worker) f_worker->Touch();
diff -Nru vdr-plugin-live/pages/stream.ecpp vdr-plugin-live-patched/pages/stream.ecpp
--- vdr-plugin-live/pages/stream.ecpp   2024-04-25 17:16:51.740690662 +0200
+++ vdr-plugin-live-patched/pages/stream.ecpp   2024-04-25 17:14:09.865992355 +0200
@@ -15,7 +15,7 @@
 </%args>
 <%session scope="global">
        bool logged_in(false);
-       FFmpegThread *f_worker = NULL;
+       FFmpegThread *f_worker = nullptr;
 </%session>
 <%request scope="global">
        cChannel* Channel;

Anm.: Für neuen code also eher nullptr anstelle von NULL verwenden.

Quote from wirbel

cxxtools, tntnet und live von heute. gcc-13.2.0

Das betrifft dann auch schon Noble Numbat, weil da GCC14 mit bei ist, korrekt?

Oder wie bist du auf den Fehler gekommen?

Nein, unter Ubuntu 24.04 gibt es kein Problem.

pkg-config --modversion tntnet
3.0

gcc --version
gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0

Damit baut der aktuelle Stand von live ohne Fehler. wirbel hat mit dem aktuellen Git Stand von cxxtools und tntnet getestet, damit habe ich auch den gleichen Fehler bekommen.

Ein Patch weniger, danke.

Funzt, danke!

Quote from rüsseltier

..weil da GCC14 mit bei ist, korrekt?

gcc-14 wird wohl nicht sehr beliebt sein, wenn ich die Details so lese.

Aber das Problem hier hat mit gcc wenig zu tun.

NULL ist auf low-level Ebene wirklich die 4-byte Ganzzahl Null '0', was man dann ein compiler allgemein als signed integer versteht. Ob das dann als 'integer', 'long (int)' oder 'long long (int)' in compiler messages auftaucht, das hängt wohl eher von der Architektur ab (x86, x86_64, aarch, aarch64, ...). Aber selbst die Anzahl bits && bytes ist Architektur abhängig. Und zum Glück gibt es ja heute keine 7-bit integer mehr.

nullptr dagegen ist ein pointer (Zeiger auf eine Speicherstelle), der per Definition auf nichts zeigt, nicht initialisiert ist (und weitere positive Eigenschaften hat..). Sehr wahrscheinlich wäre der compiler aber mit (void *) NULL ebenso zufrieden (type cast).

Kleiner Einfall:

Aktuell kann man ja in den Listen nur durch das Vorhandensein eines Bildes auf den ersten Blick erkennen, ob etwas gescraped wurde.

Reine Text-Scrapings ohne Bildmaterial sind hingegen auf den ersten Blick nicht zu erkennen.

Dem könnte man durch ein UTF-Info-Symbol in Grau nach dem Eintrag entgegen wirken. Das sollte auch nur bei "Nur-Text-Einträgen" auftauchen.

Richtig luxuriös wäre noch als alt-Text/onmouseover hinter dem ⓘ eine Anzeige mit "TVDB" oder "TMDB", je nach ID der Quelle.

Unten ein Mockup, was ich meine.

Edit: falls einfacher umsetzbar, könnte man das ⓘ-Symbol auch zentriert an der Bild-Leerstelle einblenden.

Ich versuche gerade, die Senderlogos mit anzeigen zu lassen. Wegen SkinNopacity sind sie bei mir aber alle mit Kleinbuchstaben gespeichert. Könnte man eine Logo-Datei nicht zusätzlich auch mit Kleinbuchstaben suchen, wenn sie mit Groß/Kleinschreibung nicht gefunden werden konnte?

Danke & Grüße

Stefan

Quote from MarkusE

Also, falls jemand live noch mit --tvscraperimages aufruft: Diesen Parameter bitte entfernen.

Was passiert denn dann auf VDR-Clients mit tvscraper und den Images? Werden die alle dann n-fach geholt?

Quote from MarkusE

Auch wenn ich die Frage nicht verstehe: Es ändert sich nichts. live holt sich die Information, wo die Images liegen, über das Service Interface von tvscraper bzw. scraper2vdr. Daher muss diese Information nicht mehr mit --tvscraperimages bereitgestellt werden.

Hm, evtl. hab ich das auch nur falsch im Kopf. Mein Stand ist, dass der Server die Sachen holt und ein Client auf einem Share das einfach lesen kann, ohne es erneut holen zu müssen

Quote from MarkusE

Auch auf dem Client wird tvscraper installiert. tvscraper nutzt dann die Daten des tvscraper vom Server. Dazu gibt es Parameter bei tvscraper, die wurden nicht verändert.

Du meinst

--dir ${VDR_VIDEOBASE}/tvscraper --readOnlyClient

Wenn das reicht, ok.

Danke!

Mir ist gerade aufgefallen, dass seit dem letzten Commit b7cced0 in searchNameDesc gefundene Duplikate zwar zum Aufruf von AppendAsJsArray führen, in den Events trotzdem nicht als vorhandene Aufzeichnungen gelistet werden.

Hier das Log für ein aktuelles Beispiel:

searchNameDesc: event = Free Guy, RecItems = 36 (filled)
searchNameDesc: equalName.first != equalName.second
searchNameDesc: equalDuplicates.first == equalDuplicates.second
searchNameDesc: numEqualCharsLow <= numEqualCharsUp
searchNameDesc: num_match_rec == 0
searchNameDesc: %Free Guy [true]
appendEpgItem: event = Free Guy, recItem = %Free Guy
appendEpgItemWithRecItem: event = Free Guy, recItem = %Free Guy
// hier folgt im Code:
// recItem->AppendAsJSArray(epg_item);

Hier der Fix für dieses Problem:

• Fixed missing brackets for EPG existing recording item (2).zip

Das ist nur eine schnelle Lösung für das Problem. Unschön ist, dass für die EPG-Daten, für die Aufzeichnungen und fürs Streaming jeweils ein Daten-Array generiert wird, zur Transformation in HTML aber die Array-Elemente einzeln als Positionsparameter an existingRecordingSR übergeben werden. Schöner wäre es, stattdessen nur das Array übergeben zu müssen und dessen Dekodierung der Funktion zu überlassen. Es müsste also nur noch existingRecordingSR anstelle der drei Aufrufer die Struktur des Arrays kennen. Ist aber ein bisschen zu viel Aufwand für einen schnellen Fix…

Ich bin gerade auch etwas genervt, weil ich jedes Mal mit den PO-Dateien kämpfe, die sich nach dem Kompilieren bei jedem Testlauf in den Patch einschleichen. Die darf ich dann manuell wieder herauslöschen und den Patch nochmals hochladen. Könntest du die beim Kompilieren geänderten PO-Dateien bitte nicht einfach mit einchecken? Wenn dir mal drin sind, herrscht lange Zeit Ruhe… jedenfalls ist das die Beobachtung bei anderen Plugins.

Danke & Grüße

Stefan

Wenn man in der Programmübersicht auf eine vorhandene Aufzeichnung klickt, wird ein Link ohne die (korrekte) Recording-ID erzeugt. Der Aufruf der Funktion existingRecordingSR für die vorhandene Aufzeichnung berücksichtigt nicht, dass die Daten für den Parameter imdb_id erst in Index 2 kodiert sind. Hier der neueste kumulative Fix:

• Fixed missing brackets for EPG existing recording item (3).zip

Viele Grüße

Stefan