Beiträge von micclass

Zitat von speed

Ich gehöre zu dem Menschen die in einem Gebiet wohnen wo die Flut damals schlimme Folgen hatte.

Es gab sehr lange kein Internet, und du glaubst gar nicht wie froh wir waren das wir noch eine Sat Schüssel auf dem Dach hatten.

Ich würde mir das nochmal überlegen, so eine Schüssel mit LNB mit ein paar Kabel kosten wirklich kleines Geld.

Nur meine Meinung...

speed

Auch eine Überlegung wert. Und ja, das Thema "keine SAT Schüssel" ist nicht wegen der Kosten. Schüsseln sind einfach hässlich und die LAN Verkabelung im neuen Haus ist auch nur rudimentär vorhanden (zumindest vom Dach her), so daß eher der Aufwand und das vermeiden von Löchern im Haus das Thema sind ...

Zitat von jsffm

Für die Basis-Versorgung käme auch DVB-T2 infrage.

Was für einen Encoder verwendest Du?

Dies ist der Kern des Scriptes den ich für's kodieren verwende:

ffmpeg -i "$1" -c:v libsvtav1 -crf 20 -preset 7 -c:a copy -map 0 -map -0:d -map -0:s "$2"

funktioniert ganz gut, aber braucht ordentlich CPU.

Hallo,

Seit ca. 18 Jahren benutze ich sehr zufrieden VDR. SAT Anlage mit zunächst TV-Karte im Server und nun seit langen Jahren SATIP mit OctopusNet in einem LXC Container auf meinem Hausserver. VDR selbst wird schon lange nicht mehr als Frontend verwendet. Die Frontends (PCs unter Linux, Android Tablets und der Fernseher mit FireTV Stick) haben alle Kodi. Auf das TV Life Programm und die VDR Aufzeichnungen greife ich über VNSI zu. VDR ist also reines "Backend" für's EPG und Aufnehmen. Killer-Applikationen sind bisher epgsearch und das Live Plugin für die EPG Darstellung. Life TV selbst wird auch immer unwichtiger und lässt sich auch auf allen Geräten problemlos direkt streamen. Content ist bei mir ausschließlich unverschlüsselt der öffentlich-rechtlichen Sender. Radio spielt auch keine Rolle mehr. Vom VDR aufgezeichneter Content wird, wenn ich den nicht innerhalb zwei Wochen manuell weglösche, automatisiert nach AV1 codiert und ist dann sowieso nur noch über Kodi zugänglich.

Nun werde ich demnächst umziehen und habe beschlossen im neuen Haus keine SAT Schüssel mehr zu installieren (ist ja eher 20. Jahrhundert wie Festnetztelefonie, Fax Geräte und Kabelfernsehen). Ich bekomme da in absehbarer Zeit schnelles Internet über Glasfaser also sollte das der Weg sein.

Den Content den ich bisher über SAT/VDR bekomme kann ich ja auch über die Mediatheken downloaden/streamen. Content fehlen würde also zunächst mal nicht, Allerdings fand ich bisher epgsearch ziemlich geschickt. Immer wenn ich irgendwo eine Besprechung eines Filmes gelesen habe und das für mich interessant geklungen hat, dann habe ich einfach den Titel in meine Suchliste eingetragen und mit hoher Wahrscheinlichkeit hat mir VDR dann in den nächsten 6-18 Monaten den Film aufgezeichnet. Ausserdem schaue ich alle paar Tage am PC mit dem Browser über vdr-life das EPG an und entscheide was ich den gerne aufgenommen hätte, weil ich das vielleicht anschauen wollte.

