Streamdev überspringt Kanäle

hummel99 · 12. August 2013

Hallo,

ich habe bei Streamdev Client + Server häufig das Problem dass beim Umschalten ethliche Kanäle übersprungen werden.
Der Server hat einen Dual Tuner, der Client keinen. Jetzt war gearde ein Tuner am Server mit einer Aufnahme belegt.

Beim Umschalten von ARD (Kanal1) auf ZDF loggt der Server:

Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 2 (ZDF HD) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 3 (RTL Television) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 4 (RTL2) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 5 (VOX) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 6 (SAT.1) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 7 (ProSieben) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 8 (kabel eins) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 9 (SIXX) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 11 (n-tv) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 12 (N24) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 13 (DAS VIERTE) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 14 (3sat) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 15 (SUPER RTL) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 16 (DMAX) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 17 (SPORT1) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 18 (Eurosport Deutschland) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 19 (CNBC Europe) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 20 (BBC World) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 21 (CNN Int.) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 22 (EuroNews) at priority 1
Aug 12 22:12:39 vdr vdr: [27834] streamdev: No device provides channel 23 (Sky News Intl) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 24 (CANAL+ LIGA) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 25 (NICK JR) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 26 (VIVA Germany) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 27 (MTV Germany) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 28 (iM1) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 29 (GoTV) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 30 (KiKA) at priority 1
Aug 12 22:12:40 vdr vdr: [27834] streamdev: No device provides channel 31 (NICK/COMEDY) at priority 1

Beim zweiten Mal klappts dann....

Streamdev Server + Client sind auf 0.6.0.

Irgendeine Idee wie man es verhindern kann ? Server war zum diesem Zeitpunkt manuell auf pausiert gesetz.

austen · 13. August 2013

eine Lösung kann ich dir nicht bieten, aber bestätigen kann ich das Verhalten.

Ich habe einen Headless-Server mit einer Dual-Karte, und Clients ohne eine DVB-Karte.
Manchmal beim Hochzappen überspringt der Client ohne Grund irgendwelche Buquets. Gebe ich die Kanalnummer direkt ein, klappt es und ich kann den Sender sehen. Beim nachfolgenden rauf-, runterzappen überspringt er den Sender wieder.
Zu dieser Zeit mache ich weder eine Aufnahme, noch ist ein zweiter Client am Laufen.
Sobald ich dann den Server einmal neu starte, ist das Verhalten wieder normal.
Bis..... Ja, das weiß ich leider auch nicht. Eine Regelmäßigkeit habe ich nicht feststellen können.

gruß

SigVDR · 13. August 2013

Hallo

hier gab es ein ähnliches/gleiches Problem
#mce_temp_url#

Auch der Server belegt zunächst mal einen Tuner

Gruß sig

schmirl · 13. August 2013

Installier auf dem Server mal das devstatus-Plugin (oder auf Client und Server das neue peer-Plugin) und schau Dir im Problemfall die Prioritäten der Server-Devices an. Auch ein Blick in die Verbindungs-Liste des streamdev-server Plugins wäre hilfreich.

austen · 13. August 2013

Hier mal meine Gedanken dazu:

1. ich denke, hummel und ich haben eher das Problem, dass es "manchmal" nicht geht. (hummel schreibt "häufig"). Bei Daniel schien es "nie" zu gehen. Da vermute ich eher den klassischen Einstellungsfehler, der zumindest bei mir nicht vorliegt, da es "meistens" geht.

2. der Hinweis mit Transponder und Buquet war gut. Ich lag wohl auch falsch als ich Buquet schrieb. Natürlich meinte ich Transponder.

3. devstatus läuft jetzt auch. Muss ich nur noch warten, bis die Störung wieder auftritt.

4. ich habe auf dem Server das streamdev-server Plugin wieder ins Hauptmenü geholt. Bei einer Störung werde ich dort auch mal reinschauen.

5. peer-plugin wollte ich eigentlich noch nicht installieren, da ich auf den Clients keine DVB-Karte habe. Das war wohl eher die Intention dieses Plugins. Vielleicht denke ich noch mal darüber nach, falls 3 und 4 nichts Aussagekräftiges liefern.

