Posts by micclass

    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:

    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

    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?

    kfb77 schrieb: wrote:

    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:

    Code
    1. # netstat -i
    2. Kernel Schnittstellentabelle
    3. Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
    4. br0 1500 11325611 0 20348 0 518018 0 0 0 BMRU
    5. 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)


    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?


    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

    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:

    Code
    1. $ rpm -qa | grep -iE 'tntnet|cxxtools'
    2. cxxtools-3.0-1.fc34.x86_64
    3. cxxtools-devel-3.0-1.fc34.x86_64
    4. tntnet-3.0-3.fc34.x86_64
    5. 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.

    Quote

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

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