Aufnahmeprobleme nach Update von RS1.27 auf RS1.28

[jocke]

Hallo,

 

nach dem Update vom Recordingservice 1.27 auf die aktuelle 1.28 stellen sich bei mir, bei sich überschneidenden Aufnahmen auf dem selben Sender, Errors in der bereits laufenden Aufnahme ein. Dies geschieht nur bei verschlüsselten Sendern, getestet habe ich das mit einer sehr alten S01 (ja ich hab wirklich noch eine aus der alten Premiere-Dbox1 ;-) ) im Alphacrypt light und einer V14 in einem Deltacam. Beide Cam's hängen an Digital Devices Hardware. Wenn ich den Recordingservice wieder auf die Version 1.27 downgrade ist das Problem verschwunden.

 

Heute habe ich mich mal hingesetzt und je ein support.zip erstellt nachdem ich mit den verschiedenen Versionen je einmal diese Situation nachgestellt habe.

 

Beispielhaft hier einmal die beiden log-dateien der Aufnahmen unter 1.28. Als die 2. Aufnahme auf dem selben Sender startet, werden auf der bereits laufenden Aufnahme Errors erzeugt. Diese sind dann nachher auch in der Aufnahme sichtbar (meisstens durch stocken des Bildes)

Syfy HD (deu) 31.12.2013

\\HD-RECORDER\Aufnahmen_F\Filme\True Blood\Syfy HD (deu)\True Blood - Spiel mit dem Feuer_08.ts

Device: Digital Devices DVB-S/S2 Tuner 1 (1)

13:54:57 / 00:00:00 (~ 0,00 MB) Start
13:55:06 / 00:00:08 (~ 0,47 MB) PID 515: AC3 Audio 5.1, 48 khz, 384 kbps
13:55:06 / 00:00:08 (~ 0,47 MB) PID 516: AC3 Audio Stereo, 48 khz, 384 kbps
13:55:07 / 00:00:09 (~ 1,49 MB) PID 511: H.264 Video, 16:9, 1920x1088, 25 fps
13:56:01 / 00:01:03 (~ 48,35 MB) Errors: 3
13:56:12 / 00:01:15 (~ 57,14 MB) Stop

Average Data Rate: 0,761 MB/s
Total Size: 57,1 MB (59912216 Bytes)
Removed Filler Data: 0,4 MB (0,8%)

Syfy HD (deu) 31.12.2013

\\HD-RECORDER\Aufnahmen_F\Filme\True Blood\Syfy HD (deu)\True Blood - Spiel mit dem Feuer_09.ts

Device: Digital Devices DVB-S/S2 Tuner 1 (1)

13:56:00 / 00:00:00 (~ 0,00 MB) Start
13:56:01 / 00:00:00 (~ 0,59 MB) PID 511: H.264 Video, 16:9, 1920x1088, 25 fps
13:56:01 / 00:00:00 (~ 0,59 MB) PID 515: AC3 Audio 5.1, 48 khz, 384 kbps
13:56:01 / 00:00:00 (~ 0,59 MB) PID 516: AC3 Audio Stereo, 48 khz, 384 kbps
13:56:13 / 00:00:13 (~ 10,16 MB) Stop

Average Data Rate: 0,752 MB/s
Total Size: 10,2 MB (10654148 Bytes)
Removed Filler Data: 0,2 MB (2,0%)

support_128.zip

support_127.zip

 

Ich habe mir die in den support-dateien enthaltenen svcdebug.log's mal angeschaut, sehe dort aber keinen unterschied zwischen den Aufnahmen des RS1.27 und 1.28 die einen Hinweis auf diese Störungen geben würden.

 

Ich bin vorerst wieder auf die Version 1.27 zurück gegangen...

 

Gruß,

Rainer

 

[Derrick]

Normalerweise würde ich hinter solchen kurzen störungen eine gegenseitige beeinflussung der tuner z.b. durch diseqc-befehle vermuten. Aber so viele tuner hängen sicher hinter einem multiswitch und ausserdem hätte die RS-version kaum einen einfluss.

 

In der 1.28 gibt es änderungen beim RTSP. Du könntest mal versuchen, ob bei den virtuellen RTSP devices im DVBViewer-client eine änderung auf TCP statt UDP einen einfluss hat. Auch kannst du es mit unicast devices probieren..

[jocke]

Momentan laufen wieder ein paar Aufnahmen. Werde ich später probieren.

 

Aber der DVBViewer ist eigentlich außen vor, das Problem besteht bereits wenn der RS nur Aufnahmen tätigt, also ohne das der DVBViewer läuft und daher auch keine RTSP-Verbindung besteht.