Nun suche ich nach Ideen wie ich diesen Zustand mit oder ohne VDR in der Zukunft wieder herstellen kann ohne SAT oder TV-Kabel zu haben. Ein bischen habe ich schon mit dem iptv Plugin gespielt - bisher ohne großen Erfolg - und eigentlich sollten EPG Daten ja auch irgendwie über IP ladbar sein (was allerdings nur was nützen würde wenn ich die Aufnahmen mit VDR machen kann.

Sind andere Leute hier schon vor den gleichen Überlegungen/Problemen gestanden? Was war da die Lösung?

Grüße Michael

So, nach diversen Tests habe ich nun mit den minimal notwendigen Plugins (satip, live, svdrpsend, epgsearch und vnsiserver) nur noch selten Aufnahmen mit Fehlern. Und diese liegen im Bereich 1-5 Fehler pro Aufnahme. Ich habe auch ohne epgsearch und vnsiserver getestet und das hat keinen Unterschied gemacht. Auch das gleichzeitige streamen von live TV über vnsi (in Kodi) scheint so keine Fehler mehr zu generieren.

Ich denke ich werde nun einfach mit dem gegenwärtigen Stand leben. Das Ausschalten der EPG Scans während der Aufnahmen brauchts aber auf jeden Fall!.

Was ich noch nicht verstehe sind Meldungen im Log:

Aug 15 15:38:13 satip.mchome.dom vdr[640]: [768] SDT: channel 20 NID/TID (1/1089) not found, got 1/1011

Aug 15 15:38:13 satip.mchome.dom vdr[640]: [765] SDT: channel 4 NID/TID (1/1025) not found, got 1/1039

Aug 15 15:38:13 satip.mchome.dom vdr[640]: [771] SDT: channel 19 NID/TID (1/1107) not found, got 1/1019

Die bekomme ich immer wieder. Wenn ich die TID in der Channels.conf entsprechend anpasse (obwohl die TIDs meiner Meinung nach korrekt sind) kommen die Meldungen aber immer noch (dann mit z.B. "NID/TID (1/1011) not found, got 1/1011") . Den Code in sdt.c verstehe ich aber nicht wirklich. Kann also nicht sagen ob das ein Problem darstellt.

Gruß

Michael

Naja, "unnötige Plugins" gibt es da nicht. Da wären:

satip: sonst kein Signal

epgsearch: sonst keine Aufnahmen

live: sonst kann ich den headless vdr nicht steuern

vnsiserver: so kommen die Aufnamen in's Kodi

svdrposd: wird von live gebraucht für die GUI Config

Für den realen Betrieb brauche ich diese Plugins. Was ich aber mal zum Testen tun kann (und insofern ist der Hinweis natürlich richtig und gut) Mal ohne epgsearch und vnsi probieren. Ohne Live wird's schon schwieriger ...

Ich berichte dann was es gebracht hat.

Gruß Michael

So inzwischen habe ich noch wesentlich weitergespielt ...

Der vdr (alles gleich SW Versionen) läuft nun auf einem dezidierten Rapsberry Pi 4. /video ist eine USB3 SSD. Der Pi hängt netzwerktechnisch direkt am Switch des OctopusNet. Packet drops sehen ich nun über mehrere Tage und viele VDR Aufnahmen nicht. Netzwerktechnisch scheint also alles im grünen Bereich zu sein.

Verhalten ist wie gehabt! Wir bewegen uns also definitiv im bereich VDR SW (inklusive Plugins - sehr wahrscheinlich beim satip Plugin) und dem SATIP Server im OctopusNet.

Was ich definitiv sagen kann: EPG Scans während Aufnahmen laufen auf den freien Tunern des Octopus sind böse (sprich generieren Fehler in den Aufnahmen).

Das hab ich nun mal - mir der Kneifzange - so umgangen:

Im satip plugin habe ich das ein-/ausschalten des EPG scans über svdrpsend steuerbar gemacht. Folgender patch macht das möglich:

diff -Bc vdr-plugin-satip/satip.c vdr-plugin-satip.MC/satip.c
*** vdr-plugin-satip/satip.c    2021-08-08 15:52:56.419631759 +0200
--- vdr-plugin-satip.MC/satip.c    2021-08-08 15:57:02.827899707 +0200
***************
*** 482,487 ****
--- 482,489 ----
      "    Detachs active SAT>IP servers.\n",
      "TRAC [ <mode> ]\n"
      "    Gets and/or sets used tracing mode.\n",
+     "EITS [ on/off ]\n"
+     "    switches EPG scan mode on/off\n",
      NULL
      };
    return HelpPages;
***************
*** 592,597 ****
--- 594,611 ----
          SatipConfig.SetTraceMode(strtol(optionP, NULL, 0));
       return cString::sprintf("SATIP tracing mode: 0x%04X\n", SatipConfig.GetTraceMode());
       }
+   else if (strcasecmp(commandP, "EITS") == 0) {
+      if (optionP && *optionP) {
+         if (strcasecmp(optionP, "off") == 0) {
+            SatipConfig.SetEITScan(false);
+            return cString("SATIP EITScan switched off");
+        }
+         if (strcasecmp(optionP, "on") == 0) {
+            SatipConfig.SetEITScan(true);
+            return cString("SATIP EITScan switched on");
+        }
+         }
+      }
  
    return NULL;
  }

