ghost0815
DEB König
- Registriert
- 17. Juni 2012
- Beiträge
- 6.113
- Lösungen
- 11
- Reaktionspunkte
- 8.832
- Punkte
- 3.030
Digital Eliteboard - Das Digitale Technik Forum
Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
Moin.
Jetzt mal ne ganz blöde Frage:
Ich habe die TivuSat Sache seit langer Zeit lokal via newcamd/oscam-oscam am laufen. Alles was ich bisher gelesen hatte bezieht sich immer auf einen lokalen reader IN der Box. Ich habe allerdings einen dedizierten ARM-Server, nur mit Smartmäusen und auf dem sind die entsprechenden configs+cards. Das G-EMM Set wird auch korrekt initialisiert samt einer "SilverCard" (nutzt den anderen RSA-Key, als den der "Gold-Card"). Jedenfalls wird das "Tiger G-EMM" Key-Set im logfile als OK und "enabled" geloggt....
Aber... die EMM Daten selber kommen vom client mit gleicher oscam-version (die ebenfalls den Tivusat-patch enthält....) - Nur kommen ueber newcamd da keine "Fragmente" am eigentlichen Server an, aus denen dann dort, wo die Karte sich auch befindet, lokal ein G-EMM zusammengeschraubt wird. Offenbar geht das mit DVBAPI + lokaler Karte wohl nur im selben Gerät ?
Das Key-Set auf der client-Box und anstelle von lokalem Cardslot und eine newcamd Zeile als "reader" für den Remote-Server bringt natürlich auch nichts, da diese config mit "Remote-Update" nicht unterstützt wird. Die Option "localcard =" für einen RemoteReader zu verwenden führt auch zu keinen "eingehenden Fragmenten" am Remote-Cardserver.
Mache ich da gerade einen Denkfehler, weil ich immer noch newcamd zwischen Client+Server verwende, oder brauche ich schlichtweg einfach nur ein anderes Protokoll, z.b. Radegast, scam oder oscam-cccam, damit von der Clientbox da mehr EMM-Daten auch am Server mal ankommen ?
Für mich siehts es so aus, als ob die client-box das einfach wegfiltert und nur "standard EMM-G/S/U" ueber das Remote-Proto überträgt ?
Jetzt mal ne ganz blöde Frage:
Ich habe die TivuSat Sache seit langer Zeit lokal via newcamd/oscam-oscam am laufen. Alles was ich bisher gelesen hatte bezieht sich immer auf einen lokalen reader IN der Box. Ich habe allerdings einen dedizierten ARM-Server, nur mit Smartmäusen und auf dem sind die entsprechenden configs+cards. Das G-EMM Set wird auch korrekt initialisiert samt einer "SilverCard" (nutzt den anderen RSA-Key, als den der "Gold-Card"). Jedenfalls wird das "Tiger G-EMM" Key-Set im logfile als OK und "enabled" geloggt....
Aber... die EMM Daten selber kommen vom client mit gleicher oscam-version (die ebenfalls den Tivusat-patch enthält....) - Nur kommen ueber newcamd da keine "Fragmente" am eigentlichen Server an, aus denen dann dort, wo die Karte sich auch befindet, lokal ein G-EMM zusammengeschraubt wird. Offenbar geht das mit DVBAPI + lokaler Karte wohl nur im selben Gerät ?
Das Key-Set auf der client-Box und anstelle von lokalem Cardslot und eine newcamd Zeile als "reader" für den Remote-Server bringt natürlich auch nichts, da diese config mit "Remote-Update" nicht unterstützt wird. Die Option "localcard =" für einen RemoteReader zu verwenden führt auch zu keinen "eingehenden Fragmenten" am Remote-Cardserver.
Mache ich da gerade einen Denkfehler, weil ich immer noch newcamd zwischen Client+Server verwende, oder brauche ich schlichtweg einfach nur ein anderes Protokoll, z.b. Radegast, scam oder oscam-cccam, damit von der Clientbox da mehr EMM-Daten auch am Server mal ankommen ?
Für mich siehts es so aus, als ob die client-box das einfach wegfiltert und nur "standard EMM-G/S/U" ueber das Remote-Proto überträgt ?
Es werden keine Fragmente gesendet, das ist richtig. Aber das reassembeled emm wird schon an einen Server weitergeleitet (hier via cs378x) , wenn die AU Kette funktioniert.
Ggf. die Tivusat Karte auf der client Box kurz deaktivieren, damit die Karte im Server angesprochen wird...
LG stefan
Ggf. die Tivusat Karte auf der client Box kurz deaktivieren, damit die Karte im Server angesprochen wird...
LG stefan
Es gibt ja keine "Karte" auf der Clientbox - derzeit nur einen newcamd eintrag für 183E um den dedizerten oscam anzusprechen...
mit emm-reassembling client und server-seitig hatte ich auch mal testweise gespielt. beim Server selber sehe ich mit debug=64 oder 65 auch keine einzige Info, das irgend ein Fragment da vom client auch mal ankommt. Nur reguläre EMM-G+shared kommen vom client und werden geschrieben. Da das im Server wohl alles korrekt geconfed ist, dürfte es am client + proto liegen, das da offenbar nicht alles durchgereicht wird. Also mal testweise cs378x verwenden - wieso eigentlich genau dieses proto ?
Mir wäre eine Single-Portlösung für ALLE CAIDs und Cards sowieso lieber, bei der Combo: Mehrere HD+ CAIDs, ORF, SRG und Tivu gabs aber immer irgendwas, was nicht wollte.
Entweder konnten nicht mehrere Karten gleichzeitig upgedated werden, beim ORF wurde zuviel gefiltert oder das SRG Via-Assembling haute nie richtig hin. mit newcamd und als client auch teilweise mgcamd rennt das seit Jahren viel stabiler. Manche Channels die über Irdeto, VIA, N3 verfügen reicht es zum updaten dann auf einem kanel zu bleiben und alle 3 "Welten" bekommen Ihre Updates: Beispiel: 3+ vom Astra: Hier gibts dann nebenbei noch Irdeto-EMMs + das ganze HD+ Set. Oder irgendein HD+ Channel + von Irdeto immer zusätzlich noch die ORF-EMMs ;-)
Ich glaube ich müsste auch mal das dvbapi-setup auf der vuplus ggfs. nochmal checken - das rennt allerdings auch einwandfrei seit Jahren...
mit emm-reassembling client und server-seitig hatte ich auch mal testweise gespielt. beim Server selber sehe ich mit debug=64 oder 65 auch keine einzige Info, das irgend ein Fragment da vom client auch mal ankommt. Nur reguläre EMM-G+shared kommen vom client und werden geschrieben. Da das im Server wohl alles korrekt geconfed ist, dürfte es am client + proto liegen, das da offenbar nicht alles durchgereicht wird. Also mal testweise cs378x verwenden - wieso eigentlich genau dieses proto ?
Mir wäre eine Single-Portlösung für ALLE CAIDs und Cards sowieso lieber, bei der Combo: Mehrere HD+ CAIDs, ORF, SRG und Tivu gabs aber immer irgendwas, was nicht wollte.
Entweder konnten nicht mehrere Karten gleichzeitig upgedated werden, beim ORF wurde zuviel gefiltert oder das SRG Via-Assembling haute nie richtig hin. mit newcamd und als client auch teilweise mgcamd rennt das seit Jahren viel stabiler. Manche Channels die über Irdeto, VIA, N3 verfügen reicht es zum updaten dann auf einem kanel zu bleiben und alle 3 "Welten" bekommen Ihre Updates: Beispiel: 3+ vom Astra: Hier gibts dann nebenbei noch Irdeto-EMMs + das ganze HD+ Set. Oder irgendein HD+ Channel + von Irdeto immer zusätzlich noch die ORF-EMMs ;-)
Ich glaube ich müsste auch mal das dvbapi-setup auf der vuplus ggfs. nochmal checken - das rennt allerdings auch einwandfrei seit Jahren...
Zuletzt bearbeitet:
cs378x Protokoll zwischen AU Box und Server hab ich vor Jahren einfach mal genommen, weil die damalige ORF Karte damit shared emm's bekommen hat. Das heisst jetzt nicht das es mit andeen Protokollen nicht geht, war damals in diesem setup halt so und hab das einfach Beibehalten. Hat auch immer für alle Karten funktioniert...
Das reassembeled emm ist ja letzlich ein global emm, ich spiel da auch noch rum, bzw finde es im Log des Servers nicht so einfach, aber es ist da...
Die Zeiten sind jetzt unterschiedlich, das betreffende emm aber identisch.
Das reassembeled emm ist ja letzlich ein global emm, ich spiel da auch noch rum, bzw finde es im Log des Servers nicht so einfach, aber es ist da...
Die Zeiten sind jetzt unterschiedlich, das betreffende emm aber identisch.
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Step 9: EMM extracted - INS=0xD3, LEN=138
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Step 10: Building reassembled EMM
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Tiger EMM reassembled: 147 bytes (INS=0xD3)
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Reassembled EMM:
2025/12/17 13:44:00 5C36938C c (reader) 82 70 8E 00 00 00 00 00 D3 87 54 11 B2 53 4B 84
2025/12/17 13:44:00 5C36938C c (reader) 86 00 B3 C1 8B 9C 95 E6 D7 5C B3 72 D4 05 DB BF
2025/12/17 13:44:00 5C36938C c (reader) 5F 69 6B C1 AC F6 BC CC C9 90 C5 D3 C8 5E D2 1C
2025/12/17 13:44:00 5C36938C c (reader) 0C A8 3F 05 6D E6 2D 33 B8 95 64 60 10 32 4C 3F
2025/12/17 13:44:00 5C36938C c (reader) 8B 21 89 8C AE 15 AC 0D 8A B1 D2 36 9C FC 5E CE
2025/12/17 13:44:00 5C36938C c (reader) D0 36 37 40 AD 2E 2A 7E A3 AC EA 4E 52 4E 18 CF
2025/12/17 13:44:00 5C36938C c (reader) E8 C9 18 B9 A9 DF 9B 19 72 0F 47 B0 51 D6 82 4D
2025/12/17 13:44:00 5C36938C c (reader) 5C E3 31 37 7E 4D 02 A1 57 5C 3B 23 36 6F 29 BD
2025/12/17 13:44:00 5C36938C c (reader) 7B 19 C2 AD 51 4D 30 39 FD 59 15 A9 4C 61 2B E7
2025/12/17 13:44:00 5C36938C c (reader) 6E 16 03
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: === Tiger EMM reassembly END ===
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Step 11: Resetting fragment buffer
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emmtype global. Reader serial ################.
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emm UA/SA: ################.
2025/12/17 13:44:00 5C36938C c (emmcache) found emmcache match
2025/12/17 13:44:00 5C36938C c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 13:44:00 5C36938C c (emmcache) found emmstat match (reader:Tivusat-183E, count:3)
2025/12/17 13:44:00 5C36938C c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emm count 3 rewrite 3
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] Levi45 emmtype=global, len=142 (hex: 0x8E), cnt=3: skipped (0 ms)
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: reader 183E match since emmpid has no provid -> SEND!
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: emmtype global. Reader serial ################.
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: emm UA/SA: ################.
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Step 10: Building reassembled EMM
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Tiger EMM reassembled: 147 bytes (INS=0xD3)
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Reassembled EMM:
2025/12/17 13:44:00 5C36938C c (reader) 82 70 8E 00 00 00 00 00 D3 87 54 11 B2 53 4B 84
2025/12/17 13:44:00 5C36938C c (reader) 86 00 B3 C1 8B 9C 95 E6 D7 5C B3 72 D4 05 DB BF
2025/12/17 13:44:00 5C36938C c (reader) 5F 69 6B C1 AC F6 BC CC C9 90 C5 D3 C8 5E D2 1C
2025/12/17 13:44:00 5C36938C c (reader) 0C A8 3F 05 6D E6 2D 33 B8 95 64 60 10 32 4C 3F
2025/12/17 13:44:00 5C36938C c (reader) 8B 21 89 8C AE 15 AC 0D 8A B1 D2 36 9C FC 5E CE
2025/12/17 13:44:00 5C36938C c (reader) D0 36 37 40 AD 2E 2A 7E A3 AC EA 4E 52 4E 18 CF
2025/12/17 13:44:00 5C36938C c (reader) E8 C9 18 B9 A9 DF 9B 19 72 0F 47 B0 51 D6 82 4D
2025/12/17 13:44:00 5C36938C c (reader) 5C E3 31 37 7E 4D 02 A1 57 5C 3B 23 36 6F 29 BD
2025/12/17 13:44:00 5C36938C c (reader) 7B 19 C2 AD 51 4D 30 39 FD 59 15 A9 4C 61 2B E7
2025/12/17 13:44:00 5C36938C c (reader) 6E 16 03
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: === Tiger EMM reassembly END ===
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: Step 11: Resetting fragment buffer
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emmtype global. Reader serial ################.
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emm UA/SA: ################.
2025/12/17 13:44:00 5C36938C c (emmcache) found emmcache match
2025/12/17 13:44:00 5C36938C c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 13:44:00 5C36938C c (emmcache) found emmstat match (reader:Tivusat-183E, count:3)
2025/12/17 13:44:00 5C36938C c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] EMM: emm count 3 rewrite 3
2025/12/17 13:44:00 5C36938C c (reader) Tivusat-183E [nagra] Levi45 emmtype=global, len=142 (hex: 0x8E), cnt=3: skipped (0 ms)
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: reader 183E match since emmpid has no provid -> SEND!
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: emmtype global. Reader serial ################.
2025/12/17 13:44:00 5C36938C c (reader) homeserv [cs378x] EMM: emm UA/SA: ################.
2025/12/17 14:59:40 6B89C162 c (emm) emm:
2025/12/17 14:59:40 6B89C162 c (emm) 82 70 8E 00 00 00 00 00 D3 87 54 11 B2 53 4B 84
2025/12/17 14:59:40 6B89C162 c (emm) 86 00 B3 C1 8B 9C 95 E6 D7 5C B3 72 D4 05 DB BF
2025/12/17 14:59:40 6B89C162 c (emm) 5F 69 6B C1 AC F6 BC CC C9 90 C5 D3 C8 5E D2 1C
2025/12/17 14:59:40 6B89C162 c (emm) 0C A8 3F 05 6D E6 2D 33 B8 95 64 60 10 32 4C 3F
2025/12/17 14:59:40 6B89C162 c (emm) 8B 21 89 8C AE 15 AC 0D 8A B1 D2 36 9C FC 5E CE
2025/12/17 14:59:40 6B89C162 c (emm) D0 36 37 40 AD 2E 2A 7E A3 AC EA 4E 52 4E 18 CF
2025/12/17 14:59:40 6B89C162 c (emm) E8 C9 18 B9 A9 DF 9B 19 72 0F 47 B0 51 D6 82 4D
2025/12/17 14:59:40 6B89C162 c (emm) 5C E3 31 37 7E 4D 02 A1 57 5C 3B 23 36 6F 29 BD
2025/12/17 14:59:40 6B89C162 c (emm) 7B 19 C2 AD 51 4D 30 39 FD 59 15 A9 4C 61 2B E7
2025/12/17 14:59:40 6B89C162 c (emm) 6E
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: reader 183E match since emmpid has no provid -> SEND!
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emmtype global. Reader serial ################.
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emm UA/SA: ################.
2025/12/17 14:59:40 6B89C162 c (emmcache) found emmcache match
2025/12/17 14:59:40 6B89C162 c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 14:59:40 6B89C162 c (emmcache) found emmstat match (reader:TivuSat_4K, count:1)
2025/12/17 14:59:40 6B89C162 c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emm count 1 rewrite 1
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] gbQuadUHD emmtype=global, len=142 (hex: 0x8E), cnt=1: skipped (0 ms)
Also das emm KOMMT durch, wird bei mir nur nicht geschrieben, da emm cache an...
2025/12/17 14:59:40 6B89C162 c (emm) 82 70 8E 00 00 00 00 00 D3 87 54 11 B2 53 4B 84
2025/12/17 14:59:40 6B89C162 c (emm) 86 00 B3 C1 8B 9C 95 E6 D7 5C B3 72 D4 05 DB BF
2025/12/17 14:59:40 6B89C162 c (emm) 5F 69 6B C1 AC F6 BC CC C9 90 C5 D3 C8 5E D2 1C
2025/12/17 14:59:40 6B89C162 c (emm) 0C A8 3F 05 6D E6 2D 33 B8 95 64 60 10 32 4C 3F
2025/12/17 14:59:40 6B89C162 c (emm) 8B 21 89 8C AE 15 AC 0D 8A B1 D2 36 9C FC 5E CE
2025/12/17 14:59:40 6B89C162 c (emm) D0 36 37 40 AD 2E 2A 7E A3 AC EA 4E 52 4E 18 CF
2025/12/17 14:59:40 6B89C162 c (emm) E8 C9 18 B9 A9 DF 9B 19 72 0F 47 B0 51 D6 82 4D
2025/12/17 14:59:40 6B89C162 c (emm) 5C E3 31 37 7E 4D 02 A1 57 5C 3B 23 36 6F 29 BD
2025/12/17 14:59:40 6B89C162 c (emm) 7B 19 C2 AD 51 4D 30 39 FD 59 15 A9 4C 61 2B E7
2025/12/17 14:59:40 6B89C162 c (emm) 6E
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: reader 183E match since emmpid has no provid -> SEND!
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emmtype global. Reader serial ################.
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emm UA/SA: ################.
2025/12/17 14:59:40 6B89C162 c (emmcache) found emmcache match
2025/12/17 14:59:40 6B89C162 c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 14:59:40 6B89C162 c (emmcache) found emmstat match (reader:TivuSat_4K, count:1)
2025/12/17 14:59:40 6B89C162 c (emmcache) 6A 11 5F 43 84 49 62 11 A8 6F 8E A5 2C 5A 52 9B
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] EMM: emm count 1 rewrite 1
2025/12/17 14:59:40 6B89C162 c (reader) TivuSat_4K [nagra] gbQuadUHD emmtype=global, len=142 (hex: 0x8E), cnt=1: skipped (0 ms)
Also das emm KOMMT durch, wird bei mir nur nicht geschrieben, da emm cache an...
Zuletzt bearbeitet:
Suppi. Dann werd ich einfach mal ein testsetup mit cs378x Proto zwischen client und server machen.... und dann gucken ob das EMM-reassembling mit der SRG VIA-Card dann ebenfalls noch rennt, bzw. ob die 3 HD+ CAIDs 1830+1843+186A ebenso zeitgleich noch bedient werden. Mit einem HD+ Channel kontinuierlich die ORF-EMMs auch zu bekommen ist schon ein Vorteil, gerade weil die shared EMMs teilweise etliche Stunden oft brauchen - und man so nicht unbedingt via Twin-Tuner oder direkt auf nen ORF Channel muss. Das rennt bei newcamd einfach seit Jahren und musste nie wirklich angefasst werden ;-)
Hint: Eine Beispielconfig für Newbis wo nicht in jedem Post immer der lokale Box-Reader in jedem Spoiler drin ist, sondern auch eine oscam <-> oscam lokale config mit einer reinen Client-Box -nach local Oscam-Server und mit welchem Proto das dann auf beiden Seiten sinnvoll zu confen ist, würde auch anderen Usern ggfs. helfen. cccam, wo es da oft noch die Probleme mit der "ProviderID" bei Nagra, NDS, usw. gibt, bläht dann die readerconfig auch weiter auf und ist eine weitere Fehlerquelle. Hat man nur eine lokale Karte mit einer CAID, sollte es da auch
reichen in der Grundconfig 183E:000000 und im reader nur die CAID ohne ident zu verwenden. Beim log in der Client-Box werden mit newcamd sowieso die 000000 und 005411 beide
gelesen. Bei ORF irdeto gabs da auch mit cccam immer wieder ProviderID-Probleme, da sich die "ProviderIDs" ja pro Karte ändern nach dem Demo-Modus-Switch. Zumindest emm-seitig ist das immer recht tricky gewesen - auch hier heist es bei newcamd 0650:000000 einmal zu setzen - und es geht einfach....
Hint: Eine Beispielconfig für Newbis wo nicht in jedem Post immer der lokale Box-Reader in jedem Spoiler drin ist, sondern auch eine oscam <-> oscam lokale config mit einer reinen Client-Box -nach local Oscam-Server und mit welchem Proto das dann auf beiden Seiten sinnvoll zu confen ist, würde auch anderen Usern ggfs. helfen. cccam, wo es da oft noch die Probleme mit der "ProviderID" bei Nagra, NDS, usw. gibt, bläht dann die readerconfig auch weiter auf und ist eine weitere Fehlerquelle. Hat man nur eine lokale Karte mit einer CAID, sollte es da auch
reichen in der Grundconfig 183E:000000 und im reader nur die CAID ohne ident zu verwenden. Beim log in der Client-Box werden mit newcamd sowieso die 000000 und 005411 beide
gelesen. Bei ORF irdeto gabs da auch mit cccam immer wieder ProviderID-Probleme, da sich die "ProviderIDs" ja pro Karte ändern nach dem Demo-Modus-Switch. Zumindest emm-seitig ist das immer recht tricky gewesen - auch hier heist es bei newcamd 0650:000000 einmal zu setzen - und es geht einfach....
so... habe dann mal das ganze mit cs378x getestet.... das alte Problem, das dann nur noch die EMMs an den server gesendet werden, die vom aktuellen Programm verwendet werden ist nach wie wie vor vorhanden. Allerdings klappt damit auch keine saubere client/server Kombi mit tivusat. am server wird nach wie vor keine emm-g zusammengebaut. Habe natuerlich auch noch client & serverseitig mit dem emm-reassembling gespielt, mit auprov und ident variiert.... nix...
Einziger Unterschied ist der verwendete rsa-key, da ich keine Goldcard sondern eine 183E-SilverCard im Server nutze. Das sollte beim global-emm aber auch kein Unterschied machen, da das emm ja zuvor auch immer lokal oder via curl-script problemlos geschrieben worden ist. Rennen tuts also im Moment nur, wenn die Karte physikalisch sich auch in der der client-box befindet.
...da kann ich gleich die Karte in den Original TivuSat Receiver stecken.... irgendwie scheint die client oscam auf der vuuno einfach nicht alles an den server zu senden.
Frage: hat den irgendwer eine client-server kombi mit dem tivusat fix erfolgreich laufen ? Falls ja, mit welchem protokoll ? Ansonsten belasse ich das weiterhin auf newcamd und würde maximal nur für tivusat ein anderes Protokoll verwenden als "Krücke".... :-(
@stefan4u: Laut Deines logfiles hast Du das auf der CLIENT-Box laufen und sendest es dann zum server....
Frage: Wie sieht dann Deine oscam.server config aus - wenn der Reader hier ein remote reader dann ist ? - Die Nummer habe ich ja gestern auch durchgetestet, ohne das sich dann etwas geändert hatte beim server selber....
Einziger Unterschied ist der verwendete rsa-key, da ich keine Goldcard sondern eine 183E-SilverCard im Server nutze. Das sollte beim global-emm aber auch kein Unterschied machen, da das emm ja zuvor auch immer lokal oder via curl-script problemlos geschrieben worden ist. Rennen tuts also im Moment nur, wenn die Karte physikalisch sich auch in der der client-box befindet.
...da kann ich gleich die Karte in den Original TivuSat Receiver stecken.... irgendwie scheint die client oscam auf der vuuno einfach nicht alles an den server zu senden.
Frage: hat den irgendwer eine client-server kombi mit dem tivusat fix erfolgreich laufen ? Falls ja, mit welchem protokoll ? Ansonsten belasse ich das weiterhin auf newcamd und würde maximal nur für tivusat ein anderes Protokoll verwenden als "Krücke".... :-(
@stefan4u: Laut Deines logfiles hast Du das auf der CLIENT-Box laufen und sendest es dann zum server....
Frage: Wie sieht dann Deine oscam.server config aus - wenn der Reader hier ein remote reader dann ist ? - Die Nummer habe ich ja gestern auch durchgetestet, ohne das sich dann etwas geändert hatte beim server selber....
Zuletzt bearbeitet:
- Registriert
- 18. Februar 2017
- Beiträge
- 1.820
- Lösungen
- 3
- Reaktionspunkte
- 1.634
- Punkte
- 1.970
@Loman , mach doch mal ein neues Thema auf, mit deinen kompletten Configs.
Dann kann man schauen, woran es liegt. Entweder an deiner Config oder irgendwas anders, was durch den Patch nicht funktioniert, was man dann evt. fixen kann.
Dann kann man schauen, woran es liegt. Entweder an deiner Config oder irgendwas anders, was durch den Patch nicht funktioniert, was man dann evt. fixen kann.
Den versteh ich nicht. Die EMMs können doch nur von einem aktuellem/aktiven Sender kommen.
sodex
Elite Lord
- Registriert
- 9. Dezember 2012
- Beiträge
- 3.523
- Lösungen
- 3
- Reaktionspunkte
- 2.908
- Punkte
- 2.020
ja - hab es mal auf Raspi mit Oscam tiger fix und Dream Two mit ner herkömmlichen Oscam ohne diesen tiger fix getestet - das funktioniert mit dem cs378 Protokoll 1A auf der Client Box auf Canale5 HD geschaltet
Configs siehe Anhang
MfG
Also dank der Einzelports bei newcamd können auf "Multi-System-Channels", wo z.b. HD+, ORF, 3+(SRG) usw. ebenfalls mit auf dem Transponder liegen
auf nur einem Kanal 3 CA-Systeme zeitgleich upgedatet werden - ohne Multituner. Bei 3x HD+ und 3 newcamd-lines mit eigenem Port kann man so auch
3 HD+ Karten mit U/S/G einzeln zeitgleich Updaten - und nicht nur die Karte die gerade aktiv ist. Die HD+ Kanäle updaten also immer die ORF-Irdeto CAID gleich mit ;-)
3+ auf Astra, was eigentlich VIA ist, updated ebenso HD+/Irdeto, da auch hier die zusätzlichen EMMs für die anderen CA-Systeme vorhanden sind. Das ist jahrelang
ein netter Nebeneffekt von newcamd und leider einer Unmenge an extra Ports ;-)
Das mit meiner client-server config ist seit Jahren newcamd basierend und der Patch ist sowohl in der client-, als auch in der server-Kiste drin, allerdings
nur auf dem Server konfiguriert derzeit. (Log sagt ja auch klar: Keyset OK - enabled!)
Daher waren ja meine Fragen: a.) Werden die tivu-Keys auf die Clientboxen(en) in die configs eingebunden - und der Server selber, indem die eigentlichen Karten sind, bleibt weiterhin "dumm", also hier keine lokale Bearbeitung weil die clients das managen sollen....) und b.) falls das doch serverseitig "remote" geconfed wird, WELCHES Protokoll tut dann sauber zum Server ?
In meinem Fall hatte das tivu-Keyset am Client in Zusammenhang mit einem "Remote-Reader" (anstatt locales "/dev/sci0") erwartungsgemäss keine Auswirkung, da man am client,
wo keine Karten sind normal auch keine RSA-Keys braucht (mangels einer Karte). Wo keine Karte drin ist kann auch nix "aktiviert" werden. daran hat auch "localcards = 183E:000000,005411"
auf der clientbox keine Änderung gebracht.
Beim Client (VuUnoSE) siehts es so aus seit guten +2 Jahren....
oscam.conf:
oscam.dvbapi:
Das "lokale" emmreassembly muss aktiv bleiben auf den clients, da sonst die V7 SRG Ihre EMMs nicht bekommt. Das serverseitig zu machen und am client zu disablen klappt
nicht - somit ist am server jegliches emmreassbly bei den user accounts "0". Das sollte ja eigentlich eh nur für CW und VIA aktiv sein....
Und auch das habe ich kreuzweise mit allen Optionen durchgespielt ohne Änderungen.
Wie gesagt, ich habe eine SILVER-183E - keine Goldkarte, die hat den "anderen" RSA-Basis-Key damit der Server überhaupt mit der Karte kommunzieren kann !
rsakey = B0xx...xx99
- der Rest ist das Set aus der Key-Section.
auf nur einem Kanal 3 CA-Systeme zeitgleich upgedatet werden - ohne Multituner. Bei 3x HD+ und 3 newcamd-lines mit eigenem Port kann man so auch
3 HD+ Karten mit U/S/G einzeln zeitgleich Updaten - und nicht nur die Karte die gerade aktiv ist. Die HD+ Kanäle updaten also immer die ORF-Irdeto CAID gleich mit ;-)
3+ auf Astra, was eigentlich VIA ist, updated ebenso HD+/Irdeto, da auch hier die zusätzlichen EMMs für die anderen CA-Systeme vorhanden sind. Das ist jahrelang
ein netter Nebeneffekt von newcamd und leider einer Unmenge an extra Ports ;-)
Das mit meiner client-server config ist seit Jahren newcamd basierend und der Patch ist sowohl in der client-, als auch in der server-Kiste drin, allerdings
nur auf dem Server konfiguriert derzeit. (Log sagt ja auch klar: Keyset OK - enabled!)
Daher waren ja meine Fragen: a.) Werden die tivu-Keys auf die Clientboxen(en) in die configs eingebunden - und der Server selber, indem die eigentlichen Karten sind, bleibt weiterhin "dumm", also hier keine lokale Bearbeitung weil die clients das managen sollen....) und b.) falls das doch serverseitig "remote" geconfed wird, WELCHES Protokoll tut dann sauber zum Server ?
In meinem Fall hatte das tivu-Keyset am Client in Zusammenhang mit einem "Remote-Reader" (anstatt locales "/dev/sci0") erwartungsgemäss keine Auswirkung, da man am client,
wo keine Karten sind normal auch keine RSA-Keys braucht (mangels einer Karte). Wo keine Karte drin ist kann auch nix "aktiviert" werden. daran hat auch "localcards = 183E:000000,005411"
auf der clientbox keine Änderung gebracht.
Beim Client (VuUnoSE) siehts es so aus seit guten +2 Jahren....
oscam.conf:
oscam.dvbapi:
server.conf:
oscam.user:
Das "lokale" emmreassembly muss aktiv bleiben auf den clients, da sonst die V7 SRG Ihre EMMs nicht bekommt. Das serverseitig zu machen und am client zu disablen klappt
nicht - somit ist am server jegliches emmreassbly bei den user accounts "0". Das sollte ja eigentlich eh nur für CW und VIA aktiv sein....
Und auch das habe ich kreuzweise mit allen Optionen durchgespielt ohne Änderungen.
Wie gesagt, ich habe eine SILVER-183E - keine Goldkarte, die hat den "anderen" RSA-Basis-Key damit der Server überhaupt mit der Karte kommunzieren kann !
rsakey = B0xx...xx99
- der Rest ist das Set aus der Key-Section.
Zuletzt bearbeitet von einem Moderator:
AHHHH.... Das ist jetzt mal ne Idee: Ich baue mal eben ne "herkömmliche" Client-oscam, kann nämlich gut sein, wenn der fix auf einem client drin ist, das der ggfs. (unkonfiguriert)
die notwendigen emms "wegschnappt" und deshalb beim Server nie was an kommt ;-)
Danke mal für die Beispielconfig - war schon verzweifelt, da ich mit cs378x zum exakt gleichem Ergebnis kam, wie mit newcamd ;-)
Grundsätzlich sahs bei mir mit den accounts + readers bis auf den RSA-Key für die Silver-Card ziemlich identisch aus, daher war ich ja so verwundert das die "einfachsten" Dinge
nach Jahren jetzt einfach nicht mehr laufen sollen ;-) lol
Zuletzt bearbeitet:
sodex
Elite Lord
- Registriert
- 9. Dezember 2012
- Beiträge
- 3.523
- Lösungen
- 3
- Reaktionspunkte
- 2.908
- Punkte
- 2.020
du braucht doch nur beim Server in der oscam.conf das cs378 Protokoll dazu nehmen - den debuglevel auf 64 beim Abschnitt global rein machen und auf der Clientbox den Proxy Reader dazu mit der passenden Einstellung zu Caid und Group - fertig
MfG
Edit: auf der Clientbox kann auch eine Oscam mit dem tiger fix am laufen sein, das hat keinen Einfluss
MfG
Edit: auf der Clientbox kann auch eine Oscam mit dem tiger fix am laufen sein, das hat keinen Einfluss
Zuletzt bearbeitet:
...und genau das hatte ich ja gemacht gehabt - inklusive checking mit dem debuglevel 64 und da tat sich halt nichts... ich compile aber mal die normale client-version zum gegentesten, dann sollte das normal auch laufen wie erwartet 
- siehst eh an meinen config snippets, das ich den ident+provid schnickschnack da auch nicht drin hatte. Ich hatte erst mal nur die dvbapi config für die vuuno mit den optionen in Verdacht, da die den kram ja an den proxy ausliefert
... und in meinem fall rennen die beiden identischen Versionen eben noch nicht.
Ich habe allerdings auch den 802er emu mit eincompiliert in die 11907, auch das teste ich nochmal gegen. Bzw. ich teste das auch mit ner ollen DM500HD aufs mips basis nochmal nachher.
Wenn ich die eigentliche Ursache gefunden habe gebe ich mal nen Feedback.
- siehst eh an meinen config snippets, das ich den ident+provid schnickschnack da auch nicht drin hatte. Ich hatte erst mal nur die dvbapi config für die vuuno mit den optionen in Verdacht, da die den kram ja an den proxy ausliefert... und in meinem fall rennen die beiden identischen Versionen eben noch nicht.
Ich habe allerdings auch den 802er emu mit eincompiliert in die 11907, auch das teste ich nochmal gegen. Bzw. ich teste das auch mit ner ollen DM500HD aufs mips basis nochmal nachher.
Wenn ich die eigentliche Ursache gefunden habe gebe ich mal nen Feedback.
Zuletzt bearbeitet von einem Moderator:
sodale.... im Prinzip war die Ursache recht simpel:
Beim SERVER muss in die oscam.user zwingend "emmreassembly = 2" - oder nichts (2= sowieso default) beim user gesetzt sein. Ich habe da bei allen Usern vorher 1 drin gehabt.
- Beim client hingegen habe ich beim dvbapi-api user "emmreassembly = 1" drin gehabt - und beim server eben 0 für den user!
Irgendwie ist das bei mir wg. VIA 7/SRG-EMM die einzigste lauffähige Kombination gewesen mit der die Verlängerungen "assembliert" dann auch geschrieben wurden 10 Tage vorher.
Jetzt habe ich beim client (dvbapi-user) das emmreassembly rausgenommen (was dann wohl hier auch 2 als default wäre).... jetzt wirds aber spannend wenn client UND server quasi beide auf "2" stehen obs dann mit SRG-Verlängerung noch hinhaut... Irgendwie ist das etwas unglücklich jetzt, das das usersetting mit dem assembling recht "global" ist.
Beim server kann man das ja mit mehreren accounts lösen - z.b. einen EMM-User/newcamd mit einem anderen default - beim client hingegen gibts nur einen dvbapi user, entweder an oder aus - und das hat eben VIA nicht mehr upgedated wenn es hier mit > 0 enabled war.
(Die uralte Lösung wo das assembling noch in der oscam.server bei den readern gesetzt wurde war da hilfreicher - da konnte man zumindest readerbezogen regeln ob man ein assembling braucht oder nicht... da war ja mal was vor etlichen Jahren betreffs CW+ORF.....)
Die Frage bei einer codeoptimierung wäre jetzt ob man die tivusat sache unabhängig vom gesetzten asseembling-wert machen sollte - so steht diese Funktion client- und serverseitig dann für andere reader-situationen weiterhin so zur Verfügung wie man es benötigt. Da die 183E ja sowieso als Tiger erkannt wird kann man ja eigentlich davon ausgehen das man hier immer assemblen muss - egal was im "user" beim client oder server für werte stehen stehen ?
Ach ja... rennt auch weiterhin mit newcamd und ich kann auf cs378x verzichten und habe so weiterhin emms für mehr als 1 CAID zeitglich
Beim SERVER muss in die oscam.user zwingend "emmreassembly = 2" - oder nichts (2= sowieso default) beim user gesetzt sein. Ich habe da bei allen Usern vorher 1 drin gehabt.
- Beim client hingegen habe ich beim dvbapi-api user "emmreassembly = 1" drin gehabt - und beim server eben 0 für den user!
Irgendwie ist das bei mir wg. VIA 7/SRG-EMM die einzigste lauffähige Kombination gewesen mit der die Verlängerungen "assembliert" dann auch geschrieben wurden 10 Tage vorher.
Jetzt habe ich beim client (dvbapi-user) das emmreassembly rausgenommen (was dann wohl hier auch 2 als default wäre).... jetzt wirds aber spannend wenn client UND server quasi beide auf "2" stehen obs dann mit SRG-Verlängerung noch hinhaut... Irgendwie ist das etwas unglücklich jetzt, das das usersetting mit dem assembling recht "global" ist.
Beim server kann man das ja mit mehreren accounts lösen - z.b. einen EMM-User/newcamd mit einem anderen default - beim client hingegen gibts nur einen dvbapi user, entweder an oder aus - und das hat eben VIA nicht mehr upgedated wenn es hier mit > 0 enabled war.
(Die uralte Lösung wo das assembling noch in der oscam.server bei den readern gesetzt wurde war da hilfreicher - da konnte man zumindest readerbezogen regeln ob man ein assembling braucht oder nicht... da war ja mal was vor etlichen Jahren betreffs CW+ORF.....)
Die Frage bei einer codeoptimierung wäre jetzt ob man die tivusat sache unabhängig vom gesetzten asseembling-wert machen sollte - so steht diese Funktion client- und serverseitig dann für andere reader-situationen weiterhin so zur Verfügung wie man es benötigt. Da die 183E ja sowieso als Tiger erkannt wird kann man ja eigentlich davon ausgehen das man hier immer assemblen muss - egal was im "user" beim client oder server für werte stehen stehen ?
Ach ja... rennt auch weiterhin mit newcamd und ich kann auf cs378x verzichten und habe so weiterhin emms für mehr als 1 CAID zeitglich
Deine Problematik verstehe ich nicht so ganz...
Ich fang mal ganz vorn an. Mein reci im Wohnzimmer versorgt alle lokalen Karten im Server mit emm's. Für die üblichen Verdächtigen halt (HD+/-, ORF,SRG,Tivu,früher auch fransat und sky) also zeitgleich an alle benutzten Caids.
Ja stimmt, ich habe 2 Tivusat Karten, eine goldene und eine silberne. Die goldene steckt im Wohnzimmer reci mit der gepatchten Oscam und wird von dort aktualisiert. Die silberne könnt ich auch dort Einlesen und aktualisieren, es reicht aber den Tivu-Reader im Wohnzimmer Reci kurz zu deaktivieren, dann wird auf die silberne Karte im Server mit "normalem" Oscam zugegriffen bzw. emm's gesendet.
Wenn ich für meine Wohnzimmer Box den entsprechenden Reader rausnehme, aktualisiere ich die Karte eines Freundes auf die dann zugegriffen wird.
Jetzt das große Aber:
Es werden nur dann fragmentierte emm's eingesammelt und emms reassembliert wenn der lokale Reader in der Wohnzimmer Box wieder aktiviert wurde. Also nur kurz deaktivieren... Frag mich jetzt nicht nach Sinn, aber so beobachte ich das hier, wenn ich die verschiedenen Logs durchsehe... Was ich jetzt noch nicht probiert habe sind die verschiedenen "prefere local cards" Einstellungen...
LG stefan
Ich fang mal ganz vorn an. Mein reci im Wohnzimmer versorgt alle lokalen Karten im Server mit emm's. Für die üblichen Verdächtigen halt (HD+/-, ORF,SRG,Tivu,früher auch fransat und sky) also zeitgleich an alle benutzten Caids.
Ja stimmt, ich habe 2 Tivusat Karten, eine goldene und eine silberne. Die goldene steckt im Wohnzimmer reci mit der gepatchten Oscam und wird von dort aktualisiert. Die silberne könnt ich auch dort Einlesen und aktualisieren, es reicht aber den Tivu-Reader im Wohnzimmer Reci kurz zu deaktivieren, dann wird auf die silberne Karte im Server mit "normalem" Oscam zugegriffen bzw. emm's gesendet.
Wenn ich für meine Wohnzimmer Box den entsprechenden Reader rausnehme, aktualisiere ich die Karte eines Freundes auf die dann zugegriffen wird.
Jetzt das große Aber:
Es werden nur dann fragmentierte emm's eingesammelt und emms reassembliert wenn der lokale Reader in der Wohnzimmer Box wieder aktiviert wurde. Also nur kurz deaktivieren... Frag mich jetzt nicht nach Sinn, aber so beobachte ich das hier, wenn ich die verschiedenen Logs durchsehe... Was ich jetzt noch nicht probiert habe sind die verschiedenen "prefere local cards" Einstellungen...
LG stefan
Zuletzt bearbeitet:
