Beiträge von micclass

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

    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

    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

    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

    "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

    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

    Hallo,

    nochmals ein Update: Inzwischen habe ich auch das SATIP Plugin mit direkter Kommunikationm zum Octopus wieder am laufen. Der relevante Unterschied war hier ein Downgrade der Firmware Version 1.16 auf 1.15. Gibt es hier auch Erfahrungen mit Problemen bei der 1.16 Firmware version?


    DIe letzten offenen Themen sind nun nur noch dass ich relativ oft folgende Meldungen sehe:


    2020-12-04T09:29:29.692031+01:00 vdr-6d7d678f9-qtq5p vdr: [482] retrying


    D.h. der Channelwitch (für's EPG scanning - was anderes ist in dieser Zeit nicht passiert) scheint nicht auf Anhieb zu klappen und mehere Anläufe zu brauchen. Ideen dazu?


    Und dann sehe ich noch (zwar selten aber immerhin)
    2020-12-04T09:37:40.486680+01:00 vdr-6d7d678f9-qtq5p vdr: [485] SATIP: Detected 4 RTP packet errors [device 2]


    Netzwerk ist schon überprüft (unterschiedliche Switche und Kabel machten keinen Unterschied).


    Wenn ich das nun noch geläst bekomme, räume ich mal auf und mache das ganze öffentlich zugänglich.


    Gruß

    Michael

    Mal ein kleines Update:


    Also der VDR an sich läuft inzwischen prima im Kubernetes Cluster auf den Raspies. Das beschrieben Problem mit den capabilities habe ich durch "rauspatchen" für mich hier umgangen (gelöst würde ich nicht schreiben wollen).


    Also einfach so:


    Die einzige Baustelle mit der ich noch kämpfe ist SATIP. Ich benutze einen Octopus 4-Kanal SATIP Receiver mit aktueller Firmware (1.16). Wenn ich den direkt im SATIP Plugin konfiguriere (-s 192.168.62.32|DVBS2-4|OctopusNet|) bekomme ich zwar zumeist ein SIgnal, aber nicht immer und häufig "tuning timed out" Meldungen) Spätestens nach einem Tag ist das aber für alle Tuner tot. Nur noch Fehlermeldungen. Das erholt sich auch nicht von selbst und ich muß alles mögliche machen (den Octopus, und VDR neu Starten und machmal sogar anschliessend im VDR Satip Plugin den Transport auf TCP und dann wieder auf UDP zurück stellen) um wieder ein Signal zu bekommen. So ist das Ganze unbenutzbar.


    Nun habe ich Rahmen des debuggings (sprich: "ziellosem rumprobieren" ;) ) mal ein minisatip "dazwischen" gehängt. Also der minisatip hat als Quellen die 4 Tuner des Octopus (wird also mit "minisatip -s 192.168.62.32 -s 192.168.62.32 -s 192.168.62.32 -s 192.168.62.32" gestartet.). Dabei läuft der minisatip auf einem System (Fedora 33) ausserhalb des Kubernetes clusters. Nun konfiguriere ich das SATIP Plugin im vdr mit "-s 192.168.62.10|DVBS2-4|minisatip|" Zu meiner großen Überraschung läuft das Ganze damit fast stabil (im Bereich "gut benutzbar"). Auch wenn es mal "Tuner timeouts" gibt "erholt" sich das dann wieder von selbst.


    Nun bin ich natürlich am grübeln warum die für mich fragiler aussehende Konfiguration (Traffic vom Octopus zum minisatip und dann von dort zum vdr) stabiler läuft wie der direkte weg. Irgenwelche Ideen dazu?


    Gruß Michael

    Hallo,


    ich hätt da mal ein kleines Problem:


    Bin gerade dabei mein seit jahren zuverlässig laufenden VDR (bisher x64 kvm mit OctopusNet SATIP) mal komplett mit "neumodischen Zeugs" zu machen. Ist eher ein Spiel-/Lernprojekt denn wirklich notwendig.


    Was ich bisher gemacht habe: -

    - Kubernetes Cluster auf 3 Raspi-4 (8GB) Nodes mit Ubuntu 20.04 als Host OS und microk8s (mit Kubernetes 1.19) aufgesetzt. Funktioniert soweit schon mal ganz gut für andere Dinge. Ich verwende "metallb" um die Services "nach aussen" also in mein lokales Netz zu mappen.

    - Eigenes Docker Image für vdr erzeugt (custom build aus den Repositories für vdr und den paar wenigen Plugins die ich brauche - satip, streamdev-server, epgsearch, vdrmanager, live, vnsiserver, svdrposd, dummydevice). Alles wird auf dem Raspie compiliert. Ist allerdings noch Work in Progress, weil das erzeugte Image noch etwas kleiner werden soll. Base OS im Docker-Image ist auch wieder Ubuntu 20.04.

    - helm chart geschrieben, welches das Deployment in den Kubernetes Cluster macht (hier werden das /video Verzeichnis und das config Directory für den VDR via NFS gemountet damit die Daten persistent sind.)


    Wenn alles läuft sehe ich:



    Code ist bisher noch nicht veröffentlicht, weil das ja alles noch sehr roh mit vielen lokalen Eiegenheiten durchsetzt ist.


    2. Probleme die ich bisher noch nicht lösen konnte:


    1. Wenn ich den vdr im Container als root user starte und dann mit "-u vdr" den User vdr als echten Benutzer verwenden will, dann bekomme ich beim Start:


    Code
    vdr: cap_set_proc failed: Operation not permitted
    vdr: OS does not support cap_sys_time


    Geht also erst mal nicht. Wenn ich den vdr direkt unter dem User "vdr" starte (also: "su -c /opt/vdr/bin/vdr vdr") startet der vdr.

    Allerdings bekomme ich dann Fehlermeldungen im log:

    Code
    2020-09-22T11:53:39.836187+02:00 vdr-5c8477d77f-xlm44 vdr: [57] SATIP poller thread started (pid=54, tid=57, prio=high)
    2020-09-22T11:53:39.838676+02:00 vdr-5c8477d77f-xlm44 vdr: [57] ERROR (thread.c,258): Permission denied


    Ist das kritisch? Und ist ggf. mein 2. Problem eine Folge davon? Was würde man erwarten das alles nicht geht wenn man den vdr Prozess direkt als nicht privilegierten Benutzer startet?


    2. SATIP funktioniert nur sporadisch und meldet Fehler:


    Damit ich das satip plugin überhaupt - zumindest rudimentär - zum laufen bekommen habe, habe ich folgendes gemacht:

    Code
    [satip]
    -d3
    -s 192.168.62.32|DVBS2-4|OctopusNet|
    -p 31900-31907

    D.h. der SATIP Server ist ausserhalb des Netzes des Clusters in meinem lokalen Netz! Und dann in der Service Definition für Kubernetes:

    Code
    ports:
    - port: 31900
      targetPort: 31900
      nodePort: 31900
      protocol: UDP
      name: rtp-0
    (wiederholt für ports 31901-31907 ...)

    Und das dann korrespondierend im deployment.


    D.h. der Nodeport ist der gleiche wie der Containerport. Damit werden also die UDP Ports jeweils 1:1 gemapped und sind aus meinem Netz erreichbar unter der Adresse 192.168.63.1

    Code
    kubectl get svc
    NAME         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                                                                                                                           AGE
    vdr-tcp      LoadBalancer   10.152.183.29   192.168.63.1   6419:31991/TCP,6420:31230/TCP,2004:30022/TCP,3000:30623/TCP,8008:30008/TCP,34890:31354/TCP                                        9m29s
    vdr-udp      LoadBalancer   10.152.183.16   192.168.63.1   31900:31900/UDP,31901:31901/UDP,31902:31902/UDP,31903:31903/UDP,31904:31904/UDP,31905:31905/UDP,31906:31906/UDP,31907:31907/UDP   9m29


    Wenn ich alles neu starte, dann bekomme ich auch EPG daten (z.b. ersichtlich über das Live frontend welches über http://192.168.62.1:8008 zugänglich ist, (Mein lokales netz mit dem SATIP server (ist 192.168.62.0/23 und das Netz mit calico im cluster für die services ist dann 10.152.183.0/24). kube-proxy sollte das dann mappen.


    Sollte so ein Setup denn überhaupt funktionieren? Sprich vdr mit satip Plugin im Cluster mit IPs des Clusters und dann der SATIP-Server ausserhalb des Clusters in einem anderen Subnetz. Kube-proxy macht ja da sowas wie NAT wenn ich das richtig verstehe. Hat jemand so ein Setup bereits am laufen?


    Gruß Michael

    Hallo


    Danke! Also HD-Streams (H264) laufen hier sowohl in Firefox, als auch Chrome mit ffmpeg version 4.1-static.


    Gibt's ne Chance das auch auf Aufnahmen zu erweitern? Das Streamen über VLC Plugin ist ja wohl eher Geschichte ...


    Gruß Michael

    Besten Dank!


    Hab das eben mal zusammengabut (auf einem virtuellen Fedora 25 System - benutze satip als input). Sieht soweit mal gut aus.


    Allerdings läuft das epgsearch-plugin nicht. Dort wird die Funktion "HandleRemoteModifications" aufgerufen, die in menu.c als "static" deklariert ist. D.h. die ist nicht sichtbar. Wenn ich in menu.c das "static" für HandleRemoteModifications entferne, dann funktioniert alles. Aber das war ja wohl nicht im Sinne des Erfinders ...


    Gruß

    Danke!


    Inzwischen hab ich alle für mich notwendigen Plugins am laufen und kann bestätigen, dass smarttvweb mit vdr-2.3.3 bei mir läuft.


    Gruß
    Michael

    Danke! Damit klappts (fast ;) )


    responsememblk.c:2263:18: Fehler: L-Wert »std::basic_ostream<char>« kann nicht mit »std::basic_ostream<char>&&« verbunden werden
    *(mLog->log()) << " Ownhost= " << own_host << endl;
    ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~


    Wenn das bei dir kompiliert, dann gehe ich davon aus, dass wir unterschiedliche C++-Kompiler und Linux Versionen einsetzen.


    Bei mir:
    [michaelc@satip smarttvweb]$ cc --version
    cc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)


    und
    [michaelc@satip smarttvweb]$ uname -a
    Linux satip.fritz.box 4.10.5-200.fc25.x86_64 #1 SMP Wed Mar 22 20:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    also Fedora 25 mit aktuellen Patches.


    Wenn ich die Zeile auskommentiere (ist ja wohl nur ein logfile eintrag) dann kompiliert das Plugin. Testen konnte ich es noch nicht, weil ich noch mit eniem anderen Plugin (vdrmanager) am kämpfen bin.


    Gruß Michael

    Sorry, I have to correct myself. The changes with checks on APIVERSNUM > 20300 are in . So it looks like I got the correct version.


    But still compile errors:
    g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/opt/vdr/src/vdr-2.3.3/include -c -DPLUGIN_NAME_I18N='"smarttvweb"' -o smarttvfactory.o smarttvfactory.c
    smarttvfactory.c: In Elementfunktion »cRecFolder* SmartTvServer::GetRecDb()«:
    smarttvfactory.c:959:18: Fehler: »Recordings« wurde in diesem Gültigkeitsbereich nicht definiert
    bool changed = Recordings->StateChanged(mRecState);
    ^~~~~~~~~~
    smarttvfactory.c: In Elementfunktion »void SmartTvServer::CreateRecDb()«:
    smarttvfactory.c:973:27: Fehler: »Recordings« wurde in diesem Gültigkeitsbereich nicht definiert
    cRecording *recording = Recordings.First();
    ^~~~~~~~~~
    smarttvfactory.c: In Elementfunktion »std::__cxx11::string SmartTvServer::processNestedItemList(std::__cxx11::string, cList<cNestedItem>*, std::vector<cCmd*>*)«:
    smarttvfactory.c:1153:37: Warnung: Format »%d« erwartet Argumenttyp »int«, aber Argument 4 hat Typ »std::vector<cCmd*>::size_type {aka long unsigned int}« [-Wformat=]
    (pref + itm->mTitle).c_str());
    ^
    Makefile:66: die Regel für Ziel „smarttvfactory.o“ scheiterte
    make: *** [smarttvfactory.o] Fehler 1
    [michaelc@satip smarttvweb]$
    [michaelc@satip smarttvweb]$ vi smarttvfactory.
    [michaelc@satip smarttvweb]$ vi smarttvfactory.c
    [michaelc@satip smarttvweb]$ make
    g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/opt/vdr/src/vdr-2.3.3/include -c -DPLUGIN_NAME_I18N='"smarttvweb"' -o smarttvfactory.o smarttvfactory.c
    smarttvfactory.c: In Elementfunktion »cRecFolder* SmartTvServer::GetRecDb()«:
    smarttvfactory.c:959:18: Fehler: »Recordings« wurde in diesem Gültigkeitsbereich nicht definiert
    bool changed = Recordings.StateChanged(mRecState);
    ^~~~~~~~~~
    smarttvfactory.c: In Elementfunktion »void SmartTvServer::CreateRecDb()«:
    smarttvfactory.c:973:27: Fehler: »Recordings« wurde in diesem Gültigkeitsbereich nicht definiert
    cRecording *recording = Recordings.First();
    ^~~~~~~~~~
    smarttvfactory.c: In Elementfunktion »std::__cxx11::string SmartTvServer::processNestedItemList(std::__cxx11::string, cList<cNestedItem>*, std::vector<cCmd*>*)«:
    smarttvfactory.c:1153:37: Warnung: Format »%d« erwartet Argumenttyp »int«, aber Argument 4 hat Typ »std::vector<cCmd*>::size_type {aka long unsigned int}« [-Wformat=]
    (pref + itm->mTitle).c_str());
    ^
    Makefile:66: die Regel für Ziel „smarttvfactory.o“ scheiterte


    Any hints?

    Danke!


    Was ich bei der Gelegenheit noch fragen wollte: Was passiert denn in softhddevice technisch warum Composite hier ein k.o. Kriterium ist?


    Technisch scheint das ja nicht unmöglich zu sein (mplayer und andere Spieler verwenden ja auch vdpau und laufen auch unter Gnome3).


    Gruß Michael

    So, nun habe ich das mit ausgeschaltetem Composite getestet. Und ich kann bestätigen, dass dann der Ton synchron zum Bild ist.


    ... nur leider läuft unter Fedora weder gdm noch der gnome Desktop mit dem nvidia Treiber ohne Composite. Also ein klassischer Catch-22. Entweder vdr mit softhddevice oder mein normaler Desktop (den ich auf dem System benötige, weil das TV schauen mit vdr ja hier nur eine - eher kleine - Nebenaufgabe ist).


    D.h. ich werde wohl keinen vdr mehr auf dem System selbst benutzen sondern Kodi mit dem VNSI Plugin (welches ich auch auf einem Raspi II benutze der am richtigen Fernseher hängt). Hier geht alles im Fenster, als auch Fullscreen mit synchronem Ton. (Allerdings musste ich das aktuelle vnsi plugin für Kodi 15 selbst bauen. Das im rpmfusion repository geht nur mit Kodi 14).


    Danke für die Hilfe beim Problem suchen!


    Gruß Michael

    > Wenn dann immer noch die Videopuffer leer sind, dann vermute ich dein Bildschirm hat 70Hz oder sogar mehr.


    Nein, ich kann definitiv bestätigen dass der Monitor mit 60Hz läuft (zumindest sagt mir das nividia-settings so).


    > Composite und solche Spielerein sind ausgeschaltet?
    Da bin ich mir nicht ganz sicher. Auf dem Desktop läuft Gnome3. Allerdings war das schon immer der Fall. D.h. auch in dem Szenario vor dem im Ausgangspost genannten Commit, wo AV in sync läuft.


    Xorg.0.log:


    > Ansonsten fällt, in deinem Setup, auf, daß du keine Deinterlacer aktiviert hast.
    Ja, ich schau eigentlich nur 720p Material an. Und da brauch ich doch keinen deinterlacer für, oder?


    Gruß Michael

    Das scheint keinen Unterschied zu machen. Ich habe mit Werten für den AudioBuffer von 50 bis 50000 gespielt (wenn ich das aus dem code richtig lese ist 1000ms ja der Default).


    Vielleicht noch die Konfiguration von softhddevice in setup.conf:

    O.k. hier ein kompletter syslog von einer kurzen vdr session:



    Gruß

    Hello,


    I do see lots of the following messages:



    Oct 22 15:07:01 pc vdr: video: slow down video, duping frame
    Oct 22 15:07:01 pc vdr: video: decoder buffer empty, duping frame (721/684) 0 v-buf
    Oct 22 15:07:01 pc vdr: video: 24:19:20.085+1298 301 0/\ms 0+1+1 v-buf
    Oct 22 15:07:01 pc vdr: video: slow down video, duping frame
    Oct 22 15:07:01 pc vdr: video: 24:19:20.085+1282 286 0/\ms 0+1+1 v-buf
    Oct 22 15:07:01 pc vdr: video: decoder buffer empty, duping frame (723/684) 0 v-buf
    Oct 22 15:07:01 pc vdr: video: 24:19:20.085+1267 270 0/\ms 0+1+1 v-buf
    Oct 22 15:07:01 pc vdr: video: slow down video, duping frame
    Oct 22 15:07:01 pc vdr: video: 24:19:20.085+1257 380 0/\ms 4+4+1 v-buf
    Oct 22 15:07:01 pc vdr: video: slow down video, duping frame
    Oct 22 15:07:01 pc vdr: video/vdpau: missed frame (20/704)
    Oct 22 15:07:01 pc vdr: video: slow down video, duping frame
    Oct 22 15:07:01 pc vdr: video: 24:19:20.445+1270 321 0/\ms 0+3+1 v-buf


    Cheers,
    Michael