Nun lasse ich einen cronjob alle 10 minuten laufen und wenn einen Aufnahme in der nächsten halben Stunde ansteht oder gar schon läuft schält der Job das EPG Scanning ab und ansonsten an.

Richtig wäre meiner Meinung nach aber dass der vdr selbst nicht einfach alle freien Tuner für's EIT scanning verwendet, sondern für die SATIP Tuner Gruppen pro Device bilden würde und den Scan nur startet wenn alle Tuner dieser Gruppe frei sind. Das schau ich mir mal an, aber nach dem ich am C++ nicht so unbedingt der Held bin kann das ein Weilchen dauern.

Mit diesem Setup bekomme ich nun immer fehlerfreie Aufnahmen wenn nur eine Aufnahme läuft (ich hab dem vdr alle 4 Tunder des Octopus gegeben.) Laufen mehere Aufnahmen parallel gibts aber auch wieder (allerdings nur eine sehr kleine Zahl) von Fehlern.

Zudem bekomme ich reproduzierbar Fehler wenn eine Aufnahme läuft und ich via vnsi (mit Kodi) einen Kanal tune. Macht immer genau 2 Fehler pro Kanalwechsel in Kod in der Aufnahme.

Nun bin ich also an grübeln: Ist das ein Problem des satip Servers im Octopus dass ein neues Tunen in einem Tuner den Stream der anderen Tuner beeinflusst? Wenn dem so wäre, dann wären meine Möglichkeit wohl am Ende. Ich kann den Zustand nicht vermeiden (zumindest wenn ich mehere Tuner verwenden möchte). Oder aber haben wir noch ein Problem im vdr (oder wohl eher im satip Plugin) welches dann ja irgendwie zu fixen sein müsste.

Hat den jemand hier ein setup mit einem OctopusNet (1.16) das komplett und immer fehlerfreie Aufnahemn mit vdr 2.5.6 und dem satip Plugin aus dem git repository liefert?

Gruß Micha

Zitat von wirbel

Könnte dazu passen:

https://github.com/rofafor/vdr-plugin-satip/issues/72

Does disabling frontend reuse in the setup menu have any effect on the issue?