[Derrick]

Hast du auch wieder recht. Dann fällt mir auch nichts ein..

[Griga]

Ist das Problem tatsächlich auf zwei sich überschneidende Aufnahmen des selben Senders beschränkt, oder passiert es auch bei zwei Aufnahmen verschiedener Sender vom selben Transponder (der selben Frequenz)?

[shaupti]

Habe das selbe Problem. Es ist nur bei Überschneidungen auf dem selben Sender.

Und das, wenn die neue Aufnahme startet gibt es in der alten Fehler, für ein paar milli Sekunden.

Ist aber leider im Bild zu sehen.

[Griga]

Auch nur mit verschlüsselten Sendern? Mit unverschlüsselten kann ich es nicht nachvollziehen.

[jocke]

Hallo Girga,

 

ja, das passiert nur mit verschlüsselten Sendern. Und wie shaupti schon schrieb nur wenn die folgende Aufnahme auf dem selben Sender, üblicherweise durch vor- und Nachlauf bedingt sich überschneiden.

 

hmm, das mit der selben Frequenz teste ich gleich nochmal...

Edited January 1, 2014 by jocke

[Derrick]

..scheint eine harte nuss zu sein, wenn sich das immer reproduzieren lässt. Hast du mal die CI-module getauscht?

[jocke]

soooo, test auf der selben Frequenz abgeschlossen.

 

Da es sich um einen verschlüsselten Sender handelt nimmt der RS einen weiteren Tuner für die Aufnahme eines anderen Senders auf der selben Frequenz.

In diesem Fall entstehen keine Störungen in der bereits laufenden Aufnahme.

 

@Derrick: Ja, ein Tausch der CAM's in den CI-Module hat keinen Einfluss, der Fehler entsteht mit beiden Modulen/Karten egal in welchem CI das CAM steckt. Die CI-Module an sich habe ich jetzt noch nicht gegeneinander getauscht, es sind aber beides Digital Devices Flex CI. Das eine hängt an einer CineS2 V5.5 und das andere an einer CineS2 V6 zusammen mit einer Duoflex S2.

Edited January 1, 2014 by jocke

[Derrick]

Mit CI-modul meinte ich das "CAM", denn das ist die offizielle bezeichnung

 

..egal, wenn nur eine tv-karte/modul/cam/smart_card beteiligt ist, müsste ich das im prinzip auch nachvollziehen können. Ist aber alles paletti bei 2 kurzen, überlappenden aufnahmen von NED1. Hardware: Firedtv-S2, AlphaCrypt classic. Zum glück habe ich keine hardware von DD

 

 

NED1 01.01.2014

F:\DVBViewer\2014-01-01_12-03-02_NED1_NED1.ts

Device: FireDTV BDA Tuner DVBS2 (1)

12:03:02 / 00:00:00 (~ 0,00 MB) Start
12:03:05 / 00:00:03 (~ 0,63 MB) PID 517: MPEG2 Video, 16:9, 704x576, 25 fps
12:03:05 / 00:00:03 (~ 0,63 MB) PID 88: MPEG Audio Stereo, 48 khz, 192 kbps
12:05:01 / 00:01:58 (~ 53,18 MB) Stop

Average Data Rate: 0,447 MB/s
Total Size: 53,2 MB (55766440 Bytes)
Removed Filler Data: 0,8 MB (1,7%)

 

NED1 01.01.2014

F:\DVBViewer\2014-01-01_12-04-00_NED1_NED1.ts

Device: FireDTV BDA Tuner DVBS2 (1)

12:04:00 / 00:00:00 (~ 0,00 MB) Start
12:04:01 / 00:00:00 (~ 0,50 MB) PID 517: MPEG2 Video, 16:9, 704x576, 25 fps
12:04:01 / 00:00:00 (~ 0,50 MB) PID 88: MPEG Audio Stereo, 48 khz, 192 kbps
12:06:00 / 00:01:59 (~ 51,12 MB) Stop

Average Data Rate: 0,426 MB/s
Total Size: 51,1 MB (53605004 Bytes)
Removed Filler Data: 0,6 MB (1,5%)

[Griga]

Hmm, es könnte an dieser Änderung liegen

 

DVBViewer Pro 5.2.9

Fix: CI/CAM: Eine dynamische Senderdaten-Änderungen bei verschlüsselten Sendern funktionierte nicht mit Karten von Digital Devices.

 

die natürlich auch in den RS 1.28 eingeflossen ist, auch wenn wir sie dort im ChangeLog vergessen haben. Der Fix wurde anlässlich eines Reports von CiNcH durchgeführt, der Probleme bei der Regionalumschaltung von ORF 2 mit DD-Karten entdeckt hatte. Da er sich mit dem CI/CAM-Kram gut auskennt, werde ich ihn um eine Beurteilung des Falles bitten...

