[Streamdev]Funktion cStatus::ChannelChange()

Wie wäre es das als Featurerequest im streamdev Bugtracker einzutragen und mit ein paar ergänzenden Hinweisen zu versehen ? Bin mir sicher dann gehts schneller

http://projects.vdr-developer.org/projects/plg-streamdev

Lg,
Joe

Zur Vollständigkeit: Hier gibt es eine Testversion von streamdev mit ChannelChange.

Hi,

gibt es hier schon Fortschritte? Läuft Streamdev-server mit dem gesagten Plugin inzwischen ohne Umschaltprobleme unter VDR 2.1.6+?

Seit irgendeiner Version funktioniert alles, weiss aber nicht mehr genau, ab wann. Mit stable 2.2.0 auf jeden fall.

Ich habe es auch mal wieder versucht mit VDR 2.2 und Voldemort (alt, neu). Der neue ist weit zuverlässiger, allerdings wird noch nicht die Stabilität von 2.0.3 (alt) erreicht.
Beim Zappen habe ich immer wieder Kanäle, die funktionieren oder auch nicht. Ein System habe ich dabei nicht entdecken können. Nach mehreren Versuchen komme ich zwar auf jeden Kanal, aber eben nicht immer beim ersten, zweiten oder dritten, sondern irgendwann.

Im Log finde ich immer wieder

vdr: [7011] ERROR (dvbdevice.c,1464): Das Argument ist ungültig
vdr: [7011] ERROR: can't set PID -1 on device 2
kernel: [20442804.895591] dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)

oder auch sehr häufig

vdr: [8424] too many PIDs in cReceiver (Pid = 5376)

Aber ob da ein Zusammenhang besteht, weiß ich nicht. Wenn ich einen Hinweis hätte, wonach ich Ausschau halten soll, könnte ich weiter testen. Debug-Ausgaben könnte ich auch einfügen, wenn ich wüsste wo und was.

Auf jeden Fall ist dies für mein Setup noch nicht ausreichend stabil genug. Da brauche ich ein zuverlässigen Wechsel der Kanäle.

Rechner 1:
Server (8 DVB Devices, Streamdev-Server)
Record-Client1 (Streamdev Client, Nur für Aufnahmen von Client 1)
Record-Client2 (Streamdev Client, Nur für Aufnahmen von Client 2)

Rechner 2:
Client 1 (Streamdev-Client, Live-TV connect zum Server, Timer an Record-Client1)

Rechner 3:
Client 2 (Streamdev-Client, Live-TV connect zum Server, Timer an Record-Client2)

Zabrimus

Probier mal ob es was bringt wenn du die maximale Anzahl an receiver- und device-PIDs erhöhst:

Index: receiver.h
===================================================================
--- receiver.h.orig	2014-11-07 13:04:35.407158486 +0100
+++ receiver.h	2014-11-07 13:04:46.000000000 +0100
@@ -12,7 +12,7 @@
 
 #include "device.h"
 
-#define MAXRECEIVEPIDS  64 // the maximum number of PIDs per receiver
+#define MAXRECEIVEPIDS  128 // the maximum number of PIDs per receiver
 
 class cReceiver {
   friend class cDevice;
Index: device.h
===================================================================
--- device.h.orig	2014-11-07 15:33:42.695086776 +0100
+++ device.h	2014-11-07 15:34:07.000000000 +0100
@@ -27,7 +27,7 @@
 #include "tools.h"
 
 #define MAXDEVICES         16 // the maximum number of devices in the system
-#define MAXPIDHANDLES      64 // the maximum number of different PIDs per device
+#define MAXPIDHANDLES      128 // the maximum number of different PIDs per device
 #define MAXRECEIVERS       16 // the maximum number of receivers per device
 #define MAXVOLUME         255
 #define VOLUMEDELTA         5 // used to increase/decrease the volume

Ich hatte endlich mal wieder Zeit zu testen.

Erst dachte, die Meldungen wären weg, aber wenn ich sehr oft umschalte, tauchen sie wieder auf. Wird da irgendwas nicht freigegeben oder läuft ein Puffer über?
Auf das eigentliche Problem hatten diese Änderungen aber leider keine Auswirkungen

Zabrimus

Ich habe einen Patch für streamdev erstellt, mit dem das Umschalten ziemlich problemlos funktioniert.

Allerdings erhalte ich nach einigen Umschaltvorghängen wieder Meldungen der Form

too many PIDs in cReceiver (Pid = 6494)
too many PIDs in cReceiver (Pid = 5381)
too many PIDs in cReceiver (Pid = 5382)
too many PIDs in cReceiver (Pid = 5383)
too many PIDs in cReceiver (Pid = 560)

Ab dem Zeitpunkt wird Umschalten zu einem Glücksspiel. Verwendet habe ich einen ungepatchten VDR 2.2.0, wobei ab VDR 2.1.7 das Problem eigentlich gelöst sein soll, wenn ich das richtig verstanden habe. In einem anderen Thread habe ich gelesen, daß der Wert 128 for MAXRECEIVEPIDS schon extrem hoch sein soll.

Wie kann man das Problem denn noch umgehen?

Zabrimus

Mal ein kurzer Zwischenstand meiner Forschung. Es werden tatsächlich bei jedem Umschalten (Non-FTA) solange PID gesammelt, bis die Maximalgrenze erreicht ist.

Ich konnte das Problem auf den cCaPidReceiver aus dem VDR eingrenzen. Dieser cReceiver sammelt und sammelt. Jetzt verstehe ich nur nicht, wann und wer diese PID wieder löschen soll? In cCamSlot:: SendCaPmt werden oder sollen wohl welche gelöscht werden. Allerdings werden es immer nur minimal weniger, bevor wieder neue angehängt werden.

Zabrimus