so. Jetzt heißt es für mich abwarten, bis es wieder passiert, und danke für die Anregungen.
gruß, austen

SigVDR · 13. August 2013

Hallo,

Zitat

ich denke, hummel und ich haben eher das Problem, dass es "manchmal" nicht geht

siehe Anfangsbeitrag:

Zitat

Jetzt war gearde ein Tuner am Server mit einer Aufnahme belegt

dann hab mal trotzdem ein Auge darauf ob es nicht doch nur dann auftritt wenn eine Aufnahme läuft.

Gruß Sig

hummel99 · 13. August 2013

So, nun wieder viel getestet.

Probiert habe ich:

- Kanalliste auf ca.100 Kanäle reduziert die ich alle entschlüsseln kann (auf Server und Client diesselbe Liste) -> keine Veränderung, wenn ein Tuner belegt ist
springt der Client immer noch über Kanäle hinweg, am besten zu reproduzieren wenn man in den Sky Kanälen rumschaltet.

- Kanaliste auf 20 FTA Kanäle reduziert -> Problem nicht reproduzierbar. Bringt mit jedoch wenig da ich fast nur Sky und HD+ schaue.

- Das böse Plugin deaktiviert -> Bei Zappen bleibt der Clien bei MTV "hängen" und schaltet auch nicht drüber da nicht entschlüsselbar.

- den vdr-1.6.0-ignore_missing_cam.diff Patch am Client installiert (hoffe ich zumindest, händisch gepacht:
in der device.c diese Zeilen auskommentiert:

// if (!NumUsableSlots)
// InternalCamNeeded = true; // no CAM is able to decrypt this channel
) -> kein Unterschied zu ohne Patch

- Einen dritten Tuner angeschlossen -> läuft problemlos solange immer zwei frei sind, sobald wieder nur einer frei ist treten die gleichen Probleme wie bei zwei Tunern + eine Aufnahme auf.
- Im Streamdev Server Plugin sehe ich immer nur eine Verbindung, devstatus liefert dass was es soll, den Kanal den der Client zeigt und den Kanal den der Server aufnimmt...

"Installier auf dem Server mal das devstatus-Plugin (oder auf Client und
Server das neue peer-Plugin) und schau Dir im Problemfall die
Prioritäten der Server-Devices an"

Die Prioritäten sehe ich nur im Peer Plugin ? Dann kommt das jetzt mal drauf.

Für micht Laien sieht so aus als könne der Client nur bedingt dem Server das Bild "wegnehmen" (hochschalten klappt meistens nicht, wird dann rückwärts gezappt kommen die übersprungenen Kanäle)

Müsst ja eigentlich bei jeden Server mit einem Tuner passieren, ich teste auch mal mit 1 Tuner ohne Aufnahme.

hummel99 · 13. August 2013

Btw. ich sehe gerade dass wenn zwei Tuner frei sind, der Client beim Zappen die Tuner durchwechselt (Der dritte ist eine TT-USB 3600 und bei dem zeigt Femon am Client keine Signalstärke an, bei der Cine S2 ziegt ers an. Beim Zappen wechselt dann laufend die Anzeige der Singalstärke von den zwei Balken auf nichts)

schmirl · 14. August 2013

Seit VDR 1.7.30 ist der InternalCamPatch hinfällig, da in VDR integriert. Du hast den InternalCam-Teil von VDR deaktiviert. Sofern der Client selbst kein CAM hat und die CA-ID in der channels.conf des Clients nicht auf die Device-Nummer von streamdev-client oder auf 0 gesetzt wurde, sollte der Client jetzt überhaupt keine verschlüsselten Kanäle mehr anwählen können. Bitte rückgängig machen.

Laut Deinem Test tritt das Problem nicht bei FTA auf, ist also ein Problem mit der Verschlüsselung. Da bin ich nun leider außen vor, da ich keine verschlüsselten Kanäle empfangen kann. Bevor es ans Eingemachte geht, könntest Du noch versuchen, auf dem Client die LiveTV Priorität zu erhöhen (derzeit 1?), wird aber vermutlich nichts ändern.