[jocke]

hmmm, kann diese Senderdaten-Änderung evtl. auch etwas mit dem Verhalten des RS, welches ich am 2. März 2013 beschrieben hatte zu tun haben?

Da ging es darum das, falls vor der Aufnahme eine Sendung mit weniger Audiospuren lief, und in der Vorlaufzeit eine zusätzliche Tonspur hinzukommt, diese nicht aufgenommen wird.

Das passiert mir regelmäßig bei Aufnahmen um 20:15Uhr wenn auf Sky Cinema vor dem Film Zapping läuft. Bei Zapping ist nur eine Tonspur vorhanden, bei Filmbeginn wird dann die zusätzliche (englisch) hinzugeschaltet, was der RS bei der Aufnahme ignoriert. Ich gehe inzwischen so vor das ich die Vorlaufzeit so hoch setze das der RS bereits bei dem zuvor laufenden Film mit der Aufnahme beginnt wo die zusätzliche Tonspur noch vorhanden ist. In diesem Fall nimmt der RS dann die eigentlich aufzunehmende Sendung mit allen Tonspuren auf. Dieses Verhalten konnte ich bisher mangels mehrsprachiger Sendungen auch nur auf verschlüsselten Sendern feststellen, unter anderem auch auf Syfy wenn dort vorher eine Serie mit entsprechend nur einer Tonspur lief.

[Griga]

hmmm, kann diese Senderdaten-Änderung evtl. auch etwas mit dem Verhalten des RS, welches ich am 2. März 2013 beschrieben hatte zu tun haben?

 

Könnte. Wenn der DD-Treiber nicht mitbekommt, dass eine verschlüsselte Audiospur hinzugekommen ist und sie deshalb nicht entschlüsselt, dann nimmt sie der RS auch nicht auf. Das müsste mit dem o.a. Fix jetzt allerdings anders sein.

 

Das Problem bei der Sache ist, einen erneuten Zugriff auf den selben Sender von einer dynamischen Senderdaten-Änderung zu unterscheiden. Auf der Ebene, wo die Entschlüsselung durch den DD-Treiber angestoßen wird, sind die beiden Vorgänge nicht zu unterscheiden. Ich nehme an, dass der Vorgang Diskontinuitäten erzeugt, daher das in diesem Thema geschilderte Problem. Aber erst mal abwarten, was CiNcH dazu meint...

[shaupti]

Noch ein kleines Problemchen, was damit zusammenhängen könnte.

 

Passiert nur auf dem Sender boomerang bzw Junior liegen ja beide auf dem selben transponder.

 

So Aufnahme läuft..... Alles super. Aufnahme wird beendet.

Beim starten der nächsten Aufnahme auf dem selben tuner, egal welcher bei mehreren, wird die Aufnahme nicht mehr entschlüsselt.

 

Kann reproduziert werden indem im DVBViewer der Sender gestartet und wieder beendet wird, durch schließe Graph, und danach wieder gestartet.

 

Passiert nicht immer aber zu 70 Prozent.

[Derrick]

 

Passiert nur auf dem Sender boomerang bzw Junior liegen ja beide auf dem selben transponder.

Welcher transponder soll das denn sein?

 

Bitte nicht mehrere probleme durcheinander bringen. Nimm dir ein beispiel an @jocke, der seinen fall vorbildlich beschrieben und dokumentiert hat und damit offensichtlich einen DD-bug blossgelegt hat. Meine 1. antwort hat leider nicht gepasst, weil ich wohl zu oberflächlich gelesen hatte

[CiNcH]

Das erneute Setzen desselben verschlüsselten Kanals veranlasst den RS dazu die SID beim DD-Treiber zu 0 und anschließend zum ursprünglichen Wert zu setzen. Das wiederum veranlasst den DD-Treiber dazu die CA_PMT neu an das CAM zu schicken. Das kann natürlich zu einem kurzen Aussetzer in der Entschlüsselung im CAM führen, bzw. wird das in den meisten Fällen mit den meisten CAMs wohl auch tun. Mit dem DeltaCam jedoch nicht. Da werden die CA_PMTs verglichen. Nur wenn sich die ECM-PIDs ändern, wird die Entschlüsselung kurz gestoppt, bzw. der Kanal neu aufgesetzt. Sich ändernde A/V PIDs werden im Descrambler unterbruchsfrei hinzugefügt/entfernt. Ändert sich in der CA_PMT gar nichts (wie in diesem Fall), macht das DeltaCam auch nichts.

 

