You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Monday, March 11th 2013, 1:33pm

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.

Source code

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

2

Monday, March 11th 2013, 3:02pm

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

Source code

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

3

Monday, March 11th 2013, 3:49pm

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.

Source code

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

4

Tuesday, March 12th 2013, 12:01pm

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.

Quoted


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

5

Tuesday, March 12th 2013, 12:45pm

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

6

Tuesday, March 12th 2013, 12:47pm


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

Source code

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

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

7

Tuesday, March 12th 2013, 12:51pm

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.

Quoted


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

8

Tuesday, March 12th 2013, 1:18pm

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:

Source code

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

9

Tuesday, March 12th 2013, 5:59pm

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

Source code

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:

Source code

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

10

Wednesday, March 13th 2013, 12:27pm

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

Source code

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:

Source code

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

11

Wednesday, March 13th 2013, 2:09pm

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

Ich teste dann später weiter.


kamel5
VDR 2.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

12

Sunday, March 24th 2013, 4:23pm

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

Source code

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

This post has been edited 2 times, last edit by "kamel5" (Mar 24th 2013, 5:31pm)


kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

13

Sunday, March 24th 2013, 5:02pm


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

14

Sunday, March 24th 2013, 5:30pm

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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

15

Sunday, March 24th 2013, 5:33pm

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

Sunday, March 24th 2013, 5:53pm

@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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.15.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

17

Sunday, March 24th 2013, 7:57pm


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

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

18

Monday, March 25th 2013, 11:59am


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

Das Minus bedeutet Aufnahme, das x keine Aufnahme.

Source code

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:

Source code

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

mini73

Moderator

Posts: 5,531

Location: Flensburg

  • Send private message

19

Monday, March 25th 2013, 12:10pm

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

kls

Master

Posts: 2,667

Location: Mettenheim

  • Send private message

20

Monday, March 25th 2013, 12:19pm

Moin!

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

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

Quoted


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