Dann hilft nur noch Debugging der Funktion cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query) auf dem Server. Da Du yavdr nutzt: Prüfe bitte zunächst ob die Methode identisch ist mit Vanilla VDR - nicht dass das Problem durch einen Patch verursacht wird. Dann reichere die Methode mit Debug-Ausgaben an.

Was passieren sollte:
Client fragt an, ob der Kanal verfügbar wäre (Priority wie auf Client eingestellt, Query auf true). Die Priorität des CamSlots und des Devices über das der Client gerade schaut, sollte zu diesem Zeitpunkt um eins kleiner sein als die auf dem Client eingestellte Priorität.
Sofern die Antwort positiv ausfällt: Client versucht umzuschalten (Priority wie auf Client eingestellt, Query auf false). Die Priorität von CamSlot und Device sollte jetzt -100 (IDLEPRIORITY) liefern.

Zitat

Die Prioritäten sehe ich nur im Peer Plugin?

Sorry - ich dachte, devstatus zeigt die Prioritäten auch an

hummel99 · 14. August 2013

Hmm, ok schau ich nach, Priority hatte ich schon oben, hat keinen Unterschied gemacht.

Was allerdings im Log erscheint nachdem er die Kanäle übersprungen hat:

Aug 14 23:03:23 vdr vdr: [19136] TS buffer on device 2 thread started (pid=7055, tid=19136, prio=high)
Aug 14 23:03:24 vdr vdr: [7151] streamdev: No device provides channel 62 (Sky Cinema +1) at priority 1
Aug 14 23:03:24 vdr vdr: [7151] streamdev: No device provides channel 63 (Sky Cinema +24) at priority 1
Aug 14 23:03:24 vdr vdr: [7151] streamdev: No device provides channel 64 (Sky Comedy) at priority 1
Aug 14 23:03:25 vdr vdr: [7151] streamdev: No device provides channel 65 (Sky Atlantic HD) at priority 1
Aug 14 23:03:25 vdr vdr: [7151] streamdev: No device provides channel 66 (Sky Krimi) at priority 1
Aug 14 23:03:25 vdr vdr: [19134] streamdev-livestreaming thread ended (pid=7055, tid=19134)
Aug 14 23:03:25 vdr vdr: [19136] TS buffer on device 2 thread ended (pid=7055, tid=19136)
Aug 14 23:03:25 vdr vdr: [19135] buffer stats: 128780 (3%) used
Aug 14 23:03:25 vdr vdr: [19135] receiver on device 2 thread ended (pid=7055, tid=19135)
Aug 14 23:03:25 vdr vdr: [19133] streamdev-writer thread ended (pid=7055, tid=19133)

Aug 14 23:03:25 vdr vdr: [7151] streamdev-server TUNE S19.2E-133-10-124: Priority unknown - using 0

Aug 14 23:03:26 vdr vdr: [7151] buffer stats: 169012 (4%) used
Aug 14 23:03:26 vdr vdr: [7151] Streamdev: Setting data connection to 192.168.0.64:34452
Aug 14 23:03:26 vdr vdr: [19137] streamdev-writer thread started (pid=7055, tid=19137, prio=high)
Aug 14 23:03:26 vdr vdr: [19138] streamdev-livestreaming thread started (pid=7055, tid=19138, prio=high)
Aug 14 23:03:26 vdr vdr: [19139] receiver on device 2 thread started (pid=7055, tid=19139, prio=high)
Aug 14 23:03:26 vdr vdr: [19140] TS buffer on device 2 thread started (pid=7055, tid=19140, prio=high)

Falls das was zum Problem beiträgt....

hummel99 · 22. August 2013

Hallo,

einen Vanilla VDR habe ich inzwischen gebaut, leider mit dem selben Ergebnis.
Es passiert übrigends auch bei FTA Kanälen.
Hier z.B.
Aufnahme läuft auf Kanal 1 ARD HD
Auf Kanal 7 Pro Sieben geschaltet, dann rückwärts auf 6 Sat 1 und dann springt er auf 1 ARD HD.