Ich verwende schon das aktuelle SATIP Plugin aus dem github repository ( https://github.com/rofafor/vdr-plugin-satip.git ). Da sollte das schon gefixt sein.

Und "frontend resuse" habe ich such schon ausgeschaltet ..

Das Thema EPG hat mich nun auf eine Idee gebracht. Habe mal probeweise den EPG-Scan im SATIP Plugin ausgeschalten und siehe da: Nun sind 90% der Aufnahmen fehlerfrei (gegenüber 10% vorher) und die Fehlerraten der anderen Aufnahmen liegen im einstelligen Bereich (gegenüber 200 bis über 1000 vorher).

Ich denke mal dass das wohl alles kein Infrastrukturproblem (Netzwerk oder so) darstellt. Auch drei Aufnahmen parallel gehen fehlerfrei.

Allerdings brauch ich natürlich EPG ... EPG ausschalten ist also kein wirklicher Dauerzustand. Nun bin ich also wieder ratlos. Muß ich wirklich die SATIP Rohdaten debuggen (was ich bisher noch nicht wirklich gemacht habe)? Liegt das Problem möglicherweise im SATIP Plugin?

Zitat von kfb77

Wie du siehst, sobald du den Client Müll abgetrennt hast, gibt es gar keine Drops mehr.

Ethernet Karte ist bestellt. Dauert aber ein paar Tage bis die im Dorf eintrudelt ...

Zitat von kfb77

Ist das ein vollständiges Log ? Also du hast kein epg2vdr Plugin laufen ?

Nein! EPG kommt vom Sat. Werde das setup mit epgd und epg2vdr mal ausprobieren. Ist allerdings etwas tricky zum bauen ...

Zitat von kfb77 schrieb:

es nicht am SAT Empfang liegt. Hast du mal nach Input Drops auf dem Ethernet Interface geschaut ?

zu2.: Hast du "ring buffer overflows" im Syslog zu der Zeit ? Falls ja, würde ich vermuten, deine Platte kann nicht schnell genug weg schreiben.

Also "ring buffer overflows" sehe ich keine im syslog. Das /video Verzeichnis liegt auch auf einer PCIe SSD. Die müsst eigentlich bei weitem schnell genug schreiben können.

Drops auf dem Ethernet Interface sehe ich schon. Die kommen aber auch wenn kein VDR läuft:

# netstat -i 
Kernel Schnittstellentabelle
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
br0              1500 11325611      0  20348 0        518018      0      0      0 BMRU
enp5s0           1500 11667169      0    228 0       1366259      0      0

Da muß ich noch genauer verstehen was die drops verursacht. (br0 ist eine Bridge die auf enp5s0 sitzt)

Zitat von SurfaceCleanerZ

Den Neustart kannst du wahrscheinlich verhindern indem du in den VDR Einstellungen den Notausstieg deaktivierst.

Ja klar. Aber dann hängt die erste Aufnahme. Da kommen wirklich keine Daten mehr! Der Restart macht irgendwie schon Sinn. Eventuell ein SATIP Problem?

Zitat von kfb77

Was mir noch aufgefallen ist: Der Log Auszug kann nicht vollständig sein, du hast nur 2 Fehler mit verschiedenen Frame Nummern drin, es müssten aber 402 sein. Suche nochmals nach "decoding error", da gibt es noch andere Fehler wie DTS continuity error. Wenn nicht, poste mal bitte das ganze Log, dann läuft da was schief, diese Funktion ist brandn

Ja das war tatsächlich mit einem grep drinnen. Hier also der gesamte vdr log für die Aufnahme im Anhang: (dieses Mal auch in der richtige Reihenfolge ..)
vdr-20210802-0513.txt

Gruß

Michael

Inzwischen habe ich Tests mit eingebautem Markad Plugin gemacht und sehe nun etwas klarer:

Zwei Szenarien:

1. Fehler während der Aufnahme. Hier war ich zunächst über die hohen Anzahl erstaunt. Mehrere hundert Fehler. Aber der Log von Markad zeigt mir das da durchaus einige hundert Fehler innerhalb 1-2 Sekunden entstehen können (die für mich dann nur als 1 "Ruckler" wahrnehmbar sind)

Sowas scheint den Löwenanteil auszumachen. D.h. bei meinen Aufnahmen habe ich in der Regel 1-2 solche Situationen. Was ja schon mal beruhigend ist.

2. Szenario: Wenn eine zweite Aufnahme anläuft während eine andere Aufnahme läuft gibt es häufiger (aber nicht immer) ein "ERROR: video data stream broken" und damit ein Neustart des VDR was zu einer Lücke in der ersten Aufnahme führt.

Irgendwelche hinweise was sowas verursachen könnte? WIe gesagt der Content kommt immer via SATIP. Ich hab schon lange keine DVB Karten mehr.

Danke für die Tipps!

Ein dezidiertes LAN Interface hatte ich auch schon im Sinn. Muß mal 'ne Netzwerkkarte besorgen (kost ja fast nichts mehr). Eventuell probier ich auch mal den VDR auf einen Raspie4 (dann dafür deziert) zu packen. Den muß ich aber erst freiräumen ... Der VDR ist headless. Schauen tue ich mit Kodi Clients.

Markad werde ich mal einbauen. Mal sehen ob ich dann zumindest die Uhrzeiten der Fehler lokalisieren kann.

Für den TIpp mit dem Switch: Ich habe ja das LAN Interface extra deswegen direkt an den im OctopusNet eingebauten Switch gehängt. Die anderen Switche im Netzwerk sollten also (nach meiner Meinung) aussen vor sein. Das sind dann TP-LInk TL-SG116E 1.20 bzw SG108E 5.0 Typen.

LNB ausrichten: Das habe ich mit so einen SAT-Finder gemacht. Aber würde wenn der LNB nicht gut genug ausgerichtet ist nicht auch der OctopusNet gereingere SNRs und Qualitätsraten ausspuken? Ich hatte den LNB mal getauscht (war schon über 10 Jahre alt und die Verkabelung etwas "angegammelt"). Vor dem Tausch hatte mir der OctopusNet nur SNRs im Beriech 9-12dB und Qualität manchmal < 100% angezeigt. Nach dem Tausch LNB (inklusiver neuer Kabel) sehe ich, wie geschrieben SNR 13-17dB und Qualität immer 100%.

Gruß

Michael

Hallo,

nachdem ja jetzt die vdr Entwicklungsversion (gegenwärtig verwende ich 2.5.6) die Anzahl der Fehler bei einer Aufnahme trackt, und die das Live-Plugin auch so schön darstellt (Danke!) sehe ich dass die überwiegende Anzahl meiner Aufnahmen Fehler beinhaltet. Ca. 10-20% der Aufnahmen sind fehlerfrei, die anderen haben zumeist zwischen 150 und 1000 Fehler. Beim Anschauen der Aufnahmen fällt aber nichts besonderes auf. Einzelne, sehr seltene "Rucker" in den Aufnahmen hatte ich auch bisher schon hin und wieder. Deshalb gehe ich davon aus dass das "Problem" schon länger besteht.

Nun stellt sich mir also die Frage, wie gehe ich am sinnvollsten vor die Ursache zu finden und ggf. zu fixen? Wie finde ich heraus, an welchen Stellen der Aufnahmen die Fehler sind (um ggf. die Logs zu dieser Zeit anschauen zu können)?

Setup is gegenwärtig so:

VDR läuft nativ auf einem Fedora 34 Server der physikalisch direkt am Switch des Octopus.Net SATIP Empfänger hängt. Also keine anderen Switches direkt beteiligt. Das LAN Interface des Servers ist allerdings als Bridge konfiguriert (da der Server auch mein Host für VMs ist).

Das Signal kommt über SAT (OctopusNET mit SW Version 1.1.6). Signalqualität ist immer 100% mit SNRs zwischen 13 und 17db. Als Signalstärke werden ca. 68DBµV angezeigt. Das Signal kommt von der Schüssel (80cm) über einen Switch (Spaun SMS 5587UI) und 20dB Dämpfungsglieder auf den OctopusNET. LNB und SAT Kabel sind fast neu.

VDR ist Version 2.5.6 aus dem github repository.

Plugins (alles direkt aus den github repositories): Satip, streamdev-server, epgsearch, vdrmanager, live, vnsiserver, svdrposd

Alles selbst zusammengebaut.

Probiert habe ich schon folgende Dinge:

- vdr läuft in VM auf dem Server und nicht nativ. Ergebnis: Höhere Fehlerrate

- Transport TCP statt UDP vom SATIP zum Server für RTP. Ergebnis: Kein Unterschied

Was wären denn wohl Strategien den/die Fehler zu finden?

Grüße Michael

Gerade aus dem Branch gebaut. Ja, bei mir fixt das auch das Problem. Allerdings nur unter Fedora 34 und tntnet 3.0.3 getestet.

Danke!

Hallo,

bei mir scheint vdr-live mit tntnet 3.0.X (und cxxtools 3.0.X) folgendes Problem zu bereiten:

Zeitleiste: Kanalgruppe und Zeit Auswahl springen immer auf den ersten Wert (repektive "Jetzt") zurück. D.h. wenn ich eine Zeit auswähle (z.B. "Dienstag 13.7. 20:15") dann wird das für diese Zeit für die erste Kanagruppe dargestellt. Die Anzeige im Eingabefeld steht aber anschließend wieder auf "Jetzt". Wenn ich jetzt die 2, Kanagrupppe auswähle wird mit die Zeitleiste für diese Gruppe ab jetzt angezeigt (und nicht für den ursprünglich gewählten Termin). D.h. ich kann für alle Kanalgruppen nach der Ersten nur "Jetzt" anzeigen.

Das ist unter Fedora 34 welches standardmäßig tntnet 3 mitbringt:

$ rpm -qa | grep -iE 'tntnet|cxxtools'
cxxtools-3.0-1.fc34.x86_64
cxxtools-devel-3.0-1.fc34.x86_64
tntnet-3.0-3.fc34.x86_64
tntnet-devel-3.0-3.fc34.x86_64

Bisher (unter Archlinux) hatte ich mir da immer mit tntnet 2.2.1 beholfen. Das will ich aber eigentlich auf Fedora nicht machen.

Hat das schon jemand beobachtet und ggf. eventuell einen Fix für?

Ach ja: vdr 2.5.6 und vdr-live von hier: https://github.com/MarkusEh/vdr-plugin-live.git

Gruß

Michael

Also epgsearch geht bei mir (archlinux, gcc 11.1.0) auch mit obigem Patch noch nicht:

CC conflictcheck.o

In Datei, eingebunden von /usr/include/c++/11.1.0/set:60,

von conflictcheck.h:30,

von conflictcheck.c:26:

/usr/include/c++/11.1.0/bits/stl_tree.h: In Instanziierung von »static const _Key& std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_S_key(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Const_Link_type) [with _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheckTimerObj*>; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Const_Link_type = const std::_Rb_tree_node<cConflictCheckTimerObj*>*]«:

/usr/include/c++/11.1.0/bits/stl_tree.h:2069:47: erfordert durch »std::pair<std::_Rb_tree_node_base*, std::_Rb_tree_node_base*> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_get_insert_unique_pos(const key_type&) [with _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheckTimerObj*>; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::key_type = cConflictCheckTimerObj*]«

/usr/include/c++/11.1.0/bits/stl_tree.h:2122:4: erfordert durch »std::pair<std::_Rb_tree_iterator<_Val>, bool> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert_unique(_Arg&&) [with _Arg = cConflictCheckTimerObj* const&; _Key = cConflictCheckTimerObj*; _Val = cConflictCheckTimerObj*; _KeyOfValue = std::_Identity<cConflictCheckTimerObj*>; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>]«

/usr/include/c++/11.1.0/bits/stl_set.h:512:25: erfordert durch »std::pair<typename std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const value_type&) [with _Key = cConflictCheckTimerObj*; _Compare = TimerObjSort; _Alloc = std::allocator<cConflictCheckTimerObj*>; typename std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::other>::const_iterator = std::_Rb_tree<cConflictCheckTimerObj*, cConflictCheckTimerObj*, std::_Identity<cConflictCheckTimerObj*>, TimerObjSort, std::allocator<cConflictCheckTimerObj*> >::const_iterator; typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key>::other = std::allocator<cConflictCheckTimerObj*>; typename __gnu_cxx::__alloc_traits<_Allocator>::rebind<_Key> = __gnu_cxx::__alloc_traits<std::allocator<cConflictCheckTimerObj*>, cConflictCheckTimerObj*>::rebind<cConflictCheckTimerObj*>; typename _Allocator::value_type = cConflictCheckTimerObj*; std::set<_Key, _Compare, _Alloc>::value_type = cConflictCheckTimerObj*]«