@jocke,

 

welche FW hast du auf dem DeltaCam? Der Vergleich der CA_PMT wurde mit FW Version 1.25 eingeführt. Danach sollte es eigentlich zu keinem Unterbruch mehr kommen.

 

 

Vom Design her ist das etwas unglücklich. Man sollte die Situation evtl. bereits weiter oben handeln und es nicht dem CAM überlassen..

[jocke]

Hi CiNcH,

 

ich habe auf dem DeltaCam

Was ich bei deiner Erklärung aber nicht verstehe ist das der Fehler erst ab der RS V1.28, mit beiden CAM, Alacrypt light mit S01 und DeltaCam mit V14, auftritt.

Mit der RS V1.27 läuft das alles geschmeidig, bis auf das Problem mit der nicht erkannten zusätzlichen Audiospur wenn bei Aufnahmebeginn nur eine Audiospur vorhanden war.

[CiNcH]

 

Was ich bei deiner Erklärung aber nicht verstehe ist das der Fehler erst ab der RS V1.28, mit beiden CAM, Alacrypt light mit S01 und DeltaCam mit V14, auftritt.

 

Weil da folgendes eingebaut wurde:

 

 

Das erneute Setzen desselben verschlüsselten Kanals veranlasst den RS dazu die SID beim DD-Treiber zu 0 und anschließend zum ursprünglichen Wert zu setzen.

 

 

Allerdings muss ich das wohl untersuchen, weil es eigentlich mit DeltaCam FW 1.27 nicht zu diesem Problem kommen sollte.

[CiNcH]

 

Allerdings muss ich das wohl untersuchen, weil es eigentlich mit DeltaCam FW 1.27 nicht zu diesem Problem kommen sollte.

 

Setzt du AlphaCrypt und DeltaCam zusammen in einer Kaskade ein? Entferne das AlphaCrypt mal und probiere es dann erneut mit nur dem DeltaCam. Ich habe aber keine Ahnung wieso man S01 und V14 kombinieren sollte!?

[Derrick]

 

Vom Design her ist das etwas unglücklich. Man sollte die Situation evtl. bereits weiter oben handeln und es nicht dem CAM überlassen..

..genau! DD übernimmt mit dem treiber die verantwortlichkeit. Dort muss der fehler ausgebügelt werden und nicht durch kunstgriffe im DVBViewer.

[CiNcH]

 

..genau! DD übernimmt mit dem treiber die verantwortlichkeit. Dort muss der fehler ausgebügelt werden und nicht durch kunstgriffe im DVBViewer.

 

Spiel bitte woanders...

[jocke]

Cascade? hmm, ich glaube nicht...

ich habe 2 CI. Das erste mit der V14 im Deltacam hängt zusätzlich zu einer Duoflex an einer CineS2 V6 und ist diesen 4 Tunern zugeordnet.

Das 2. CI mit S01 im Alphacrypt light hängt an einer CineS2 V5.5 und ist nur diesen Tunern zugeordnet.

 

Die geschichte mit der Kombination ist daraus entstanden das ich mit dem Alpacrypt bei > 3 gleichzeitiger Aufnahmen immer mit fehlenden Audiospuren zu kämpfen hatte. Mit dem Deltacam habe ich diese Probleme nicht mehr, und weil ich die Hardware halt hier liegen hatte und die möglichkeit ausreichender separater Sat-Anschlüsse an RS standort, habe ich das Alphacrypt zusätzlich eingebaut und habe somit die Möglichkeit von bis zu 6 gleichzeitigen Aufnahmen.

Edited January 2, 2014 by jocke

[CiNcH]

 

Das erneute Setzen desselben verschlüsselten Kanals veranlasst den RS dazu die SID beim DD-Treiber zu 0 und anschließend zum ursprünglichen Wert zu setzen.

 

Hmmm. Da fällt mir ein, dass der DD-Treiber dann wahrscheinlich die PIDs ummappt (der Treiber bzw. Remuxer zählt bei jedem "Umschaltvorgang" die PIDs hoch) und somit eine komplett andere CA_PMT schickt, was dann im CAM zwangsweise zu einem Retuning führt. Mit anderen Worten, man kann diese Situation nur in höheren Schichten auflösen.

[CiNcH]

OK, überprüft, meine Annahmen haben sich bestätigt.

 

- ORF 1 HD im DVBViewer gesetzt (VPID in der CA_PMT im CAM nach dem Remuxer: 0x279)

- Instant Recording gestartet

- > SID 0 > SID XXX (Treiber schickt neue CA_PMT)

