gelöst manchmal extrem hohe Lesezeiten (LB-Value) von Karte in USB Reader

[dvbs-rpi]

Liebes Forum,

mein Setup lief nun wieder ein Jahr problemlos; seit ein paar Tagen habe ich manchmal sehr lange Lesezeiten der Karte; was zu Bildaussetzern führt:

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

in der History sehe ich dann wie am Bild einige rote Balken (Zeiten teilweise 15000+ ms), dann wieder einige normal und sehr flott, dann wieder ewig langsam.

Meine Daten: Raspberry 3 mit Smartmouse/Easymouse Reader über USB, oscam-1.20-unstable_svn-r11211, raspbian jessie
Ich habe an meiner Konfiguration nichts verändert; ich nehme an, ich sollte nicht lauter globale EMM schreiben? Wie blocke ich die; bzw. wie schreibe ich trotzdem die EMMs, die ich benötige, damit die Karte aktiv bleibt? Ist meine Karte jetzt beschädigt durch das dauernde schreiben?

Spoiler: Log

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Spoiler: config

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Spoiler: server

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Spoiler: user

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

keine dvbapi.

ich habe Kartenname, passwörter & keys durch xxx ersetzt; falls da sonst noch Infos drin sind, die da nicht sein sollten, lasst es mich bitte wissen...

Habt ihr ideen, wie ich das behebe? Brauche ich eine neue Karte? und was sollte ich blocken/was nicht?

vielen Dank im Voraus & schönen Sonntag Abend!

 

[razorback]

Deine Konfigurationen sind ein erbarmungswürdiger Sauhaufen
Um auch nur annähernd einen Durchblick zu erlangen solltest Du mal sagen, mit was für einem Client Du auf den Server zugreifst.
Und die Konfigurationen sowohl vom Server als auch vom Client hier reinstellen.
Das einzig zuordenbare in Deinem Post ist das Log, das ja offenbar vom Server kommt.
Alles andere scheint eine willkürliche Mischung von Server und Client zu sein.

