Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 11. März 2013, 13:33

Probleme mit Aufnahmeprioritäten und wahrscheinlich Devicebonding

Hallo Klaus,

Ja ich weiß, der schon wieder mit Devicebonding .

Ich habe hier gestern noch ein Problem mir der Priorität bei Aufnahmen festgestellt. Wenn ich nicht zufällig auch gerade Live geschaut hätte, wäre es mir wohl nie aufgefallen.

Also folgendes Szenario:
2 Aufnahmen programmiert, die sich überlappen, die zweite Aufnahme mit höherer Priorität ( die Erste 50, die Zweite 60) mit unterschiedlicher Polarität oder Band, hier im Fall Das Erste und Das Erste HD

Wenn jetzt die Zeit für die zweite Aufnahme heran ist, dann wird die zweite Aufnahme ordnungsgemäß gestartet, allerdings scheint die erste Aufnahme nicht korrekt beendet zu werden. Sichtbar wird das, indem das Livebild schwarz wird und dann kein Kanalwechsel mehr möglich ist. Danach folgt dann nach timeout (bei mir 2min) ein emergency exit.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Mar 11 12:20:00 home-05 vdr: [15327] switching device 4 to channel 2
Mar 11 12:20:00 home-05 vdr: [15327] timer 97 (2 1220-1225 'ARD-Buffet') start
Mar 11 12:20:00 home-05 vdr: [15327] Title: 'ARD-Buffet' Subtitle: 'Leben & genießen'
Mar 11 12:20:00 home-05 vdr: [15327] record /video/video0/ARD-Buffet/2013-03-11.12.20.2-0.rec
Mar 11 12:20:00 home-05 vdr: [15327] creating directory /video/video0/ARD-Buffet
Mar 11 12:20:00 home-05 vdr: [15327] creating directory /video/video0/ARD-Buffet/2013-03-11.12.20.2-0.rec
Mar 11 12:20:00 home-05 vdr: [15327] recording to '/video/video0/ARD-Buffet/2013-03-11.12.20.2-0.rec/00001.ts'
Mar 11 12:20:01 home-05 vdr: [15508] recording thread started (pid=15327, tid=15508, prio=high)
Mar 11 12:20:01 home-05 vdr: [15509] receiver on device 4 thread started (pid=15327, tid=15509, prio=high)
Mar 11 12:20:01 home-05 vdr: [15510] TS buffer on device 4 thread started (pid=15327, tid=15510, prio=high)
...
Mar 11 12:23:00 home-05 vdr: [15327] switching device 2 to channel 3
Mar 11 12:23:00 home-05 vdr: [15327] timer 98 (3 1223-1230 'ARD-Buffet') start
Mar 11 12:23:00 home-05 vdr: [15327] Title: 'ARD-Buffet' Subtitle: 'Leben & genießen'
Mar 11 12:23:00 home-05 vdr: [15327] record /video/video0/ARD-Buffet/2013-03-11.12.23.3-0.rec
Mar 11 12:23:00 home-05 vdr: [15327] creating directory /video/video0/ARD-Buffet/2013-03-11.12.23.3-0.rec
Mar 11 12:23:00 home-05 vdr: [15327] recording to '/video/video0/ARD-Buffet/2013-03-11.12.23.3-0.rec/00001.ts'
Mar 11 12:23:00 home-05 vdr: [15617] recording thread started (pid=15327, tid=15617, prio=high)
Mar 11 12:23:00 home-05 vdr: [15618] receiver on device 2 thread started (pid=15327, tid=15618, prio=high)
Mar 11 12:23:00 home-05 vdr: [15619] TS buffer on device 2 thread started (pid=15327, tid=15619, prio=high)
Mar 11 12:23:01 home-05 vdr: [15337] channel 3 (Das Erste) event Mon 11.03.2013 12:15-13:00 (VPS: 11.03. 11:05) 'ARD-Buffet' status 4
Mar 11 12:23:01 home-05 vdr: [15327] switching to channel 3
Mar 11 12:23:01 home-05 vdr: [15327] info: Kanal nicht verfügbar!
Mar 11 12:23:04 home-05 vdr: [15327] max. latency time 5 seconds
Mar 11 12:23:31 home-05 vdr: [15508] ERROR: video data stream broken
Mar 11 12:23:31 home-05 vdr: [15508] initiating emergency exit
Mar 11 12:24:02 home-05 vdr: [15508] ERROR: video data stream broken
Mar 11 12:24:02 home-05 vdr: [15508] initiating emergency exit
Mar 11 12:24:33 home-05 vdr: [15508] ERROR: video data stream broken
Mar 11 12:24:33 home-05 vdr: [15508] initiating emergency exit
Mar 11 12:25:04 home-05 vdr: [15508] ERROR: video data stream broken
Mar 11 12:25:04 home-05 vdr: [15508] initiating emergency exit
Mar 11 12:25:25 home-05 vdr: [15327] PANIC: watchdog timer expired - exiting!


