kein SKY SD Empfang

Zitat von motorsense

Merkwürdig ist, wenn man Kodi als Frontend benutzt, das Bild normal ankommt. Nur wenn man direkt über VDR schaut, entsteht das Stottern.

Ich schätze mal, daß Kodi nicht prüft, ob die TS-Pakete tatsächlich entschlüsselt wurden.
VDR macht das, um in Systemen mit mehreren CAMs (von denen jedes nur bestimmte Kanäle entschlüsseln kann) automatisch dasjenige zu finden, welches für den gewählten Kanal geeignet ist.
Der Fehler liegt nach meinen bisherigen Erkenntnissen in der CAM-Firmware, die die TS-Pakete von SD-Kanälen nicht als "entschlüsselt" kennzeichnet (warum auch immer).

Klaus

Wir haben das einfach so gelöst.

http://minidvblinux.de/git/?a=viewblob&p=vdr&h=44fcc36fd4d3c1460a6b059d3fe7578f5d7b3821&hb=e05c1f9fbd9d7c818e8e3b6d579fe666536238c9&f=src/46_vdr_scrambletime.patch

Wer Probleme hat setzt die Werte einfach gleich (z.b 5/5)

Edit: ihr müsst es natürlich manuell bei euch auflösen, der Patch ist nicht gegen den Orginal vdr core

Grüße
Christian

Inwiefern sollte denn das Gleichsetzen der beiden Werte das Problem mit dem Alphacrypt lösen?

Wenn TsIsScrambled(b) immer 'true' liefert, dann wird nur Setup.ScrambleTimeout benutzt und es ist vollkommen egal welchen Wert Setup.ScrambleLock hat.
Oder übersehe ich da was?

Klaus

Es geht auch 10/10, egal wie aber es ist zwingend nötig das das scrambleOK = true wird

Ich nehme an du meinst, daß DescramblingOk 'true' wird.
Ja, das ist mir schon klar. Nur sehe ich nicht, wie das durch Gleichsetzten der beiden Werte (egal ob 5/5, 10/10 oder 42/42) erreicht werden könnte.
Wenn TsIsScrambled(b) immer true liefert, dann ist der Wert von Setup.ScrambleLock völlig egal, weil er niemals benutzt wird.

Klaus

Das Phänomen ist ja das bei einem Alpha das Bild nach genau den x Sekunden des Timeouts verschwindet und kein ok bekommt.
Eine saubere Lösung ist dies sicherlich nicht aber dadurch erzwingen wir das das ok vorm timeout kommt und nicht detached.

Ich hoffe das ich es so richtig verstehe

Gehen wir doch mal die Codesequenz Zeile für Zeile durch:

if (TsIsScrambled(b)) {
                          if (t > TS_SCRAMBLING_TIMEOUT)
                             DetachReceivers = true;
                          }
                       else if (t > TS_SCRAMBLING_TIME_OK) {
                          DescramblingOk = true;
                          startScrambleDetection = 0;
                          }

Die Zeilen 2 und 5 sind die einzigen Stellen, an denen TS_SCRAMBLING_TIMEOUT und TS_SCRAMBLING_TIME_OK (bzw. Setup.ScrambleTimeout und Setup.ScrambleLock, was aber für die Betrachtung keine Rolle spielt, dadurch habt ihr die Werte lediglich vom Benutzer einstellbar gemacht) benutzt werden.
In Zeile 1 wird mit TsIsScrambled(b) abgefragt, ob das gerade bearbeitete TS-Paket verschlüsselt ist. Da das besagte Alphacrypt (nach bisherigen Erkenntnissen) bei SD-Kanälen die "scrambling control" Bits der TS-Pakete nicht, wie im Standard vorgeschrieben, zurücksetzt, wenn es die Pakete entschlüsseln konnte, liefert TsIsScrambled(b) hierfür immer 'true' zurück. Der 'else'-Zweig dieses Statements (ab Zeile 5) wird also niemals ausgeführt, und damit kann Zeile 6 niemals DescramblingOk auf 'true' setzen.

Daß das Bild nach ein paar Sekunden verschwindet liegt daran, daß VDR glaubt (wg. TsIsScrambled(b) == true), daß das CAM den Kanal nicht entschlüsseln kann. Daher schaltet er (falls vorhanden) auf ein anderes CAM um und versucht dort sein Glück. Was ich machen könnte wäre, dieses Durchprobieren der CAMs zu unterbinden, wenn es nur ein einziges CAM im System gibt. Das wäre zwar zum einen sowieso sinnvoll (und werde ich auch machen), zum anderen für dieses Problem aber nur dann eine Abhilfe, wenn es nur dieses eine CAM im System gibt.

Klaus

Klingt logisch und wenn man die if else abfrage betrachtet auch nachvollziehbar, aber warum funktioniert es den wenn man die Zeit von TS_SCRAMBLING_TIME_OK < TS_SCAMBLING_TIMEOUT setzt? Bin verwirrt

Ich kann mir höchstens vorstellen, daß ab und zu doch mal ein Paket kommt, bei dem die "scramble control" Bits zurückgesetzt sind, und dadurch bei TS_SCRAMBLING_TIME_OK < TS_SCRAMBLING_TIMEOUT ein "Zufallstreffer" entsteht. Eine allgemeine Lösung ist das aber nicht.

Klaus

Ich habe jetzt mal etwas experimentiert und den weiter oben genannten Patch wieder rausgenommen.

Dann habe ich ich im CAM Menü, die "dbox Kompatibilität" eingeschaltet,

[Blockierte Grafik: http://imagizer.imageshack.us/v2/280x200q90/922/t9WpGk.png]

Und siehe da, es wurde hell auf Sky HD.

Ob das irgendwelche Nebeneffekte mit sich zieht, kann ich leider nicht sagen, aber Sky läuft damit Fehlerfrei, sowohl SD, als auch HD.

Zitat von PaulPanther

Wir haben das einfach so gelöst.

http://minidvblinux.de/git/?a=viewblob&p=vdr&h=44fcc36fd4d3c1460a6b059d3fe7578f5d7b3821&hb=e05c1f9fbd9d7c818e8e3b6d579fe666536238c9&f=src/46_vdr_scrambletime.patch

Wer Probleme hat setzt die Werte einfach gleich (z.b 5/5)

Alles anzeigen

Danke, klappt sogar ohne die Werte zu ändern.

Gruß

Oli