Aktuelles
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

v13 pairing verhindern

    Nobody is reading this thread right now.
AW: v13 pairing verhindern

hallo stefan,

Normalerweise bremst nicht das das AU als solches, sondern die vielen unnötigen Schreibvorgänge auf der Karte. Initial auf Seite 1 war ich davon ausgegangen daß serverseitig alle emm's auf die Karte gehen. Globals z.B. kommen relativ häufig, so daß ein permanentes SCHREIBEN (nicht loggen) zu Verzögerungen führen kann. Wenn Du aber nur speicherst (und dann auch nur die uniques) bleibt die Karte davon unbelastet. Somit können bis max 5 gleichzeitige Abfragen ohne freezer laufen.
du denkst in viel zu großen dimensionen :-)
die karte hier wird WIRKLICH nicht geshared. der abonnent benutzt sie nur dazu, im wohnzimmer und im schlafzimmer fernzusehn, ohne karte oder reciever mit rumschleppen zu müssen.
es wird weder ständig auf die karte geschrieben, noch benutzt die karte mehr als ein receiver zur selben zeit.
bzw doch, wenn er vergisst den receiver im schlafzimmer auszuschalten, oder wenn im wohnzimmer eine aufnahme läuft...
es ist also kein problem vom überlasten der karte.

Also dem proxie reader/dvbapi des clienten AU dauerhaft erlauben. Wenn AU nur für V13/14 erfolgen soll, reicht es hier nur uniques an den Server weiterzuleiten.

Am Server / bzw. dessem Reader für die V13 blockst Du zunächst alles (es kommt auch accidentiell nix auf die Karte/keine Verzögerungen durch emm Verarbeitung) uns setzt gleichzeitig einen Haken bei "save emm unique".
genau so ist es momentan eingestellt.
naja, fast. es werden vom receiver einfach alle emm an den server "geschrieben" und dieser wählt dann, was er blockt und loggt.

Weiterhin bleibt die Karte vom Datenstrom der emm's völlig unangetastet, es werden lediglich uniques im vorgesehenem Ordner gespeichert. Das wird Dein emm log, geblocke hin oder her. Nur wenn Du alle 20 Tage eine Verlängerung manuell schreibst, kann es zu kurzen Aussetzern kommen.

Also, so läuft das zumindest hier seidenweich...

das ist alles nicht das problem. es ist ein problem von enigma2, oscam, receivertreiber, whatever.
2 gleichzeitige aufnahmen verschlüsselter sender klappen NUR wenn au ausgeschaltet ist.
ist au auf dem receiver aktiv (egal ob mit blocks, logs oder ohne), ist die zweite aufnahme eines verschlüsselten senders schwarz. es ist also kartenunabhängig, da ja bei 2 aufzeichnungen desselben senders die ecm ja eh aus dem cache kommen.

das ist sehr ärgerlich, da ja bei doppelfolgen die aufnahmen überlappen und so die 2. unbrauchbar ist.
aktiviert man "block au" sind 2-3-4 gleichzeitige aufzeichnungen plus weiterer sender ansehn kein problem.
auf die karte wird beidemale nichts geschrieben.

