jocke Posted December 31, 2013 Share Posted December 31, 2013 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 Link to comment
Derrick Posted December 31, 2013 Share Posted December 31, 2013 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.. Link to comment
jocke Posted December 31, 2013 Author Share Posted December 31, 2013 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. Link to comment
Derrick Posted December 31, 2013 Share Posted December 31, 2013 Hast du auch wieder recht. Dann fällt mir auch nichts ein.. Link to comment
Griga Posted January 1, 2014 Share Posted January 1, 2014 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)? Link to comment
shaupti Posted January 1, 2014 Share Posted January 1, 2014 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. Link to comment
Griga Posted January 1, 2014 Share Posted January 1, 2014 Auch nur mit verschlüsselten Sendern? Mit unverschlüsselten kann ich es nicht nachvollziehen. Link to comment
jocke Posted January 1, 2014 Author Share Posted January 1, 2014 (edited) 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 Link to comment
Derrick Posted January 1, 2014 Share Posted January 1, 2014 ..scheint eine harte nuss zu sein, wenn sich das immer reproduzieren lässt. Hast du mal die CI-module getauscht? Link to comment
jocke Posted January 1, 2014 Author Share Posted January 1, 2014 (edited) 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 Link to comment
Derrick Posted January 1, 2014 Share Posted January 1, 2014 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.2014F:\DVBViewer\2014-01-01_12-03-02_NED1_NED1.tsDevice: FireDTV BDA Tuner DVBS2 (1)12:03:02 / 00:00:00 (~ 0,00 MB) Start12:03:05 / 00:00:03 (~ 0,63 MB) PID 517: MPEG2 Video, 16:9, 704x576, 25 fps12:03:05 / 00:00:03 (~ 0,63 MB) PID 88: MPEG Audio Stereo, 48 khz, 192 kbps12:05:01 / 00:01:58 (~ 53,18 MB) StopAverage Data Rate: 0,447 MB/sTotal Size: 53,2 MB (55766440 Bytes)Removed Filler Data: 0,8 MB (1,7%) NED1 01.01.2014F:\DVBViewer\2014-01-01_12-04-00_NED1_NED1.tsDevice: FireDTV BDA Tuner DVBS2 (1)12:04:00 / 00:00:00 (~ 0,00 MB) Start12:04:01 / 00:00:00 (~ 0,50 MB) PID 517: MPEG2 Video, 16:9, 704x576, 25 fps12:04:01 / 00:00:00 (~ 0,50 MB) PID 88: MPEG Audio Stereo, 48 khz, 192 kbps12:06:00 / 00:01:59 (~ 51,12 MB) StopAverage Data Rate: 0,426 MB/sTotal Size: 51,1 MB (53605004 Bytes)Removed Filler Data: 0,6 MB (1,5%) Link to comment
Griga Posted January 1, 2014 Share Posted January 1, 2014 Hmm, es könnte an dieser Änderung liegen DVBViewer Pro 5.2.9Fix: 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... Link to comment
jocke Posted January 1, 2014 Author Share Posted January 1, 2014 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. Link to comment
Griga Posted January 1, 2014 Share Posted January 1, 2014 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... Link to comment
shaupti Posted January 1, 2014 Share Posted January 1, 2014 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. Link to comment
Derrick Posted January 1, 2014 Share Posted January 1, 2014 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 Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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.. Link to comment
jocke Posted January 2, 2014 Author Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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!? Link to comment
Derrick Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 ..genau! DD übernimmt mit dem treiber die verantwortlichkeit. Dort muss der fehler ausgebügelt werden und nicht durch kunstgriffe im DVBViewer. Spiel bitte woanders... Link to comment
jocke Posted January 2, 2014 Author Share Posted January 2, 2014 (edited) 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 Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
jocke Posted January 2, 2014 Author Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
Derrick Posted January 2, 2014 Share Posted January 2, 2014 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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 ..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. Link to comment
CiNcH Posted January 2, 2014 Share Posted January 2, 2014 (edited) ..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 Link to comment
Griga Posted January 3, 2014 Share Posted January 3, 2014 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... Link to comment
markymark Posted January 21, 2014 Share Posted January 21, 2014 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 Link to comment
shaupti Posted January 21, 2014 Share Posted January 21, 2014 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 - . Link to comment
Recommended Posts