Zu viele PIDs?

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

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.

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

Tja, 2.1.7 habe ich noch nicht probiert :p
Gruß Andreas

Zitat von mini73

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

Zitat von wirbel

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.

Zitat

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

Zitat von 3PO

Wozu, der Fehler wurde doch gefunden und behoben?

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

Gruß Andreas

Hier

Zitat von 3PO

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.

Zitat von rell

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

Ok. Gefunden.
Danke
Andreas

Irgendwie habe ich diese Logs jetzt in 2.1.8 auch neuerdings:

Feb  1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4099)
Feb  1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4101)
Feb  1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4104)
Feb  1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4118)
Feb  1 19:03:33 vdr vdr: [2146] too many PIDs in cReceiver (Pid = 4103)
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?

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.

--- receiver.c.orig     2015-09-15 18:26:51.382072179 +0200
+++ receiver.c  2015-09-15 17:57:02.496557889 +0200
@@ -32,19 +32,21 @@
 void cReceiver::SetPriority(int Priority)
 {
   priority = constrain(Priority, MINPRIORITY, MAXPRIORITY);
 }
 
 bool cReceiver::AddPid(int Pid)
 {
   if (Pid) {
-     if (numPids < MAXRECEIVEPIDS)
-        pids[numPids++] = Pid;
-     else {
+     if (numPids < MAXRECEIVEPIDS) {
+         if (!WantsPid(Pid)) {
+            pids[numPids++] = Pid;
+         }
+     } else {
         dsyslog("too many PIDs in cReceiver (Pid = %d)", Pid);
         return false;
         }
      }
   return true;
 }
 
 bool cReceiver::AddPids(const int *Pids)

Zabrimus