Zu viele PIDs?

  • Hallo Zusammen,


    im Log sehe sich immer mal wieder Meldungen wie diese,


    Code
    1. .....
    2. Oct 12 08:45:06 [vdr] [519] [softhddev]SetPlayMode: 1_
    3. Oct 12 08:45:07 [vdr] [15378] too many PIDs in cReceiver (Pid = 4105)
    4. Oct 12 08:45:07 [vdr] [15378] too many PIDs in cReceiver (Pid = 3312)
    5. .....


    Mich würde jetzt einfach interessieren, woher die kommen, bzw. was die bedeuten?

  • Ein receiver will nie den gesamten TS empfangen, sondern immer nur eine Auswahl an Paketen und zwar die, die zu dem entsprechenden Kanal gehören. Dazu werden die Video- und Audio-PIDs als Filter gesetzt (und Teletext usw.).
    Du hast da offentsichtlich einen Kanal, der das interne Limit von 64 PIDs pro Receiver sprengt. In receiver.h gibt es einen define MAXRECEIVEPIDS, den könntest du ja mal hochsetzen.


    Der Kanal ist wahrscheinlich verschlüsselt, oder?


    Lars

  • Ob der Kanal verschlüsselt war, kann ich jetzt noch nicht einmal sagen, ich habe halt diese Meldungen im Log gefunden.


    Könnte das auch von einem EPG-Scan kommen, oder kommen solche Meldungen nur wenn "richtig" auf den entsprechenden Kanal getunt wird?


    Die "MAXRECEIVEPIDS" zu erhöhen, wäre sicherlich kein Problem, nur denke ich, dass es doch sicherlich einen Grund hat, weshalb diese auf 64 begrenzt wurden?


    Wenn ich nun die "MAXRECEIVEPIDS" erhöhe, wäre da 128 ein idealer Wert?

  • Ja, der EPG-Scan kann auch so eine Meldung verursachen, dabei wird ein device auch nur ganz normal auf einen Kanal geschaltet.
    Ich finde 64 auch schon ziemlich hoch, normalerweise gibt es ja eine Video-PID, eine handvoll Audiospuren, einmal DvB-Text. Ich weiß nicht, wie viele PIDs für das Entschlüsseln (wenn überhaupt) benutzt werden.


    Findest du die Pids in deiner channels.conf? Ansonsten könnte man diese Meldung im vdr ja mal um die Kanal-Id erweitern.
    Auf dem Tablet ist das mit Code-tippen immer etwas schwierig...


    Ein %s hinten anhängen und als zusätzlichen Parameter *channelID.ToString()
    In receiver.c, Zeile 38 in dem dsyslog.


    Code
    1. ...Pid = %d, %s)", Pid, *channelID.ToString());


    Lars

  • Hallo zusammen,


    ich wollte nur anmerken, dass sich auch bei mir die von 3PO genannten Probleme, sowie das Setzen von PIDs in unsinniger Höhe erledigt haben, nachdem ich MAXRECEIVEPIDS auf 128 erhöht habe.
    Wobei ich glaube, dass die "unerlaubten" PID Werte daher stammten, dass auf ARM char standardmäßig als unsigned-char behandelt werden.
    Mit -fsigned-char hat sich das Problem dann erledigt. Lars' "Suchhilfe" habe ich nicht ausprobiert.


    Gruß Andreas

  • Ein receiver will nie den gesamten TS empfangen, sondern immer nur eine Auswahl an Paketen und zwar die, die zu dem entsprechenden Kanal gehören. Dazu werden die Video- und Audio-PIDs als Filter gesetzt (und Teletext usw.).
    Du hast da offentsichtlich einen Kanal, der das interne Limit von 64 PIDs pro Receiver sprengt. In receiver.h gibt es einen define MAXRECEIVEPIDS, den könntest du ja mal hochsetzen.


    Der Kanal ist wahrscheinlich verschlüsselt, oder?


    Lars


    64 finde ich schon übertrieben, aber 128 ist totaler Overkill.


    Zum Vergleich: in w_scan begrenze ich die Anzahl PIDs auf 27 (ursprünglich waren es 32, aber es gab einige Tuner mit Hardware PID-Filter die bereit mit dieser Anzahl Probleme hatten).

  • 64 finde ich schon übertrieben, aber 128 ist totaler Overkill.


    Das finde ich auch. Schade, dass keiner die Logmeldung erweitert, so dass man mal mitbekommt, welcher Kanal das eigentlich ist. Wäre genauso aufwendig gewesen, wie das Limit hochzusetzen.


    Lars.

  • Quote

    Das finde ich auch. Schade, dass keiner die Logmeldung erweitert,


    ^^ Na jetzt, ich hols nach... Nächste Woche mal, wenn sich zwischenzeitlich keiner erbarmt ;)


    Gruß Andreas


  • Wozu, der Fehler wurde doch gefunden und behoben?


    Mit welcher Änderung wurde das gelöst bzw. was war die Ursache?


    Gruß Andreas

  • Hier


    Das Problem wurde in vdr-2.1.7 gefixt. ;)


    Es sei denn, Jemand hat den VDR mit dem "txtsubs-Patch" gepatcht, denn der verursacht auch das o.g. Problem.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB


  • Mit welcher Änderung wurde das gelöst bzw. was war die Ursache?


    Die Ursache war, daß es unter bestimmten Bedingungen dazu kommen konnte, daß der cReceiver eines cCamSlot, der dazu benutzt wird, die CAT, ECM und EMM Pids zu empfangen, beim Kanalumschalten nicht vollständig zurückgesetzt wurde, was zur Folge hatte, daß sich mit derZeit immer mehr Pids darin ansammelten. Die Lösung war, den Receiver an geeigneter Stelle zurückzusetzen. Details kannst du dem Diff entnehmen.


    Klaus

  • Irgendwie habe ich diese Logs jetzt in 2.1.8 auch neuerdings:


    Code
    1. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4099)
    2. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4101)
    3. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4104)
    4. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4118)
    5. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4103)
    6. Feb 1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4121)


    Kann das noch an was anderem liegen als das in 2.1.7 gefixte?

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

  • Das Problem tritt mit der Version 2.2.0 auch noch auf.


    Nach meinen Untersuchungen sammelt der cReceiver des cCaPidReceiver bei jedem Umschalten PIDs. Die pidhandle des cDevice werden zwar immer wieder nach dem Umschalten sauber abgeräumt, aber dann durch die PIDs des cReceivers(cCaPidReceiver) nicht nur wieder vollständig gefüllt, sondern mit weiteren PIDs irgendwann zum Überlaufen gebracht.


    Ich habe testweise versucht in cDevice:: Detach(cReceiver *Receiver) die PID aus dem Receiver zu löschen bzw. zu begrenzen. Das ist keine Lösung, da mir in C++ sowas wie instanceof aus Java fehlt, um zu prüfen, ob der richtige Receiver anliegt. Die Begrenzung auf eine bestimmte Anzahl PID durch Receiver->DelPid(Receiver->pids[n]) hat das Problem zumindest sehr stark verzögert.


    Aus dem Diff zu 2.1.7 bin ich nicht richtig schlau geworden, wie die eine vernünftige Lösung aussehen kann.


    Getestet habe ich mit dem streamdev-server, einem Frontend und genau einem Client.


    Zabrimus

  • Der angehängte Patch löst das Problem zwar nicht vollständig, aber verschiebt es weit nach hinten.


    Getestet:
    1 Client, 1 Transponder => Kein Problem, die Anzahl der PID bleiben konstant niedrig
    2 Client, 1 Transponder => Die Anzahl der PID steigt pro Umschaltvorgang zwar, erreicht die max. Grenze aber erst nach sehr vielen Umschaltvorgängen
    2 Client, 2 Transponder => Kein Problem, die Anzahl der PID bleiben konstant niedrig
    > 2 Client, 2 Transponder => Die Anzahl der PID steigt pro Umschaltvorgang zwar, erreicht die max. Grenze aber erst nach sehr vielen Umschaltvorgängen


    Insgesamt gesehen müssen mehrere Clients - auf demselben Transponder - sehr oft das Programm wechseln, damit die max. Anzahl der PID erreicht wird.


    Zabrimus


    ps: Das Problem tritt nur bei Non-FTA Sendern auf.


    vdr-2.2.0-clear-pids.diff.gz

  • Manchmal kann Abstand gar nicht schaden und man kann dann einzelne Bäume im Wald wieder erkennen.


    Ein kurzer Test ergab, daß die Anzahl der PID im cReceiver immer weiter ansteigt. Meine ursprüngliche Annahme war richtig, die entsprechende Lösung aber schwach. Die Anzahl der PID steigt, weil keine Duplikatprüfung stattfindet, sondern sich in der Liste PIDs mehrfach ansammeln, bis irgendwann die maximale Anzahl erreicht ist.


    Eine kleine Änderung im cReceiver und die Anzahl der PIDs bleibt konstant niedrig und trotzdem funktioniert noch alles. Egal wieviele Client und Transponder.




    Zabrimus