Kanal 2 ist Das Erste HD
Kanal 3 ist Das Erste

Möglicherweise tritt solch ein Problem auch in einer "normalen" Konfiguration ohne Devicebonding auf, das kann ich leider hier nicht testen, wenn eine weitere Aufnahme mit höherer Priorität kein freies Device findet und dann eine andere Aufnahme abbrechen müßte.

Getestet mit PlainVDR 1.7.40 + remote + dvbhddevice

Falls wieder Testbedarf besteht, stehe ich gern zur Verfügung.

Gruß
kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

2

Montag, 11. März 2013, 15:02

Hallo Klaus,

Ja ich weiß, der schon wieder mit Devicebonding .

Ich habe hier gestern noch ein Problem mir der Priorität bei Aufnahmen festgestellt. Wenn ich nicht zufällig auch gerade Live geschaut hätte, wäre es mir wohl nie aufgefallen.

Also folgendes Szenario:
2 Aufnahmen programmiert, die sich überlappen, die zweite Aufnahme mit höherer Priorität ( die Erste 50, die Zweite 60) mit unterschiedlicher Polarität oder Band, hier im Fall Das Erste und Das Erste HD

Wenn jetzt die Zeit für die zweite Aufnahme heran ist, dann wird die zweite Aufnahme ordnungsgemäß gestartet, allerdings scheint die erste Aufnahme nicht korrekt beendet zu werden. Sichtbar wird das, indem das Livebild schwarz wird und dann kein Kanalwechsel mehr möglich ist. Danach folgt dann nach timeout (bei mir 2min) ein emergency exit.

...

Kanal 2 ist Das Erste HD
Kanal 3 ist Das Erste

Möglicherweise tritt solch ein Problem auch in einer "normalen" Konfiguration ohne Devicebonding auf, das kann ich leider hier nicht testen, wenn eine weitere Aufnahme mit höherer Priorität kein freies Device findet und dann eine andere Aufnahme abbrechen müßte.

Getestet mit PlainVDR 1.7.40 + remote + dvbhddevice

Falls wieder Testbedarf besteht, stehe ich gern zur Verfügung.

Ich hatte hier neulich diesen Vorschlag bekommen

Quellcode

