Kodi 19 und pvdr-vnsi Probleme

Hallo,

schon geraume Zeit bin ich am basteln mit Kodi 19 und vdr-vnsi.

Plattform PC(x86_64) mit Fedora33, Kodi 19 aus rpmfusion. kodi-pvdr-vdr-vnsi ebenfalls (8.2.2-1). Vdr läuft auf einem Odroid C2 unter archlinux. Vdr und vnsiserver plugin selbst compiliert (das vnsiserver Plugin aus https://github.com/mdre77/vdr-plugin-vnsiserver).

Problem 1: Beim Abspielen von live TV crasht Kodi. Das kriege ich gelöst wenn ich das kodi-pvdr-vdr-vnsi von Hand baue und in InputstreamDemux.cpp alle Referencen

"props->SetLanguage(language);" auskommentiere. Dann klappt das abspielen von TV wieder.

Frage: Bin ich der einzige der das Problem hat? Was sollte die Sequenz "props->SetLanguage(language);" eigentlich bewirken? Wie bekommen wir das so gefixt dass ich nicht immer eine lokale gepatchte Version benötige?

Problem 2: Die Abspielpositionen der Aufnamen aus dem Vdr gehen beim Neustart von Kodi verloren. Solange die Kodi Instanz läuft ist alles gut (wenn ich ein video starte werde ich gefragt, ob ich an der letzten Abspielposition weitermachen will). Nach dem Kodi frisch gestartet ist, ist diese Information nicht mehr vorhanden und die Videos werden von Anfang an abgespielt. Für Videos die nicht über das pvr plugin kommen klappt aber alles!

Frage: Wo wird das gespeichert? Wo könnte ich suchen? Der Kodi Source-Code ist ja dann noch schon etwas ausladender ...

Grüße

Michael

"Kodi nur Leserechte" ... wie würde das funktionieren? Kodi redet ja über vnsi mit vdr. Dann müsste doch der vdr user (auf dem Server) der Relevante sein. Der passt. Der Benutzer is Owner von /video und allem was darunter liegt. Als vdr user kann ich ohne Problem auf dem vdr Server file anlegen/ändern/löschen.

Wird der State in Kodi (also auf dem Client) oder beim vdr Server verwaltet/gespeichert?

Gruß Michael

Nachtrag: Habe gerade mal das Plugin "vdr-recordings" ausprobiert. Damit klappt die Speicherung der Position der Aufzeichnungen. Leider ist das für mich kein Weg, das ja der vdr auf einem anderen Server (Odroid-C - also ARM64 - unter ArchLinux) läuft als die Clients. Mal Fedora PC - da würde das noch gehen, da lässt sich das Video Verzeichnis über NFS mounten - aber auch Tablets und Android 9/10 und da wird das dann schon schwieriger. Die Aufnahmen abzuspielen klappt ja aber eigentlich auch ganz gut mit dem vnsi plugin. ... nur halt - nicht mehr - die dauerhafte Speicherung der Abspielposition.

Btw. wie funktioinert die Speicherung der Postion denn hier? Ist das auf der Kodi Seite (meinte ich fast, da in der Vergangenheit die Abspielpositionen pro Client unterschiedlich waren) oder am vdr selbst? Wenn auf der Kodi Seite im vnsi Plugin oder im Core?

Gruß

Michael

Nochmal zum Punkt "Die Abspielpositionen der Aufnamen aus dem Vdr (via vnsi) gehen beim Neustart von Kodi verloren"

Hier habe ich inzwischen weitere Tests gemacht.

Ergebnis das Problem taucht NUR mit kodi 19 auf. Dort habe ich unter Fedora 33, Archlinux und Android 9 getestet. (immer gegen den gleichen vdr und mit dem kodi-pvr-vdr-vnsi plugin 8.2.2)

Wenn ich ein Kodi 18 benutze (unter Ubuntu getestet und wieder gegen den selben vdr. Plugin ist dann Version 3.64) dann werden die Abspielpositionen auch über einen Restart von Kodi hinaus gespeichert. Also alles o.k.

Scheint also auf der Kod / vnsi-plugin Seite zu sein und ein spezifisches Kodi 19 Thema.

Bin ich der einzige bei dem das so ist?

Gruß

Michael

.. und noch ein Nachtrag:

Für das erste Problem "Beim Abspielen von live TV crasht Kodi. " hab ich auch noch einen weniger invasiven Workaround gefunden.

*** orig/src/InputstreamDemux.cpp    2021-03-12 10:31:50.900559154 +0100
--- patched/src/InputstreamDemux.cpp    2021-03-12 10:29:51.079178189 +0100
***************
*** 387,394 ****
        const char* language = resp->extract_String();
        uint32_t composition_id(resp->extract_U32());
        uint32_t ancillary_id(resp->extract_U32());
!       props.SetLanguage(language);
!       props.SetSubtitleInfo((composition_id & 0xffff) | ((ancillary_id & 0xffff) << 16));
      }
      else if (codecId.GetCodecType() == PVR_CODEC_TYPE_RDS)
      {
--- 387,396 ----
        const char* language = resp->extract_String();
        uint32_t composition_id(resp->extract_U32());
        uint32_t ancillary_id(resp->extract_U32());
!       if (strlen(language)) {
!         props.SetLanguage(language);
!         props.SetSubtitleInfo((composition_id & 0xffff) | ((ancillary_id & 0xffff) << 16));
!       }
      }
      else if (codecId.GetCodecType() == PVR_CODEC_TYPE_RDS)
      {

Hintergrund: Ich bekomme für die Subtitles "codecId.GetCodecType() == PVR_CODEC_TYPE_SUBTITLE" nach dem validen Wert noch einen Weiteren mit composition _id and ancillary_id = 0xffff und language=NULL. Dieser Record verursacht dann beim Aufruf "props.SetLanguage(language) den Crash.

Warum dieser zweite Record kommt verstehe ich nicht. Aber der Workaround im Patch oben umgeht das temorär für mich.

Vielleicht versteht da ja jemand mehr davon und findet einen Fix und kein Workaround ...

Gruß

Michael

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 ...

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.