AW: immer wiederkehrende Freezer
Wie gesagt, bei CS übers Internet sind vereinzelte Freez kaum zu vermeiden v.a. bei der V14.
In deinem ersten Beispiel-Log wird das auch ersichtlich:
2016/03/06 03:26:57 03E800F8 c (ecm) anonymous (1830@000000/0000/EF74/92:CE4078E3363DE4A18D51A7E01485C5A6): found (360 ms) by Servercs357 - SAT.1 HD2016/03/06 03:27:04 03E800F8 c (ecm) anonymous (1830@000000/0000/EF74/92:9A446C5EB280D65C39F58D5BA1E19BF2): timeout (700 ms) by Servercs357 - SAT.1 HD
2016/03/06 03:27:04 03E800F8 c (ecm) anonymous (1830@000000/0000/EF74/92:9A446C5EB280D65C39F58D5BA1E19BF2): found (39 ms) by Servercs357 - SAT.1 HD
39ms wäre für
HD+ und übers Internet utopisch schnell. Meine
Vermutung: der zweite ECM request (Timeout), kam beim Server verzögert an, der Server hat darauf hin schon mit dem Key für den dritten request geantwortet, wodurch der Client bereits nach 39ms den Key für den dritten request zur Verfügung hatte.
In deinem Beispiel dürfte auch nur user1 einen Aussetzer gehabt haben, also liegt die Vermutung nahe, dass es an seiner Leitung, bzw. der Verbindung zwischen seinem unde deinem Provider liegt und weniger an deinem Server. Um zu untermauern, dass es an der Leitung liegt, könntest du noch ein Ping-Log erstellen, also der beide clients sekündlich pingen und mit der Uhrzeit + Antwortzeit loggen. Dann die Ping-logs auf Ausreißer mit hohen Antwortzeiten durchsuchen und mit den oscam logs vergleichen.
Btw. VPN wird vermutlich über TCP laufen, d.h. du wirst beim CS nicht die Verzüge von UDP genießen, es wird lediglich der doppelte TCP overhead eingespart. Persönlich halte ich camd35 für den Privatgebrauch als ausreichend sicher und dass man kein VPN zusätzlich benötigt. Bringt vllt. auch noch ein paar ms in den Latenzen ein.
Zu deiner neuen Log: (
Vermutung)
2016/03/07 02:04:32 03E800F8 c (ecm) user1 (098C@000000/025B/0083/98BC71B80C1EA7DB68560022F24FC6AFD): timeout (1200 ms) by Servercs357 - Sky Cinema HD2016/03/07 02:04:33 03E800F8 c (ecm) user1 (098C@000000/025B/0083/98BC71B80C1EA7DB68560022F24FC6AFD): timeout (1201 ms) by Servercs357 - Sky Cinema HD
2016/03/07 02:04:34 03E800F8 c (dvbapi) Demuxer 0 trying to descramble PID 0 CAID 09C4 PROVID 000000 ECMPID 1BB6 ANY CHID PMTPID 0064 VPID 04FF
2016/03/07 02:04:34 03E800F8 c (ecm) user1 (09C4@000000/025B/0083/B3:00000000000000000000000000000000): rejected caid (0 ms) - Sky Cinema HD (invalid caid 0x09C4)
2016/03/07 02:04:34 03E800F8 c (ecm) user1 (09C4@000000/025B/0083/B3:00000000000000000000000000000000): rejected caid (1 ms) - Sky Cinema HD (invalid caid 0x09C4)
2016/03/07 02:04:34 03E800F8 c (dvbapi) Demuxer 0 trying to descramble PID 1 CAID 09AF PROVID 000000 ECMPID 1FB6 ANY CHID PMTPID 0064 VPID 04FF
2016/03/07 02:04:35 03E800F8 c (ecm) user1 (09AF@000000/025B/0083/92:00000000000000000000000000000000): rejected caid (1 ms) (invalid caid 0x09AF)
2016/03/07 02:04:35 03E800F8 c (-) -- Skipped 1 duplicated log lines --
2016/03/07 02:04:35 03E800F8 c (dvbapi) Demuxer 0 restarting decodingrequests after 1 ms with 3 enabled and 0 disabled ecmpids!
2016/03/07 02:04:35 03E800F8 c (dvbapi) Demuxer 0 trying to descramble PID 2 CAID 098C PROVID 000000 ECMPID 1AB6 ANY CHID PMTPID 0064 VPID 04FF
user1 hatte mal wieder keine Verbindung zu dir bzw die Antwort ist nicht angekommen => Timeout. Nachdem er auf 098C keine gültigen ECMs bekommen hat, hat der client andere caid probiert 09C4 und 09AF (auf die keine Karte vermutlich eh keine Antwort weiß), für diese hast du ihm aber in deiner user-config keine Rechte gegeben, also wird der request abgelehnt. Irgendwann probiert er wieder die 098C und alles is OK. Der user kann glaub über die dvbapi-File festlegen, welche CAID er probieren soll, damit könnte er verhindern, dass Zeit mit sinnlosen Anfragen verschwendet wird.