1
2
3
4
5
6
7
8
9
10
11
--- dvbdevice.c 2013/03/07 09:42:29     2.84
+++ dvbdevice.c 2013/03/11 14:00:24
@@ -426,7 +426,7 @@
      cString BondingParams = GetBondingParams(Channel);
      do {
         if (t->device->Priority() > IDLEPRIORITY || ConsiderOccupied && t->device->Occupied()) {
-           if (strcmp(BondingParams, t->GetBondingParams()) != 0)
+           if (strcmp(BondingParams, t->GetBondedMaster()->GetBondingParams()) != 0)
               return false;
            }
         t = t->bondedTuner;

wollte den aber nicht mehr für die Version 2.0 aufnehmen, da ich einen konkreten Vorteil nicht direkt nachvollziehen konnte.
Kannst du diese Änderung mal in deinem Szenario ausprobieren? Falls es da hilft, dann würde ich es doch noch übernehmen.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

3

Montag, 11. März 2013, 15:49

Mit dem Patch ist das Problem noch nicht behoben, eine geringfügige Änderung gab es aber trotzdem: Das Live-Bild blieb nach dem Start der zweiten Aufnahme nicht schwarz, sondern es wurde auf den neuen Kanal umgeschaltet, so wie man es erwarten würde.
Das Problem des emergency exit bleibt aber bestehen.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Mar 11 15:25:00 home-05 vdr: [11695] switching device 4 to channel 2
Mar 11 15:25:00 home-05 vdr: [11695] timer 88 (2 1525-1530 'Sturm der Liebe (1718)~Fernsehserie Deutschland 2013') start
Mar 11 15:25:00 home-05 vdr: [11695] Title: 'Sturm der Liebe (1718)' Subtitle: 'Fernsehserie Deutschland 2013'
Mar 11 15:25:00 home-05 vdr: [11695] record /video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.25.2-0.rec
Mar 11 15:25:00 home-05 vdr: [11695] creating directory /video/video0/Sturm_der_Liebe_(1718)
Mar 11 15:25:00 home-05 vdr: [11695] creating directory /video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013
Mar 11 15:25:00 home-05 vdr: [11695] creating directory /video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.25.2-0.rec
Mar 11 15:25:00 home-05 vdr: [11695] recording to '/video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.25.2-0.rec/00001.ts'
Mar 11 15:25:00 home-05 vdr: [11951] recording thread started (pid=11695, tid=11951, prio=high)
Mar 11 15:25:00 home-05 vdr: [11952] receiver on device 4 thread started (pid=11695, tid=11952, prio=high)
Mar 11 15:25:00 home-05 vdr: [11953] TS buffer on device 4 thread started (pid=11695, tid=11953, prio=high)
Mar 11 15:28:00 home-05 vdr: [11695] switching device 2 to channel 3
Mar 11 15:28:00 home-05 vdr: [11695] timer 89 (3 1528-1535 'Sturm der Liebe (1718)~Fernsehserie Deutschland 2013') start
Mar 11 15:28:00 home-05 vdr: [11695] Title: 'Sturm der Liebe (1718)' Subtitle: 'Fernsehserie Deutschland 2013'
Mar 11 15:28:00 home-05 vdr: [11695] record /video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.28.3-0.rec
Mar 11 15:28:00 home-05 vdr: [11695] creating directory /video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.28.3-0.rec
Mar 11 15:28:00 home-05 vdr: [11695] recording to '/video/video0/Sturm_der_Liebe_(1718)/Fernsehserie_Deutschland_2013/2013-03-11.15.28.3-0.rec/00001.ts'
Mar 11 15:28:01 home-05 vdr: [12059] recording thread started (pid=11695, tid=12059, prio=high)
Mar 11 15:28:01 home-05 vdr: [12060] receiver on device 2 thread started (pid=11695, tid=12060, prio=high)
Mar 11 15:28:01 home-05 vdr: [12061] TS buffer on device 2 thread started (pid=11695, tid=12061, prio=high)
Mar 11 15:28:01 home-05 vdr: [11704] channel 3 (Das Erste) event Mon 11.03.2013 15:10-16:00 (VPS: 11.03. 15:10) 'Sturm der Liebe (1718)' status 4
Mar 11 15:28:02 home-05 vdr: [11695] switching to channel 3
Mar 11 15:28:32 home-05 vdr: [11951] ERROR: video data stream broken
Mar 11 15:28:32 home-05 vdr: [11951] initiating emergency exit
Mar 11 15:28:32 home-05 vdr: [11695] emergency exit requested - shutting down


Wie man unten im Log sieht, fehlen jetzt die 2min timeout. Ich denke das "ERROR: video data stream broken" kommt von der ersten Aufnahme, denn es fehlt im Log auch so was wie "recording thread ended" für die erste Aufnahme.

kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

4

Dienstag, 12. März 2013, 12:01

Mit dem Patch ist das Problem noch nicht behoben, eine geringfügige Änderung gab es aber trotzdem: Das Live-Bild blieb nach dem Start der zweiten Aufnahme nicht schwarz, sondern es wurde auf den neuen Kanal umgeschaltet, so wie man es erwarten würde.

OK, dann scheint der Patch schon mal was zu bringen und ich werde ihn noch für die Version 2.0 übernehmen.

Zitat


Das Problem des emergency exit bleibt aber bestehen.

Das untersuche ich gerade.
Wie sind denn deine Devices genau gebondet?

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

5

Dienstag, 12. März 2013, 12:45

Wie sind denn deine Devices genau gebondet?
Alle 4 zusammen über einen 4fach-Verteiler auf ein Kabel.

Kannst Du mir noch sagen, ob das OK ist, wenn er für die erste Aufnahme Device 4 nimmt und für die zweite Aufnahme Device 2, obwohl Device 3 auch noch frei ist.

Bei mir ist Device 1 und 2 die TT6400, Device 3 und 4 sind die beiden Anderen (Signatur).

kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

6

Dienstag, 12. März 2013, 12:47


Das Problem des emergency exit bleibt aber bestehen.

Das untersuche ich gerade.
Wie sind denn deine Devices genau gebondet?

Egal, ich glaube, ich habe das Problem gefunden.
Probier bitte mal folgendes (zusätzlich zu dem vorherigen Patch):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
--- dvbdevice.c 2013/03/12 10:08:34     2.85
+++ dvbdevice.c 2013/03/12 11:43:29
@@ -1494,7 +1494,7 @@
                      }
                   }
               needsDetachBondedReceivers = true;