conflictcheck.c:280:47: von hier erfordert

/usr/include/c++/11.1.0/bits/stl_tree.h:770:15: Fehler: statische Erklärung gescheitert: comparison object must be invocable as const

770 | is_invocable_v<const _Compare&, const _Key&, const _Key&>,

| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/c++/11.1.0/bits/stl_tree.h:770:15: Anmerkung: »std::is_invocable_v<const TimerObjSort&, cConflictCheckTimerObj* const&, cConflictCheckTimerObj* const&>« wird zu »false« ausgewertet

make[1]: *** [Makefile:197: conflictcheck.o] Fehler 1

Gerade probiert. Auf einem System mit gcc 11.1.0 compiliert das dann: (archlinux)

Linux vdr02 5.12.5-arch1-1 #1 SMP PREEMPT Wed, 19 May 2021 10:32:40 +0000 x86_64 GNU/Linux

gcc --version: gcc (GCC) 11.1.0

Für die nicht persistenten Playbackpositionen habe ich eben im Kodi Repository folgenden commit gefunden:

https://github.com/xbmc/xbmc/pull/19450

Sieht also nach einer Rrgression in Kodi selbst (und nicht im vnsi Plugin) aus.

Ich bau das mal mit dem Patch zusammen und berichte dann ob das das Problem löst.