- kurzer Aussetzer in der Live-Wiedergabe

- VPID in der CA_PMT im CAM ist nun 0x289

 

Der DD-Treiber hat also die PIDs umgemappt. Der Kanal wird nach dem Setzen der neuen CA_PMT im CAM komplett neu aufgesetzt, was zu diesem Aussetzer führt. Also entweder darf der DVBViewer die SID nicht absetzen oder der DD-Treiber muss das Remuxing mit anschließendem Erneuern der CA_PMT unterlassen.

[jocke]

ok, ich hab das jetzt einmal mit gezogenem Alphacrypt und im DD-Config-Tool die zuordnung des CI mit dem Alphacrypt zu den Tunern deaktiviert getestet.

Jetzt ist also nur noch das Deltacam im System vorhanden aber die Errors bleiben beim hinzufügen einer Aufnahme.

[CiNcH]

 

Jetzt ist also nur noch das Deltacam im System vorhanden aber die Errors bleiben beim hinzufügen einer Aufnahme.

 

Ja, die Situation ist jetzt klar, siehe vorige Seite.

[Derrick]

 

Mit anderen Worten, man kann diese Situation nur in höheren Schichten auflösen.

..etwas genauer bitte. Die TV-applikation sprich DVBViewer hat keinen schimmer von MTD und dem remapping. Der ball liegt bei DD und sonst nirgends was die überwachung auf PMT-versionsänderungen betrifft.

[CiNcH]

 

..etwas genauer bitte. Die TV-applikation sprich DVBViewer hat keinen schimmer von MTD und dem remapping. Der ball liegt bei DD und sonst nirgends was die überwachung auf PMT-versionsänderungen betrifft.

 

Wenn der DVBViewer/RS in diesem Fall die SID nicht erneut absetzt, passiert nichts.

[CiNcH]

 

..und werden auch keine später hinzukommende audiostreams aufgenommen.

 

Das wäre ein weiterer Mechanismus, der nach wie vor greifen würde (siehe ORF Problem bei Regionalprogrammen)... Ändert sich die PMT, wird die SID neu gesetzt und somit eine neue CA_PMT generiert. Unterbruchsfrei ist dieser Vorgang mit DD halt dann leider nicht, weil sämtliche PIDs neu gemappt werden und somit ein Retune im CAM stattfindet.

Edited January 3, 2014 by Griga

[Griga]

Nicht sachdienliche Off-Topic-Beiträge habe ich gelöscht.

 

Ein möglicher (und relativ einfacher) Work-Around wäre, die Service ID nur dann erneut an den DD-Treiber abzusetzen (mit vorausgeschickter SID 0), wenn sich die Video PID ändert, weil dies ein sicherer Hinweis auf eine dynamische PMT-Umschaltung ist (es sei denn, Sender Auto-Update schlägt zu, weil die Video PID in der Senderliste falsch ist).

 

Ein einfaches erneutes Einstellen des Senders würde damit kein Neuaufsetzen im CAM mit resultierenden Diskontinuitäten auslösen. Eine dynamische Zuschaltung von Audiospuren bliebe allerdings auch außen vor Für eine umfassende Lösung müsste irgendeine Instanz ständig die PMT im Auge behalten.

 

Wie auch immer - ich habe Digital Devices noch mal auf die Problematik aufmerksam gemacht...

[markymark]

Nicht sachdienliche Off-Topic-Beiträge habe ich gelöscht.

 

Ein möglicher (und relativ einfacher) Work-Around wäre, die Service ID nur dann erneut an den DD-Treiber abzusetzen (mit vorausgeschickter SID 0), wenn sich die Video PID ändert, weil dies ein sicherer Hinweis auf eine dynamische PMT-Umschaltung ist (es sei denn, Sender Auto-Update schlägt zu, weil die Video PID in der Senderliste falsch ist).

 

Ein einfaches erneutes Einstellen des Senders würde damit kein Neuaufsetzen im CAM mit resultierenden Diskontinuitäten auslösen. Eine dynamische Zuschaltung von Audiospuren bliebe allerdings auch außen vor Für eine umfassende Lösung müsste irgendeine Instanz ständig die PMT im Auge behalten.

 

Wie auch immer - ich habe Digital Devices noch mal auf die Problematik aufmerksam gemacht...

 

Wäre aber toll, wenn zeitnah sich ein Workaround findet!

 

Leider trifft es mich praktisch täglich

[shaupti]

Auf eine alte Version zurück gehen. Seit dem läuft alles zumindest bei mir für meine Zwecke fast perfekt - nur das Manko mit den wieder hohlen den timern ist ein anderes Thema - .