-              needsDetachReceivers = Receiving();
+              needsDetachReceivers = true;
               }
            }
         }

Damit schaltet er bei mir in dem geschilderten Fall richtig zwischen den Timern um, und es kommt auch gleich wieder ein Live-Bild.
Bitte ganz intensiv testen, denn das werde ich noch in die Version 2.0 aufnehmen.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

7

Dienstag, 12. März 2013, 12:51

Wie sind denn deine Devices genau gebondet?
Alle 4 zusammen über einen 4fach-Verteiler auf ein Kabel.

Kannst Du mir noch sagen, ob das OK ist, wenn er für die erste Aufnahme Device 4 nimmt und für die zweite Aufnahme Device 2, obwohl Device 3 auch noch frei ist.

Device 3 und 4 sind ja unterschiedlich (Hauppauge Nova HD-S2, SkyStar HD2). Evtl. haben die unterschiedliche Eigenschaften, und VDR "verschont" die mit mehr Eigenschaften so lange es geht.

Zitat


Bei mir ist Device 1 und 2 die TT6400, Device 3 und 4 sind die beiden Anderen (Signatur).

Ich sollte mir wohl angewöhnen, die Signaturen in solchen Fällen zu lesen... ;-)

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

8

Dienstag, 12. März 2013, 13:18

Ich sollte mir wohl angewöhnen, die Signaturen in solchen Fällen zu lesen... ;-)

Kein Problem, dann weist Du ja trotzdem noch nicht, in welcher Reihenfolge die sind, wenn es drauf an kommt.

Device 3 und 4 sind ja unterschiedlich (Hauppauge Nova HD-S2, SkyStar HD2). Evtl. haben die unterschiedliche Eigenschaften, und VDR "verschont" die mit mehr Eigenschaften so lange es geht.
Laut Log können alle 4 Karten das Gleiche.

Der erste Test ist gerade fertig. das sieht schon mal gut aus, auch das Umschalten des Live-Kanales klappt dann so wie erwartet.