Gruß

Michael

Nachtrag: Hab gerade mal ein Kodi mit dem Patch für mein Desktop System gebaut. (X86_64, Fedora 33) und kann bestätigen dass der Patch nun dazu führt, dass wie bei Kodi 18 die Playposition der VDR Aufnahmen auch über einen Kodi restart erhalten bleibt.

Zitat

Eine Kleinigkeit, die mir aufgefallen ist: Sicher, dass strlen von language gut geht, wenn language ein nullptr ist? Ich würde eher language && *language schreibe.

C-technisch sicher richtig. Allerdings scheine ich mich mißverständlich ausgedrückt zu haben. Ist wohl kein NULL Pointer, sondern ein Zeiger auf einen leeren String den ich mit "const char* language = resp->extract_String();" zurückbekomme. Der Workaraund verhindert bei mir zuverlässig den crash.

Aber ich sehe das eh nicht als Lösung an. Die Frage ist warum kommt überhaupt in cVNSIDemux::StreamChange der zweite Aufrunf mit codecID PVR_CODEC_TYPE_SUBTITLE und den fehlenden Werten für lanuage, composition_id und ancillary_id. Und das verstehe ich noch nicht.

Ach ja, und dieser Art des crashes taucht bei mir auch nur auf dem System mit Kodi unter Fedora 33 (x86_64 - AMD Ryzen X3700, 64GB) auf und nicht unter Android oder in einer VM mit Archlinux ...