aber zurück zum thema:
laut dem v13 emm pin post (den ich erst jetzt gefunden habe)
sind meine beiden emm:
8270 1E dez 30 V13 Verlängerung Vollabo (Bei V14 #UNKNOWN#)
8270 32 dez 50 V13 Verlängerung(20,21,22Tiers)-(2,3Tiers gelöscht-5a,5d+5e,F0 je1user)(Bei V14 Verlängerung:30,15 Tiers)

was bedeutet verlängerung vollabo?
muss ich die dann schreiben, oder nicht?
die 1e kommt nach wie vor etwa 3 mal die stunde, die 32 nur einmal die stunde.

es ist zwar ein vollabo mit allem (außer hd+), aber es sind nur 16 tiers drauf...

jay

ps: mittlerweile habe ich die oscam version auf dem receiver auf version 10615 geupdated...
 
Zuletzt bearbeitet:
AW: v13 pairing verhindern

Also, bleiben wir beim Wichtigem...

Der 827032 ist, wie es Aussieht, Euer Verlängerer. Der 1E kommt zwar häufiger, im bis zu 10 minütigem Intervall ist aber nicht Laufzeitrelevant. Was Er genau macht ist (mir) nicht wirklich klar, steht aber mit Änderungen im Zusammenhang. Vermutlich wirst Du nach 2-3 Verlängerungsperioden einen Verlängerer mit anderer Länge bekommen.

Du kannst den jetzigen 827032 Schreiben und damit die Gültigkeit um 20 Tage verlängern.
Am 17/18 (Du sagtest ja, das wäre die Gültigkeit der Karte) wird ein neuer Verlängerer auftauchen, höchstwahscheinlich wieder ein 827032 mit dann anderem Inhalt. Am 27/28 kommt wieder einer vermutlich auch noch ein 827032. In weiteren 20 Tagen ist der Nächste fällig, das könnte dann aber (wieder?) ein 24'er sein...Dann nicht wundern...



Nicht so wichtig...

Die Aufnahmeprobleme in der Vergangenheit sind mir nicht ganz klar. Wäre ein Ruckeln zu Beobachten, wäre die Karte Überlastet, eine jedoch völlig schwarze Aufnahme könnte eher ein dvbapi/oscam Problem sein. Es gab in der Vergangenheit mal diffuse Probleme bei Mehrfachentschlüsselungen, hatte ich auch. Gut, Du hast clientseitig oscam aktualisiert (serverseitig wäre auch gut...)

Die Zweite Variante, halt eine Überlastete Karte, habe ich im simplem homeshare anfänglich auch schnell "hinbekommen". Damals noch ohne fastmode, waren mehr als 2 gleichzeitige saubere Entschlüsselungen nicht drin. Wenn dann auch noch alle emms geschrieben (Nicht gespeichert) werden, wird pro emm schreibvorgang halt auch noch Rechenzeit der Karte gebraucht und das System kann schnell in's stocken geraten. Global emm's z.B. kommen ziemlich häufig, hier ein Logauschnitt von nicht mal einer Minute
2015/08/12 15:53:35 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=40: blocked (0 ms)
2015/08/12 15:53:37 4FD195BD c (ecm) wohnen3 (09C4@000000/11FA/0087/B3:698D303BBE36C1038552196D2173DCFB): found (122 ms) by skyv13 - Cinema + 24 HD
2015/08/12 15:53:40 4FD195BD c (ecm) wohnen3 (09C4@000000/11FC/0089/B3:2BD9361F300018D648E022E81DBDBDF9): found (120 ms) by skyv13 - Spiegel Geschichte HD
2015/08/12 15:53:41 77E0A97E c (ecm) wohnen2 (09C4@000000/08FD/2EFE/B3:058833A8910A65102D64AD4DCE19CAD2): found (120 ms) by skyv13 - RTL Living
2015/08/12 15:53:41 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=41: blocked (0 ms)
2015/08/12 15:53:44 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=42: blocked (0 ms)
2015/08/12 15:53:44 4FD195BD c (ecm) wohnen3 (09C4@000000/11FA/0087/B3:E5F5D1BAE9832B68E3A5CA847A1D4D3A): found (121 ms) by skyv13 - Cinema + 24 HD
2015/08/12 15:53:44 00000000 (stat) loadbalancer: statistic saved 58 records to /var/log/load_balancer/stat.txt in 1 ms
2015/08/12 15:53:45 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=44 (hex: 0x2C), idx=0, cnt=43: blocked (0 ms)
2015/08/12 15:53:47 4FD195BD c (ecm) wohnen3 (09C4@000000/11FC/0089/B3:7EBC61C49295E86183750E8F9AC67FE3): found (120 ms) by skyv13 - Spiegel Geschichte HD
2015/08/12 15:53:51 77E0A97E c (ecm) wohnen2 (09C4@000000/08FD/2EFE/B3:520264F303CF1AA44F31FD3E5B7A2EEE): found (121 ms) by skyv13 - RTL Living
2015/08/12 15:53:51 4FD195BD c (ecm) wohnen3 (09C4@000000/11FA/0087/B3:FCDEC399CA152A07393E357231556CA7): found (121 ms) by skyv13 - Cinema + 24 HD
2015/08/12 15:53:54 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=44: blocked (0 ms)
2015/08/12 15:53:54 4FD195BD c (ecm) wohnen3 (09C4@000000/11FC/0089/B3:A53E501D1369F148667830362D229DBB): found (121 ms) by skyv13 - Spiegel Geschichte HD
2015/08/12 15:53:56 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=45: blocked (0 ms)
2015/08/12 15:53:57 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=32 (hex: 0x20), idx=0, cnt=46: blocked (0 ms)
2015/08/12 15:53:58 4FD195BD c (ecm) wohnen3 (09C4@000000/11FA/0087/B3:B552D62893EC04CBFD15D578A7464DB4): found (121 ms) by skyv13 - Cinema + 24 HD
2015/08/12 15:54:01 77E0A97E c (ecm) wohnen2 (09C4@000000/08FD/2EFE/B3:4F76F714F90BB4CBAA3687F072D8F203): found (122 ms) by skyv13 - RTL Living
2015/08/12 15:54:01 4FD195BD c (ecm) wohnen3 (09C4@000000/11FC/0089/B3:9566B30F65C8464447F0F54918A3E6EF): found (122 ms) by skyv13 - Spiegel Geschichte HD
2015/08/12 15:54:05 4FD195BD c (ecm) wohnen3 (09C4@000000/11FA/0087/B3:D72F0672CAA960BBB9054CC8EB5F2242): found (121 ms) by skyv13 - Cinema + 24 HD
2015/08/12 15:54:07 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=151 (hex: 0x97), idx=0, cnt=47: blocked (0 ms)
2015/08/12 15:54:08 4FD195BD c (reader) skyv13 [videoguard2] wohnen3 emmtype=global, len=42 (hex: 0x2A), idx=0, cnt=48: blocked (0 ms)
Sowas Könnte die (falsche) Schlussfolgerung "AU = Aufnahmeprobleme" auch erklären, besonders ohne Fastmode.

Wenn Du alles sauber und sicher konfiguriert hast und oscam auf den Receivern, sowie serverseitig aktualisiert ist, gehen auf jeden Fall auch 5 gleichzeitige Aufnahmen, sofern der Receiver das mitmacht...

Grüße stefan
 
AW: v13 pairing verhindern

hallo,
Die Aufnahmeprobleme in der Vergangenheit sind mir nicht ganz klar. Wäre ein Ruckeln zu Beobachten, wäre die Karte Überlastet, eine jedoch völlig schwarze Aufnahme könnte eher ein dvbapi/oscam Problem sein. Es gab in der Vergangenheit mal diffuse Probleme bei Mehrfachentschlüsselungen, hatte ich auch. Gut, Du hast clientseitig oscam aktualisiert (serverseitig wäre auch gut...)
ja. es ist genau dieses diffuse problem, aber nachzuvollziehen. und es liegt eindeutig am eingeschalteten au.

natürlich hatte ich schon zu anfang das oscam auf dem server aktualisiert. sonst hätte das logging ja garnicht geklappt. steht auch im thread.
übrigens hätte ich das oscam auf dem client besser nicht erneuert, denn das neue macht im gegensatz zum alten, ein korrektes emm caching. so kommt auf dem server immer nur ein emm an und ich kann dort nicht nachvollziehen, wie oft es kommt.

Sowas Könnte die (falsche) Schlussfolgerung "AU = Aufnahmeprobleme" auch erklären, besonders ohne Fastmode.
es ist keine falsche schlussfolgerung, sondern ein eindeutiges verhalten.

Wenn Du alles sauber und sicher konfiguriert hast und oscam auf den Receivern, sowie serverseitig aktualisiert ist, gehen auf jeden Fall auch 5 gleichzeitige Aufnahmen, sofern der Receiver das mitmacht...
es ist alles "sauber und sicher" konfiguriert. es läuft seit über 3 jahren problemlos.
das au war und ist auf dem server schon immer abgeschaltet.
sobald das au auf dem client angeschaltet wird, gehen die 0 byte aufnahmen los. bis zur karte gelangte da nie auch nur ein emm...

meine hoffnung daß es an oscam lag, war auch der grund des updates. hat sich leider nicht erfüllt...

es liegt wohl an dem alten hdmu st4 image. selbst dieses kann ich nicht updaten, da der besitzer mit dem openwebif nicht zurecht kommt und ich ihm so die letzte hdmu mit dem alten webif wieder draufmachen musste.

jay
 
Zurück
Oben