Log:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Mar 12 13:05:00 home-05 vdr: [24530] switching device 4 to channel 2
Mar 12 13:05:00 home-05 vdr: [24530] timer 84 (2 1305-1310 'Mittagsmagazin~mit Tagesschau') start
Mar 12 13:05:00 home-05 vdr: [24530] Title: 'Mittagsmagazin' Subtitle: 'mit Tagesschau'
Mar 12 13:05:00 home-05 vdr: [24530] record /video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.05.2-0.rec
Mar 12 13:05:00 home-05 vdr: [24530] creating directory /video/video0/Mittagsmagazin
Mar 12 13:05:00 home-05 vdr: [24530] creating directory /video/video0/Mittagsmagazin/mit_Tagesschau
Mar 12 13:05:00 home-05 vdr: [24530] creating directory /video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.05.2-0.rec
Mar 12 13:05:00 home-05 vdr: [24530] recording to '/video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.05.2-0.rec/00001.ts'
Mar 12 13:05:00 home-05 vdr: [24914] recording thread started (pid=24530, tid=24914, prio=high)
Mar 12 13:08:00 home-05 vdr: [24914] recording thread ended (pid=24530, tid=24914)
Mar 12 13:08:00 home-05 vdr: [24530] switching device 2 to channel 3
Mar 12 13:08:00 home-05 vdr: [24530] timer 85 (3 1308-1315 'Mittagsmagazin~mit Tagesschau') start
Mar 12 13:08:00 home-05 vdr: [24530] Title: 'Mittagsmagazin' Subtitle: 'mit Tagesschau'
Mar 12 13:08:00 home-05 vdr: [24530] record /video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.08.3-0.rec
Mar 12 13:08:00 home-05 vdr: [24530] creating directory /video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.08.3-0.rec
Mar 12 13:08:00 home-05 vdr: [24596] TS buffer on device 4 thread ended (pid=24530, tid=24596)
Mar 12 13:08:00 home-05 vdr: [24595] buffer stats: 183864 (1%) used
Mar 12 13:08:00 home-05 vdr: [24595] receiver on device 4 thread ended (pid=24530, tid=24595)
Mar 12 13:08:00 home-05 vdr: [24530] recording to '/video/video0/Mittagsmagazin/mit_Tagesschau/2013-03-12.13.08.3-0.rec/00001.ts'
Mar 12 13:08:01 home-05 vdr: [25021] recording thread started (pid=24530, tid=25021, prio=high)
Mar 12 13:08:01 home-05 vdr: [25022] receiver on device 2 thread started (pid=24530, tid=25022, prio=high)
Mar 12 13:08:01 home-05 vdr: [25023] TS buffer on device 2 thread started (pid=24530, tid=25023, prio=high)
Mar 12 13:08:02 home-05 vdr: [24530] switching to channel 3
Mar 12 13:08:02 home-05 vdr: [24530] buffer stats: 361900 (1%) used
Mar 12 13:08:02 home-05 vdr: [24530] timer 84 (2 1305-1310 'Mittagsmagazin~mit Tagesschau') stop
Mar 12 13:08:36 home-05 vdr: [24530] switching to channel 1
Mar 12 13:08:39 home-05 vdr: [24530] switching to channel 3
Mar 12 13:08:41 home-05 vdr: [24530] switching to channel 5
Mar 12 13:08:43 home-05 vdr: [24530] switching to channel 3


Am Ende dann nochmal ein paar Umschaltungen des Live-Kanales, das geht auch ohne Probleme.

OK, ich werde das die nächsten Tage noch intensiv testen und gebe dann eine Info dazu.

Gruß
kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

9

Dienstag, 12. März 2013, 17:59

Nach mehreren Tests habe ich jetzt doch noch einen Nebeneffekt bezüglich der letzten Änderung festgestellt:
Nur die hier:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
--- dvbdevice.c 2013/03/12 10:08:34     2.85
+++ dvbdevice.c 2013/03/12 11:43:29
@@ -1494,7 +1494,7 @@
                      }
                   }
               needsDetachBondedReceivers = true;
-              needsDetachReceivers = Receiving();
+              needsDetachReceivers = true;
               }
            }
         }


Wenn also jetzt keine Aufnahme läuft und ich einfach nur Kanalwechsel mache, dann wird ständig zwischen 2 Devices (hier 1 und 4) hin- und her gewechselt, das macht zumindest bei einer FF-Karte wenig Sinn (ständiger Wechsel zwischen Transfermode und Nichttransfermode).
Die Gegenprüfung ohne diese Änderung zeigt keinen Devicewechsel.

Log:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Mar 12 17:44:11 home-05 vdr: [14970] switching to channel 2
Mar 12 17:44:12 home-05 vdr: [15003] receiver on device 4 thread started (pid=14970, tid=15003, prio=high)
Mar 12 17:44:12 home-05 vdr: [15004] TS buffer on device 4 thread started (pid=14970, tid=15004, prio=high)
Mar 12 17:44:15 home-05 vdr: [14970] switching to channel 3
Mar 12 17:44:16 home-05 vdr: [15004] TS buffer on device 4 thread ended (pid=14970, tid=15004)
Mar 12 17:44:16 home-05 vdr: [15003] buffer stats: 183112 (3%) used
Mar 12 17:44:16 home-05 vdr: [15003] receiver on device 4 thread ended (pid=14970, tid=15003)
Mar 12 17:44:18 home-05 vdr: [14970] switching to channel 4
Mar 12 17:44:18 home-05 vdr: [15013] receiver on device 4 thread started (pid=14970, tid=15013, prio=high)
Mar 12 17:44:18 home-05 vdr: [15014] TS buffer on device 4 thread started (pid=14970, tid=15014, prio=high)
Mar 12 17:44:23 home-05 vdr: [14970] switching to channel 5
Mar 12 17:44:23 home-05 vdr: [15014] TS buffer on device 4 thread ended (pid=14970, tid=15014)
Mar 12 17:44:23 home-05 vdr: [15013] buffer stats: 197400 (3%) used
Mar 12 17:44:23 home-05 vdr: [15013] receiver on device 4 thread ended (pid=14970, tid=15013)
Mar 12 17:44:25 home-05 vdr: [14970] switching to channel 4
Mar 12 17:44:25 home-05 vdr: [15020] receiver on device 4 thread started (pid=14970, tid=15020, prio=high)
Mar 12 17:44:25 home-05 vdr: [15021] TS buffer on device 4 thread started (pid=14970, tid=15021, prio=high)
Mar 12 17:44:29 home-05 vdr: [14970] switching to channel 3
Mar 12 17:44:29 home-05 vdr: [15021] TS buffer on device 4 thread ended (pid=14970, tid=15021)
Mar 12 17:44:29 home-05 vdr: [15020] buffer stats: 197400 (3%) used
Mar 12 17:44:29 home-05 vdr: [15020] receiver on device 4 thread ended (pid=14970, tid=15020)
Mar 12 17:44:32 home-05 vdr: [14970] switching to channel 2
Mar 12 17:44:32 home-05 vdr: [15024] receiver on device 4 thread started (pid=14970, tid=15024, prio=high)
Mar 12 17:44:32 home-05 vdr: [15025] TS buffer on device 4 thread started (pid=14970, tid=15025, prio=high)
Mar 12 17:44:37 home-05 vdr: [14970] switching to channel 1
Mar 12 17:44:37 home-05 vdr: [15025] TS buffer on device 4 thread ended (pid=14970, tid=15025)
Mar 12 17:44:37 home-05 vdr: [15024] buffer stats: 181984 (3%) used
Mar 12 17:44:37 home-05 vdr: [15024] receiver on device 4 thread ended (pid=14970, tid=15024)


Gruß
kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

10

Mittwoch, 13. März 2013, 12:27

Nach mehreren Tests habe ich jetzt doch noch einen Nebeneffekt bezüglich der letzten Änderung festgestellt:
Nur die hier:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
--- dvbdevice.c 2013/03/12 10:08:34     2.85
+++ dvbdevice.c 2013/03/12 11:43:29
@@ -1494,7 +1494,7 @@
                      }
                   }
               needsDetachBondedReceivers = true;
-              needsDetachReceivers = Receiving();
+              needsDetachReceivers = true;
               }
            }
         }


Wenn also jetzt keine Aufnahme läuft und ich einfach nur Kanalwechsel mache, dann wird ständig zwischen 2 Devices (hier 1 und 4) hin- und her gewechselt, das macht zumindest bei einer FF-Karte wenig Sinn (ständiger Wechsel zwischen Transfermode und Nichttransfermode).
Die Gegenprüfung ohne diese Änderung zeigt keinen Devicewechsel.

Versuch es bitte stattdessen mal hiermit:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
--- dvbdevice.c 2013/03/12 10:08:34     2.85
+++ dvbdevice.c 2013/03/13 11:23:53
@@ -1485,6 +1485,7 @@
               needsDetachReceivers = Receiving();
            }
         if (result) {
+           cMutexLock MutexLock(&bondMutex);
            if (!BondingOk(Channel)) {
               // This device is bonded, so we need to check the priorities of the others:
               for (cDvbDevice *d = bondedDevice; d && d != this; d = d->bondedDevice) {
@@ -1492,9 +1493,10 @@
                      result = false;
                      break;
                      }
+                  needsDetachReceivers |= d->Receiving();
                   }
               needsDetachBondedReceivers = true;
-              needsDetachReceivers = Receiving();
+              needsDetachReceivers |= Receiving();
               }
            }
         }

