Beiträge von wirbel

Ich hab das mal auf https://github.com/wirbel-at-vdr-portal/vdr-cChannel-Name bis patch #4 eingepflegt zum besseren Testen.

Hmm, ich hatte wohl nicht die letzte Version vom Patch erwischt.

mach mal

git pull

und probier noch einmal.

Vielleicht wäre sogar besser, die Kombi aus Name und Source ganz aus cChannel zu entfernen und nur im OSD an der benötigten Stelle zusammen zu bauen.

M-Reimer - danke! Sehe ich ganz genau so, ich hatte das schon gar nicht mehr auf dem Schirm.

Dieser Patch von MarkusE+SHF sollte auf jeden Fall in die nächste VDR Version.

Habe ich in mein temporäres git aufgenommen.

Um so mehr hat RHS mit seinem Kommentar/Nachfrage recht..

Hallo RHS,

ja, das macht definitiv Sinn, Klarheit über die Teststände ist essentiell.

Aber ohne deine intensiven Tests gäbe es keinen Fortschritt bei vnsi, danke dafür.

Ich packe das mal in zwei temporäre github repos auf meinem Account, das macht es leichter für dich.

------------------------------------------------------------------------------------

für vnsiserver bitte das hier verwenden:

GitHub - wirbel-at-vdr-portal/vdr-plugin-vnsiserver-crashes: VDR plugin to handle XBMC clients.

VDR plugin to handle XBMC clients. Contribute to wirbel-at-vdr-portal/vdr-plugin-vnsiserver-crashes development by creating an account on GitHub.

github.com

git clone https://github.com/wirbel-at-v…in-vnsiserver-crashes.git

identisch zu:

Commits · vdr-projects/vdr-plugin-vnsiserver

VDR plugin to handle XBMC clients. Contribute to vdr-projects/vdr-plugin-vnsiserver development by creating an account on GitHub.

github.com

+ processChannels_GetChannels_StateKey.diff

-----------------------------------------------------------------------------------

-----------------------------------------------------------------------------------

für VDR bitte das hier verwenden:

GitHub - wirbel-at-vdr-portal/vdr-cChannel-Name: temporary git repo for debugging cChannel::Name()

temporary git repo for debugging cChannel::Name(). Contribute to wirbel-at-vdr-portal/vdr-cChannel-Name development by creating an account on GitHub.

github.com

git clone https://github.com/wirbel-at-v…tal/vdr-cChannel-Name.git

identisch zu:

vdr-2.6.6 (ohne Patches)

+ changes in cChannels.c for cChannel::Name() (wirbel + kls)

-----------------------------------------------------------------------------------

Du kannst aus beiden repos auch einfach die letzten commits als Patche downloaden..

Gut wäre diese Zeile in vdr/channels.c:56ff noch hinzuzufügen.

Ansonsten hat die Variable u.U. einen beliebigen Startwert.

cChannel::cChannel(void)
{
  name = strdup("");
  shortName = strdup("");
  provider = strdup("");
  portalName = strdup("");
  memset(&__BeginData__, 0, (char *)&__EndData__ - (char *)&__BeginData__);
  parameters = "";
++nameSourceMode = 0;
  modification = CHANNELMOD_NONE;
  seen         = 0;
  schedule     = NULL;
  linkChannels = NULL;
  refChannel   = NULL;
}

Wird zusätzlich ein Lock benötigt? Verändert ja cChannel, evtl. von mehreren Threads aus.

Egal ob mit oder ohne den Patch, die einfache Abfrage von cChannel::Name() ändert in jedem Fall cChannel::nameSource und ist damit immer ein Schreibzugriff.

Und noch schlimmer - das bei jedem Zugriff auf cChannel::Name(), da die if Bedingung

