Beiträge von wirbel

  • Compile Warnings in vnsiserver

    Es knallt immer wieder in vnsiclient.c:1148 und den Zeilen danach, kurioserweise immer wieder


    cVNSIClient::processCHANNELS_GetChannels(), dann cChannel::Name(), dann cString::sprintf(), in cString::sprintf() wird vasprintf() aufgerufen, dann schafft es vielleicht nocht die Fehlermeldung ins log, bevor der Prozess beendet wird. Das sind dann die Zeilen im for loop in


    Code
    cVNSIClient::processCHANNELS_GetChannels


    Auffällig ist auch, dass zwei threads in der gleichen Funktion cVNSIClient::processCHANNELS_GetChannels sind.

  • Compile Warnings in vnsiserver

    @warnings:


    Code
    streamer.c:57:17: warning: member ‘cLiveStreamer::m_Event’ is used uninitialized [-Wuninitialized]
57 |  , m_VideoInput(m_Event)
|                 ^~~~~~~

    Der Constructor von m_VideoInput wird mit dem lokalen class member m_Event aufgerufen,

    aber m_Event ist selbst noch nicht sicher erzeugt. Deswegen erst den m_Event constructor aufrufen und _dann_ den Constructor von m_VideoInput.

    Falsche Reihenfolge.


    g++ hat recht.





    Hier wird für jeden member von (*whitelist) eine lokale Kopie innerhalb des for loop angelegt.

    Das kostet Speicher und seeeehr viel Zeit, und hofft darauf, dass die Kopie wirklich alle Daten kopiert, etc.


    Code
    channelfilter.c: In member function ‘void cVNSIChannelFilter::StoreWhitelist(bool)’:
channelfilter.c:188:23: warning: loop variable ‘i’ creates a copy from type ‘const cVNSIProvider’ [-Wrange-loop-construct]
188 |       for (const auto i : *whitelist)
|                       ^
channelfilter.c:188:23: note: use reference type to prevent copying
188 |       for (const auto i : *whitelist)
|                       ^
|                       &




    videoinput.c:468ff


    Hier gibt es gleichzeitig mehrere Probleme.

    Zum einen wird von jedem member von sPool (seehr laaangsam) eine lokale Kopie im Geltungsbereich des for loop angelegt.

    Das alleine garantiert nicht, dass in der Zwischenzeit aber nicht der 'echte' cDummyReceiver nicht zerstört wurde -> race.

    Und zusätzlich könnte auch der shared pointer dabei sein zerstört zu werden 'expired'. Aber selbst wenn nicht, kann ja 'recv' immer noch ein NULL pointer sein.


    Eigentlich haben die gcc Entwickler wirklich gute Arbeit geleistet.

    Code rausgefischt mit Warnungen, der schwer zu lesen ist..


    Code
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:469:28:
/usr/include/c++/13/bits/atomic_base.h:505:31: warning: ‘unsigned char __atomic_load_1(const volatile void*, int)’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
505 |         return __atomic_load_n(&_M_i, int(__m));
|                ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
cc1plus: note: destination object is likely at address zero

  • [vdr-plugin-satip] "Detected invalid status code 400" mit OctopusNet

    Wunderbar!

    Ich frage mich jedesmal, welchen Lack damals die C/C++ Entwickler gesoffen haben, als sie float<->string(char*) konversationen von der lokalen Sprache abhängig machten.



    Ich würde allerdings diese Art von Stolperstellen gerne an einer zentralen Stelle in librepfunc bündeln,

    damit ich nicht immer wieder darüber stolpere.


    Ich schau mir das an und würde dich eventuell nach Tests oder Änderungen fragen.

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Eine Möglichkeit wäre


    w_scan_cpp -fc --satip > channels.conf


    Aber das wird nur dann funktionieren, wenn tvheadend sich wie ein normaler SAT>IP server verhält.


    Die zweite Möglichkeit wäre, einfach einen bekannten Kanal in die channels.conf per Hand einzutragen, mindestens müssen Frequenz, Symbolrate und Modulation stimmen. PIDs sind egal.

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    SAT>IP benutzt den Standard RTSP Server port 554.

    Aber bitte diesen Port nicht zum Internet freigeben. Wer will schon offene Ports zum Inet.



    -s 192.168.178.90|DVBC-2|minisatip -r 430000


    bewirkt, dass Quirks (Eigenarten, Workarounds) für einen SAT>IP Server im Hintergrund aktiv werden, der sich mit den Namen als "minisatip" meldet. Siehe README. Würde ich eher vermeiden und auf das Plugin vertrauen.

  • Compile Warnings in vnsiserver

    Was passiert eigentlich mit den compiler warnings, wenn man einen check einfügt, ob der std::weak_ptr noch gültig ist?

    Ansonsten könnte in videoinput.c Zeilen 467 und 468 recv auf ein ungültiges object zeigen.


    videoinput.c:464 anstelle von

    Code
      // find an active receiver for the device
  for (auto p : s_Pool)
  {
    auto recv = p.lock();
    if (!recv->BeenDetached() && recv->Device() == device)
      return recv;
  }


    eher so, und im loop mit Referenz arbeiten um Kopien zu vermeiden.

    Code
      // find an active receiver for the device
  for (auto& p : s_Pool)
  {
    if (not p.expired()) {
       auto recv = p.lock();
       if (!recv->BeenDetached() && recv->Device() == device)
          return recv;
       }
  }

  • [ANNOUNCE] VDR Version 2.6.6 freigegeben

    Zitat von MarkusE

    Wenn das in Plugins zu raceconditions/Fehlern führt, solltet ihr die Fehler in den Plugins fixen.

    Die Idee als solches ist klasse, keine Frage. Ich glaube auch, dass die Änderung ordentlich Performance geben kann.


    Aber ich vermute, dass in der Änderung als solches noch etwas nicht stimmt, unabh. von möglichen races in Plugins etc.

    malloc() ist eben eine der wenigen Funktionen, die Speicherbereiche checkt, und deswegen landen alle diese backtraces nach dem Problem in malloc und glibc.


    Wir können natürlich einen VDR haben, der super performant ist, aber nicht läuft..

  • [remote] Plugin-Verwendung beendet VDR

    So sieht es beim remote Plugin aus.



    Hier crasht es in cFont::SetFont(eDvbFont, char const*, int)

  • [ANNOUNCE] VDR Version 2.6.6 freigegeben

    Irgendetwas stimmt mit 2.6.6 nicht.


    Unterschiedliche Plugins crashen mit 2.6.6 mehr oder weniger unerklärlich.


    Gerade eben ein backtrace von einem Plugin namens 'epg2vdr', das bei der Verarbeitung von strings crasht.

    Dann die Probleme im vnsi-server Plugin.

    Angeblich control und remote.


    Irgendeine Änderung in 2.6.6 ist faul, glaube ich.

  • [remote] Plugin-Verwendung beendet VDR

    So wie es ausschaut, crasht dein VDR wegen einem Plugin namens ''epg2vdr", aber nicht im control Plugin.

    Ich kenne das Plugin nicht.


    Das hier sind die Zeilen kurz vor dem Problem:


    So wie es ausschaut, crasht dieses Plugin bei der Verwendung von Texten/Zeichenketten (std::string).