Bei der Gelegenheit ist mir aufgefallen, daß da ja auch noch ein Lock auf bondMutex gefehlt hat.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

11

Mittwoch, 13. März 2013, 14:09

Versuch es bitte stattdessen mal hiermit:
Ein erster Schnelltest war positiv.

Ich teste dann später weiter.


kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

12

Sonntag, 24. März 2013, 16:23

@kls

Hallo,

ich will kurz hierzu nochmal eine Rückmeldung geben:
Bezüglich des oben besprochenen Problems konnte ich keine weiteren Auffälligkeiten feststellen.

Allerdings habe ich bei den Tests noch eine Ungereimtheit bei der Prioritätenauswertung festgestellt.

Folgendes zur Veranschaulichung: Aufnahme 1 und 3 sind gleichzeitig möglich, Aufnahme 2 nicht

Das Minus bedeutet Aufnahme, das x keine Aufnahme.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
Version 1:

Aufnahme 1: 14:25 - 14:40 Prio: 50                        B-----------------------E
Aufnahme 2: 14:20 - 14:30 Prio: 55              A---------xxxxxxxC
Aufnahme 3: 14:25 - 14:35 Prio: 60                        B---------------D

Version 2:

Aufnahme 1: 14:25 - 14:45 Prio: 50                        Bxxxxxxx-------------E
Aufnahme 2: 14:20 - 14:35 Prio: 55              A-------------xxxD
Aufnahme 3: 14:30 - 14:45 Prio: 60                            C----------------E


In der Version 1 werden Aufnahme 1 und 3 komplett aufgenommen, Aufnahme 2 wird zum Zeitpunkt B unterbrochen.
In der Version 2 wird die Aufnahme 2 zum Zeitpunkt C unterbrochen, das ist soweit OK. Aufnahme 1 wird aber nicht zum Zeitpunkt C aufgenommen, wie man es erwarten würde, sondern erst zum Zeitpunkt D.
Es scheint, das unter bestimmten Umständen nicht alle Aufnahmeprioritäten erneut hinsichtlich der Aufnahmefähigkeit geprüft werden.

Gruß
kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »kamel5« (24. März 2013, 17:31)


13

Sonntag, 24. März 2013, 17:02


Version 1:
Aufnahme 1: 14:25 - 14:40 Prio: 50 .......................B----------------------------E
Aufnahme 2: 14:20 - 14:30 Prio: 55 ............A---------xxxxxxxC
Aufnahme 3: 14:25 - 14:35 Prio: 60 .......................B-------------------D

Version 2:

Aufnahme 1: 14:25 - 14:45 Prio: 50 ......................Bxxxxxxx----------------E
Aufnahme 2: 14:20 - 14:35 Prio: 55 ...........A----------------xxxD
Aufnahme 3: 14:30 - 14:45 Prio: 60 .............................C---------------------E

Kann es sein, daß du das mit einem Proportionalfont geschrieben hast? Da ist die Ausrichtung immer Glückssache.
Kannst du es bitte in ein <code>...</code> Tag (mit eckigen statt spitzen Klammern) setzen, damit es auch wirklich so rüberkommt, wie du es meinst?

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

14

Sonntag, 24. März 2013, 17:30

OK, ich habe das oben mal versucht zu ändern. Leider geht in meinem Editor im Firefox keine Schrifteinstellung, woran das auch immer liegen könnte.

Ich hoffe, es ist jetzt zu lesen, sonst muß ich es nochmal irgendwie anders versuchen.


kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

15

Sonntag, 24. März 2013, 17:33

OK, ich habe das oben mal versucht zu ändern. Leider geht in meinem Editor im Firefox keine Schrifteinstellung, woran das auch immer liegen könnte.


Du kannst es in einem richtigen Texteditor (die haben ja Schrift mit fester Breite) schreiben und dann per C&P in das Quellcodefenster (im Tab von "Editor" auf "Quellcode" wechseln) packen. Dann passt das auf alle Fälle.

cu

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

16

Sonntag, 24. März 2013, 17:53

@Keine_Ahnung

OK, Danke.