Also:
oscam.conf, oscam.server, oscam.user sowohl vom Server als auch vom Client (wenn der auch mit Oscam betrieben wird

Dan sehen wir weiter.....

 

[dvbs-rpi]

ok, danke für die Antwort, ich weiß noch nicht genau, was ich damit anfangen kann - oscam.conf, oscam.server und oscam.user stammen direkt aus "oscam->files" vom Server und sind 1:1 hier hereinkopiert, bis auf ein paar "xxx". Auf ebendiesem Raspberry Pi läuft sowohl oscam, als auch TVHeadend. Es macht für die Symptome keinen Unterschied, ob ich mit PC und VLC schaue, oder mit Kodi/OSMC auf einem (anderen) Raspberry Pi 3. Also was soll ich noch an Informationen posten? Wie kann ich meinen "erbarmungswürdigen sauhaufen" bereinigen?

 

[waves]

Die Karte wird mit globalen EMM's bombardiert.

Füge im Reader der Karte

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

hinzu, Oscam neu starten, testen und berichten.

 

[dvbs-rpi]

besten Dank, nach hinzufügen von "blockemm-g = 1" sieht der log natürlich gleich anders aus:

Spoiler: log

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

also bin ich vorsichtig optimistisch, dass das nun besser funktioniert.

Zwei Fragen hätt ich dazu: jetzt wird die Freischaltung nicht mehr automatisch aktualisiert, oder? Dh ich muss das alle paar Wochen manuell machen? Reicht es, für einige Zeit die globalen EMMs wieder zu erlauben (wie lange?) oder einfach wenns dunkel bleibt einloggen und manuelle Freischaltung senden; das sollte dann unique sein und geschrieben werden?

Und: warum hat das so lange problemlos funktioniert und jetzt gar nicht mehr? Ich habe am System nichts verändert...

vielen Dank schon mal!

 

[waves]

Meines Wissens nach braucht die Karte keine globalen zum hell bleiben.
Falls doch, dann machst du den Blocker kurz raus, wenn es dunkel ist, und wieder rein, sobald es wieder hell ist.
Shared und Unique werden so immer noch geschrieben, und ich meine, das reicht auch.

Warum die jetzt gerade soviele globals schicken, das wissen nur die..... gibt es aber immer mal wieder bei (fast) jedem Provider mal zwischendurch.......

 

[razorback]

die global EMMs sind völlig wurscht !
wenn dem nicht so wäre dann hätten die Leute, die kein OSCam benutzen ausschließlich Probleme und statt Fernsehen eine Diashow.

Was Deine Konfigs angeht - ich hab NULL Kenntnis von TV-Headend.
Es könnte also durchaus sein, daß dein "erbarmungswürdiger Saustall" durchaus damit zusammenhängt und so sein muß - ich kanns mir aber nicht vorstellen.

 

[waves]

@razorback

Ich weiß zwar nicht, wo Du da nen "Saustall" siehst, denn die Configs sind durchaus iO...... :flushed:
Klar gibt es bei allen Configs irgendwelche Kleinigkeiten zu verbessern, die aber hier nicht ins Gewicht fallen.

Ungewöhnlich ist nur, der dvbapi Abschnitt in der Conf, obwohl kein Receiver, sondern ein Raspi..... aber richtig, da hier TVHeadend zum Einsatz kommt.

 

[Smiley007]

@razorback

so schlimm sind die Config’s doch garnicht
———————————————————-

ich würde natürlich auch die globalen EMM’s blocken.

zudem kann alles mit LB raus, da ja wohl nur eine ORF Karte vorhanden ist.

 

[razorback]

... und daß die Services für den orf im Reader drinstehen.....

 

[waves]

was sicherlich ein Copy & Paste Fehler ist..... sonst würden die Services nicht greifen.

 

[razorback]

habe ich das richtig verstanden, daß der TVHeadend sozusagen der dvbapi vom Raspi ist ?
wenn dem so ist, dann würde natürlich eine oscam.dvbapi schon Sinn machen
P: 0D98
würde schon genügen.....

...grade bei dem im Log angefüjhrten Kanal ORF-1 kommen die angeforderten CAIDs wie folgt daher:

• 2020/02/10 07:50:29 5A1B9603 c (dvbapi) Demuxer 0 ecmpid 0 CAID: 0648 ECM_PID: 0065 PROVID: 000000
• 2020/02/10 07:50:29 5A1B9603 c (dvbapi) Demuxer 0 ecmpid 1 CAID: 0650 ECM_PID: 0067 PROVID: 000000
• 2020/02/10 07:50:29 5A1B9603 c (dvbapi) Demuxer 0 ecmpid 2 CAID: 0D95 ECM_PID: 00FB PROVID: 000000
• 2020/02/10 07:50:29 5A1B9603 c (dvbapi) Demuxer 0 ecmpid 3 CAID: 0D98 ECM_PID: 00FD PROVID: 000000

ohne dvbapi werden die CAIDs in dieser Reihenfolge abgefragt und die vorhandene 0D98 ist halt da die letze in der Liste...

 

[Smiley007]

Und was soll das nun helfen?

wird ein anderer Caid als 0D98 abgefragt? Nein

Es ist doch im Log ersichtlich, wenn eine Globale EMM zeitgleich mit der ECM Anfrage kommt, geht die Antwortzeit hoch.

Globale EMM geblockt und schon passiert das nicht mehr.

 

[razorback]

ja, ich geb Dir recht !
das Schreiben der EMMs dauert da wirklich unterirdisch lang.
vielleicht würde eine nähere Betrachtung der mhz/cardmhz da was bringen ?

 

[waves]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Am Raspi ist wahrscheinlich sogar ein Tuner dran.....

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Wozu? Du sagst doch selbst

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Alles andere ist Makulatur oder sagen wir "jammern auf hohem Niveau".