if (isempty(nameSource) || nameSourceMode != Setup.ShowChannelNamesWithSource) {

niemals falsch ergeben kann. nameSourceMode wird immer '0' bleiben und Setup.ShowChannelNamesWithSource bleibt immer bei dem was der Nutzer einstellt, also hier '2'.

Es fehlt also in jedem Fall ein Lock oder ähnliches. Aber dafür müsste nur cChannel gelockt werden, nicht die ganze Kanalliste.

Wenn es satip ist, dann müsste die sources.conf editiert worden sein, um die Auswahl des Satelliten festzulegen. Wäre also auch mal interessant, die Datei zu sehen.

Aber da wir immer über cChannel::Name stolpern:

Was ich auch nicht so ganz verstehe, ist die Bedeutung der Variable nameSourceMode in vdr/channels.c.

Diese Variable wird niemals initialisiert im Konstruktor, aber wird direkt in cChannel::Name verwendet. Ich hätte im Konstruktor erwartet

nameSourceMode = Setup.ShowChannelNamesWithSource;

Wenn nameSourceMode zugewiesen wird, wird immer der gleiche Wert '0' zugewiesen.

Diese Variable ist also entweder uninitiatlisiert, oder gleich '0'. Kein anderer Wert.

Ich hätte ja auch erwartet, dass diese Variable dann nach diesem Vergleich in channels.c:110 neu gesetzt wird:

     if (isempty(nameSource) || nameSourceMode != Setup.ShowChannelNamesWithSource) {
++      nameSourceMode = Setup.ShowChannelNamesWithSource;
        if (Setup.ShowChannelNamesWithSource == 1)
           nameSource = cString::sprintf("%s (%c)", name, cSource::ToChar(source));
        else
           nameSource = cString::sprintf("%s (%s)", name, *cSource::ToString(source));
        }

Auch in cChannel::operator= wird der variable 0 zugewiesen, anstelle vom rhs Channel.nameSourceMode

In cChannel::SetTransponderData wird dann nameSourceMode auf 0 gesetzt (warum nicht Setup.ShowChannelNamesWithSource?), wenn

if (source != Source || frequency != Frequency || srate != Srate || strcmp(parameters, Parameters)) {

Dabei lohnt sich das nur, wenn source != Source.. Jede einzelne Änderung an den Transponderdaten bewirkt Neuzweisung von nameSource, obwohl das gar nicht nötig wäre.

Hat jemand ne Idee?

Vielleicht wäre es hier sinnvoller, std::swap zu verwenden, dann ist der Pointer in der queue definitiv leer und kann ohne Nebenwirkungen weg.

So etwas wie (ungetestet..)

    while (Running())
    {
        try
        {
            std::unique_lock<std::mutex> lock( m_QueueMutex );
            if ( m_QueueCondVar.wait_for(lock, std::chrono::milliseconds(100), [this]()
                {
                    return m_Queue.size() > 0;
                }))
            {
                std::shared_pointer<ICommand> command; // shared ptr w. no managed object
                std::swap(command, m_Queue.front());   // command = m_Queue[0], m_Queue[0] = NULL;
                m_Queue.pop_front();                   // now, remove m_Queue[0]
                lock.unlock();

                command->execute(*this);
                // command should be destroyed automatically here,
                // as ref count goes to zero.
            }
        }
        catch ( const std::exception& error )
        {
            ERRORLOG( "Client error: '%s'. Dropping client", error.what() );
            break;
        }
        catch ( ... )
        {
            ERRORLOG( "Client error: 'Undetermined exception'. Dropping client" );
            break;
        }
    }

Ariane 5 ist wegen floating point cast abgestürzt.

Ich glaube, so wäre korrekter

cString cSource::ToString(int Code)
{
  char buffer[16];
  char *q = buffer;
  *q++ = (Code & st_Mask) >> 24;
  if (int n = Position(Code)) {
     int l = snprintf(q, sizeof(buffer) - 1, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
     if (l < (sizeof(buffer) - 1) && l > 0) {
        q += l;
        *q++ = (n < 0) ? 'W' : 'E';
        }
     }
  *q = 0;
  return buffer;
}

Mir fällt gerade auf, dass diese Zeilen in vdr selbst nicht ok sind.

sources.c:55

cString cSource::ToString(int Code)
{
  char buffer[16];
  char *q = buffer;
  *q++ = (Code & st_Mask) >> 24;
  if (int n = Position(Code)) {
     q += snprintf(q, sizeof(buffer) - 2, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
     *q++ = (n < 0) ? 'W' : 'E';
     }
  *q = 0;
  return buffer;
}

Wenn snprintf hier einen Fehler hat, dann wird snprintf einen negativen return code geben.

Dokumentation: "If an encoding error occurs, a negative number is returned."

Danach würde u.U. die nächste Zeile an eine falsche Stelle im Speicher schreiben:

*q++ = (n < 0) ? 'W' : 'E';

Kannst du bitte den Link zur Dokumentation noch anpassen?

Ist: https://github.com/wirbel-at-v…-satip/blob/master/README

Soll: https://github.com/wirbel-at-v…-satip/blob/wirbel/README

responsepacket_realloc_3.diff.txt sorgt auch dafür, dass malloc() seltener aufgerufen wird, da der buffer um mehr als 'by' vergrößert wird.

Das alleine schon ist gut.

Zitat von M-Reimer

Kann mal bitte jemand auflisten welche Patches aktuell sind? Dann würde ich die gegen Abend in einem neuen Branch mal einbauen.

Ich denke

#83 vnsiserver-gcc12.diff.txt

und

#115 responsepacket_realloc_3.diff.txt

Sollten jetzt schon einmal in dein repo. Aber bitte erst taggen, wenn mehr user input kommt.

Ich hab nur per GUI damit gespielt.

network-caching=xxxx (msec)

Wenn du das buffern ausschaltest, dann wird bei jedem bisschen mehr CPU last oder kurzem Netzwerk Traffic Problem das Bild stottern.

Zumindest war das damals beim analogtv Plugin und dessen Nachfolger pvrinput Plugin das große Problem.

Wie auch immer, damit ist die To-Do Liste beim Plugin (z.Z.) erledigt. Ist doch was.

PS: zum finden solcher Whitespaces benutze ich meist

git add {., <LIST>}

git commit -m <test message>

git show

danach

more <CHANGED_FILE(s)>

und wenn nicht alles ok ist

git reset HEAD~