Aug 22 21:37:53 vd vdr: [13711] streamdev: No device provides channel 5 (VOX) at priority 3
Aug 22 21:37:53 vd vdr: [13711] streamdev: No device provides channel 4 (RTL2) at priority 3
Aug 22 21:37:53 vdr vdr: [13711] streamdev: No device provides channel 3 (RTL Television) at priority 3
Aug 22 21:37:53 vdr vdr: [13711] streamdev: No device provides channel 2 (ZDF HD) at priority 3

Ist dann cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query) die richtige Stelle ? So wie ich es verstehe gehts da nur um CAM Slots.

schmirl · 3. September 2013

Zitat von hummel99

Ist dann cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query) die richtige Stelle ? So wie ich es verstehe gehts da nur um CAM Slots.

Ja die Stelle ist richtig. Zuerst geht es nur um CAM Slots (und Du hattest ja zunächst das Problem nur bei verschlüsselten Kanälen), aber die Methode ist ein wenig länger...

hummel99 · 5. Oktober 2013

Hab jetzt mal ein paar "Debug" Ausgaben eingebaut.

für jeden Tune Versuch der Kanäle die er überspringt macht er diese Schleife durch:

Code

cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query)
{
// Collect the current priorities of all CAM slots that can decrypt the channel:
int NumCamSlots = CamSlots.Count();
int SlotPriority[NumCamSlots];
int NumUsableSlots = 0;
bool InternalCamNeeded = false;
if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot->ModuleStatus() == msReady) {
if (CamSlot->ProvidesCa(Channel->Caids())) {
if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
SlotPriority[CamSlot->Index()] = CamSlot->Priority();
NumUsableSlots++;
}
}
}
}
if (!NumUsableSlots)
InternalCamNeeded = true; // no CAM is able to decrypt this channel
}
bool NeedsDetachReceivers = false;
cDevice *d = NULL;
cCamSlot *s = NULL;