So was in der Art hatte ich bei meinem letzten Versuch oben ja schon versucht. Ich kann es hier bei mir bloß nicht verifizieren, bei mir hier im Browser sah auch der erste Versuch schon gut aus.

Kann man es oben denn jetzt gut lesen, oder passt es immer noch nicht?

kamel5
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

17

Sonntag, 24. März 2013, 19:57


Kann man es oben denn jetzt gut lesen, oder passt es immer noch nicht?

Jetzt passt es.
Ich schau es mir morgen an.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

18

Montag, 25. März 2013, 11:59


Folgendes zur Veranschaulichung: Aufnahme 1 und 3 sind gleichzeitig möglich, Aufnahme 2 nicht

Das Minus bedeutet Aufnahme, das x keine Aufnahme.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
Version 1:

Aufnahme 1: 14:25 - 14:40 Prio: 50                        B-----------------------E
Aufnahme 2: 14:20 - 14:30 Prio: 55              A---------xxxxxxxC
Aufnahme 3: 14:25 - 14:35 Prio: 60                        B---------------D

Version 2:

Aufnahme 1: 14:25 - 14:45 Prio: 50                        Bxxxxxxx-------------E
Aufnahme 2: 14:20 - 14:35 Prio: 55              A-------------xxxD
Aufnahme 3: 14:30 - 14:45 Prio: 60                            C----------------E


In der Version 1 werden Aufnahme 1 und 3 komplett aufgenommen, Aufnahme 2 wird zum Zeitpunkt B unterbrochen.
In der Version 2 wird die Aufnahme 2 zum Zeitpunkt C unterbrochen, das ist soweit OK. Aufnahme 1 wird aber nicht zum Zeitpunkt C aufgenommen, wie man es erwarten würde, sondern erst zum Zeitpunkt D.
Es scheint, das unter bestimmten Umständen nicht alle Aufnahmeprioritäten erneut hinsichtlich der Aufnahmefähigkeit geprüft werden.

Ich vermute das Problem in cTimers::GetMatch(time_t t).
Vom Zeitpunkt C bis D sind sowohl Timer 1 als auch 2 "pending". Da Timer 2 eine höhere Priorität hat als Timer 1 wird hier immer Timer 2 ausgewählt.
Um das zu durchbrechen könnte folgende Änderung dienen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
--- timers.c    2013/03/16 10:37:10     2.17
+++ timers.c    2013/03/25 10:44:46
@@ -720,8 +720,10 @@
   for (cTimer *ti = First(); ti; ti = Next(ti)) {
       if (!ti->Recording() && ti->Matches(t)) {
          if (ti->Pending()) {
-            if (ti->Index() > LastPending)
+            if (ti->Index() > LastPending) {
                LastPending = ti->Index();
+               return ti;
+               }
             else
                continue;
             }

"Pending" bedeutet ja, daß der Timer eigentlich schon "dran" wäre, aber aus irgendwelchen Gründen (noch) nicht aufnehmen kann. Somit muß jeder "pending" Timer immer mal wieder zur Auswahl kommen, unabhängig von seiner Priorität.

Probier bitte obigen Patch mal mit deinen beiden Test-Szenarien aus.

Es wäre schön, wenn auch möglichst viele andere diesen Patch testen könnten bzw. einen Kommentar dazu abgeben würden, ob er irgendwelche negativen Seiteneffekte haben könnte. Abhängig davon würde ich entscheiden, ob das noch in die finale Version 2.0.0 mit reinkommt oder nicht.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

19

Montag, 25. März 2013, 12:10

Moin!

Der letzte Patch betrifft ja nicht nur Device-Bonding, oder?
Geht es ansonsten um die Patches aus Post 10 und 18?

Lars.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

20

Montag, 25. März 2013, 12:19

Moin!

Der letzte Patch betrifft ja nicht nur Device-Bonding, oder?

Richtig, diese Situation kann auch ohne Device-Bonding auftreten.

Zitat


Geht es ansonsten um die Patches aus Post 10 und 18?

Der aus Post 10 ist bereits seit Version 1.7.41 im Test.
Der Patch aus Post 18 ist der, um den es aktuell geht, und der unabhängig vom Device-Bonding ist.

Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

Immortal Romance Spielautomat