uint32_t Impact = 0xFFFFFFFF; // we're looking for a device with the least impact
for (int j = 0; j < NumCamSlots || !NumUsableSlots; j++) {
if (NumUsableSlots && SlotPriority[j] > MAXPRIORITY)
continue; // there is no CAM available in this slot
for (int i = 0; i < numDevices; i++) {
if (Channel->Ca() && Channel->Ca() <= CA_DVB_MAX && Channel->Ca() != device->CardIndex() + 1)
continue; // a specific card was requested, but not this one
bool HasInternalCam = device->HasInternalCam();
if (InternalCamNeeded && !HasInternalCam)
continue; // no CAM is able to decrypt this channel and the device uses vdr handled CAMs
if (NumUsableSlots && !HasInternalCam && !CamSlots.Get(j)->Assign(device, true))
continue; // CAM slot can't be used with this device

Alles anzeigen

Im Log:
streamdev: No device provides channel 65 (Sky Atlantic HD) at priority 5
streamdev: No device provides channel 66 (Sky Krimi) at priority 5
streamdev: No device provides channel 67 (Fox HD) at priority 5
streamdev: No device provides channel 68 (Syfy) at priority 5

Wenn streamdev dann diese Zeile loggt:
streamdev-server TUNE S19.2E-133-12-126: Priority unknown - using 0

geht er dann weiter zur ndr Funktion:

Code

bool ndr;


if (device->ProvidesChannel(Channel, Priority, &ndr)) { // this device is basically able to do the job
if (NumUsableSlots && !HasInternalCam && device->CamSlot() && device->CamSlot() != CamSlots.Get(j))

Weiss jetzt nicht ob das was hilft...

hummel99 · 6. Oktober 2013

Was auch noch auffällt, obwohl der Server nicht pausiert ist lässt es sich auf dem Clinet problemlos zappen, ohne Kanal überspringen und ohne dass auf dem Server das
Livebild umgesschaltet wird. Das Problem tritt also erst auf wenn alle Tuner bis auf einen mit Aufnahmen belegt sind.
Und das Problem tritt nur auf wenn ein freier Tuner mit Streamdev verwendet werden soll, wenn ein Tuner mit einer Aufnahme belegt ist und auf dem Server lokal umgeschaltet wird
(also ohne streamdev client) funktioniert es normal.

hummel99 · 12. Oktober 2013

So, habe noch ein paar Tests gemacht:

- Streamdev Cleint Live TV Priority über 50, Server ist nicht pausiert, es läuft eine Aufnahme, also ein Tuner frei:
Beim Umschalten am Client wird die Aufnahme meistens für 1 Sekunde unterbrochen, das Umschalten funktioniert ohne dass Kanäle übersprungen werden.

- Streamdev Cleint Live TV Priority über 50, Server ist pausiert, es läuft eine Aufnahme, also ein Tuner frei:
Beim Umchalten am Client wird die Aufnahme nicht unterbrochen, das Umschalten funktioniert ohne dass Kanäle übersprungen werden.

- Streamdev Cleint Live TV Priority über 50, Server ist pausiert, es laufen zwei Aufnahmen, also kein Tuner frei:
Beim Umschalten am Client wird die Aufnahme so lange unterbrochen bis der Client wieder auf den Transponder schaltet auf dem die unterbrochene Aufnahme läuft, das Umschalten funktioniert ohne dass Kanäle übersprungen
werden

Bei Prio am Client unter 50 werden Kanäle übersprungen wenn nur ein Tuner frei ist, FTA / Verschlüsselt macht keinen Unterschied.

hummel99 · 12. Oktober 2013

Und noch was: mit XVDR klappts auch mit Prio unter 50.

schmirl · 14. Oktober 2013

Zitat

streamdev: No device provides channel 65 (Sky Atlantic HD) at priority 5
streamdev: No device provides channel 66 (Sky Krimi) at priority 5
streamdev: No device provides channel 67 (Fox HD) at priority 5
streamdev: No device provides channel 68 (Syfy) at priority 5

Wenn streamdev dann diese Zeile loggt:
streamdev-server TUNE S19.2E-133-12-126: Priority unknown - using 0

geht er dann weiter zur ndr Funktion

Alles anzeigen

S19.2E-133-12-126 müsste SyfyHD sein. Ist das der nächste Kanal nach 68? Oder ist das der Kanal der auf dem Client lief bevor Du umschalten wolltest? Oder evtl. der Live-Kanal auf dem Server?

Zitat

- Streamdev Cleint Live TV Priority über 50, Server ist nicht pausiert, es läuft eine Aufnahme, also ein Tuner frei:
Beim Umschalten am Client wird die Aufnahme meistens für 1 Sekunde unterbrochen, das Umschalten funktioniert ohne dass Kanäle übersprungen werden.

Vermutlich verdrängt Streamdev die Aufnahme. Der Server merkt kurz darauf, dass da ein Aufnahme in der Luft hängt und legt diese auf die andere DVB-Karte. So ließe sich zumindest der Aussetzer in der Aufnahme erklären.
Erwartet hätte ich, dass Streamdev Live-TV auf dem Server verdrängt (da niedrigere Priorität als die Aufnahme).

Dabei ist mir in cDevice::GetDevice etwas aufgefallen: Wenn nach einem freien Device gesucht wird, wird die Tatsache, dass es sich um das für Live-TV genutzte Device handelt, höher Bewertet als die Priorität. Könntest Du mal die folgende Zeile um zwei Zeilen nach unten schieben (unter die Device und Cam-Slot-Prioritäten Checks)?

Code

imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice();

hummel99 · 14. Oktober 2013

Hi,

die Änderung habe ich mal eingebaut, im ersten Eindruck ist das Problem besser aber nicht ganz weg.

Ich habe hier gerade eine gut reproduzierbare Situation:

- Timer läuft auf ARD HD (Kanal1), Server ist suspended, dummydevice läuft mittlerweile auch.
- Der Client hat eine Prio von 3
- Ich schalte auf Kanal 4 (RTL2 SD)
- Ich schalte rückwärt auf 3 (RTL SD) und schalte bevor das Bild kommt weiter nach unten -> ZDF DH (Kanal 2 wir übersprungen):

Code

Oct 14 21:24:58 vdr vdr: [8840] streamdev-livestreaming thread ended (pid=7920, tid=8840)
Oct 14 21:24:58 vdr vdr: [8842] TS buffer on device 1 thread ended (pid=7920, tid=8842)
Oct 14 21:24:58 vdr vdr: [8841] buffer stats: 105092 (1%) used
Oct 14 21:24:58 vdr vdr: [8841] receiver on device 1 thread ended (pid=7920, tid=8841)
Oct 14 21:24:58 vdr vdr: [8839] streamdev-writer thread ended (pid=7920, tid=8839)
Oct 14 21:24:58 vdr vdr: [8019] buffer stats: 114492 (3%) used
Oct 14 21:24:58 vdr vdr: [8843] streamdev-writer thread started (pid=7920, tid=8843, prio=high)
Oct 14 21:24:58 vdr vdr: [8844] streamdev-livestreaming thread started (pid=7920, tid=8844, prio=high)
Oct 14 21:24:58 vdr vdr: [8844] streamdev-livestreaming thread ended (pid=7920, tid=8844)
Oct 14 21:24:58 vdr vdr: [8843] streamdev-writer thread ended (pid=7920, tid=8843)
Oct 14 21:24:58 vdr vdr: [8019] Streamdev: Setting data connection to 192.168.0.62:47198
Oct 14 21:24:58 vdr vdr: [8845] streamdev-writer thread started (pid=7920, tid=8845, prio=high)
Oct 14 21:24:58 vdr vdr: [8846] streamdev-livestreaming thread started (pid=7920, tid=8846, prio=high)
Oct 14 21:24:58 vdr vdr: [8847] receiver on device 1 thread started (pid=7920, tid=8847, prio=high)
Oct 14 21:24:58 vdr vdr: [8848] TS buffer on device 1 thread started (pid=7920, tid=8848, prio=high)
Oct 14 21:24:58 vdr vdr: [8019] streamdev: No device provides channel 2 (ZDF HD) at priority 3
Oct 14 21:24:59 vdr vdr: [8846] streamdev-livestreaming thread ended (pid=7920, tid=8846)
Oct 14 21:24:59 vdr vdr: [8848] TS buffer on device 1 thread ended (pid=7920, tid=8848)
Oct 14 21:24:59 vdr vdr: [8847] buffer stats: 65236 (0%) used
Oct 14 21:24:59 vdr vdr: [8847] receiver on device 1 thread ended (pid=7920, tid=8847)
Oct 14 21:24:59 vdr vdr: [8845] streamdev-writer thread ended (pid=7920, tid=8845)
Oct 14 21:24:59 vdr vdr: [8019] buffer stats: 65612 (1%) used
Oct 14 21:24:59 vdr vdr: [8849] streamdev-writer thread started (pid=7920, tid=8849, prio=high)
Oct 14 21:24:59 vdr vdr: [8850] streamdev-livestreaming thread started (pid=7920, tid=8850, prio=high)
Oct 14 21:24:59 vdr vdr: [8850] streamdev-livestreaming thread ended (pid=7920, tid=8850)
Oct 14 21:24:59 vdr vdr: [8849] streamdev-writer thread ended (pid=7920, tid=8849)
Oct 14 21:24:59 vdr vdr: [8019] Streamdev: Setting data connection to 192.168.0.62:33370
Oct 14 21:24:59 vdr vdr: [8851] streamdev-writer thread started (pid=7920, tid=8851, prio=high)
Oct 14 21:24:59 vdr vdr: [8852] streamdev-livestreaming thread started (pid=7920, tid=8852, prio=high)

Alles anzeigen

Und hier noch ein Beispiel wenn von Kanal 3 auf 2 schalten will und auch Kanal 2 übersprungen wird:

Code

Oct 14 21:27:33 vdr vdr: [9124] streamdev-livestreaming thread started (pid=7920, tid=9124, prio=high)
Oct 14 21:27:33 vdr vdr: [9123] streamdev-writer thread started (pid=7920, tid=9123, prio=high)
Oct 14 21:27:33 vdr vdr: [9124] streamdev-livestreaming thread ended (pid=7920, tid=9124)
Oct 14 21:27:34 vdr vdr: [9123] streamdev-writer thread ended (pid=7920, tid=9123)
Oct 14 21:27:34 vdr vdr: [8019] Streamdev: Setting data connection to 192.168.0.62:43157
Oct 14 21:27:34 vdr vdr: [9125] streamdev-writer thread started (pid=7920, tid=9125, prio=high)
Oct 14 21:27:34 vdr vdr: [9126] streamdev-livestreaming thread started (pid=7920, tid=9126, prio=high)
Oct 14 21:27:34 vdr vdr: [9127] receiver on device 1 thread started (pid=7920, tid=9127, prio=high)
Oct 14 21:27:34 vdr vdr: [9128] TS buffer on device 1 thread started (pid=7920, tid=9128, prio=high)
Oct 14 21:27:40 vdr vdr: [8019] streamdev: No device provides channel 2 (ZDF HD) at priority 3
Oct 14 21:27:40 vdr vdr: [9126] streamdev-livestreaming thread ended (pid=7920, tid=9126)
Oct 14 21:27:40 vdr vdr: [9128] TS buffer on device 1 thread ended (pid=7920, tid=9128)
Oct 14 21:27:40 vdr vdr: [9125] streamdev-writer thread ended (pid=7920, tid=9125)
Oct 14 21:27:40 vdr vdr: [9127] buffer stats: 78772 (0%) used
Oct 14 21:27:40 vdr vdr: [9127] receiver on device 1 thread ended (pid=7920, tid=9127)
Oct 14 21:27:40 vdr vdr: [8019] buffer stats: 111108 (2%) used
Oct 14 21:27:40 vdr vdr: [9130] streamdev-writer thread started (pid=7920, tid=9130, prio=high)
Oct 14 21:27:40 vdr vdr: [9131] streamdev-livestreaming thread started (pid=7920, tid=9131, prio=high)
Oct 14 21:27:40 vdr vdr: [9131] streamdev-livestreaming thread ended (pid=7920, tid=9131)
Oct 14 21:27:40 vdr vdr: [9130] streamdev-writer thread ended (pid=7920, tid=9130)
Oct 14 21:27:40 vdr vdr: [8019] Streamdev: Setting data connection to 192.168.0.62:35418
Oct 14 21:27:40 vdr vdr: [9132] streamdev-writer thread started (pid=7920, tid=9132, prio=high)
Oct 14 21:27:40 vdr vdr: [9133] streamdev-livestreaming thread started (pid=7920, tid=9133, prio=high)

Alles anzeigen

schmirl · 16. Oktober 2013

Die Änderung in cDevice::GetDevice hat nichts mit dem Überspringen der Kanäle zu tun. Da ging es um das Problem, dass Streamdev für Unterbrechungen in Aufnahme sorgt anstatt LiveTV zu verdrängen. Ist dieses Problem verschwunden?

Bezüglich des Überspringens müsste GetDevice mit Debug-Ausgaben bzgl. Priorität ausgestattet werden. So wie es aussieht, blockiert ja irgendetwas ein Device und/oder einen Cam-Slot, was dann zu der "No device provides channel ... at priority ..."-Meldung führt.

Konkret: die Übergabeparameter an GetDevice, eine Ausgabe mit CamSlot->Index(), CamSlot->Priority() und der letzlich ermittelten SlotPriority[CamSlot->Index()] in der oberen for-Schleife, den Wert von NumUsableSlots und IinternalCamNeeded nach der Schleife und in der doppelten for-Schleife i und j, ob ProvidesChannel erfolgreich war und falls ja imp und ndr. Ich kann Dir das auch als Patch schicken.

hummel99 · 16. Oktober 2013

Hi, über Patches freue ich mich natürlich, meine Debugausgaben ware "etwas" unbeholfen...

Zitat

Die Änderung in cDevice::GetDevice hat nichts mit dem Überspringen der
Kanäle zu tun. Da ging es um das Problem, dass Streamdev für
Unterbrechungen in Aufnahme sorgt anstatt LiveTV zu verdrängen. Ist
dieses Problem verschwunden?

Sorry, hatte ich falsch verstanden, ich teste das Szenario nochmal und gebe Rückmeldung.

Streamdev überspringt Kanäle

Jetzt mitmachen!

Teilen