Oscam cacheex=3-Част5

[galiano]

Колеги, днес забелязах странно поведение на кеш-кама. Преди няколко часа, видях, че има един юзер, който прави опити за двойно логване, до тук добре нищо не обичайно, кама го дропи и остава логнат само по веднъж. След още час обаче, още един юзер започна да прави опити за многократни влизания. Към този момент, юзерите правещи двоен логин, вече са 5.... Не съм променял нищо почти месец, все още съм с билд #8068.

Въпросът ми е: само при мен ли се случва тази аномалия, или и при други колеги е така?

P.s.
Имам подозрение, че в някоя от днешните версии има бъг, и сега ъпдейтналите юзери създават проблеми (това е само предположение, не съм сигурен).

[londongunner]

Здравейте колеги , при мен продължава проблема със timeout. Сървъра е кешекс филтриран, приемниците са с оскам последни версии, спрян е лоудбаланса и на приемниците и на сървъра, но напоследък много често , след timeot в приемника спира да отваря канала дава Can't decode channel , след което трябва да сменя канала за да тръгне пак, има ли някой идея от къде може да е проблема ,какви ли не настройки въртях не става.
Това са конф на приемниците:

[global]
disablelog                    = 1
logfile                       = /tmp/oscam.log
clienttimeout                 = 1500
fallbacktimeout               = 1600
cachedelay                    = 120
unlockparental                = 1
nice                          = 1
maxlogsize                    = 200
waitforcards                  = 0
cacheexwaittime               = 100
cwlogdir                      = /tmp/cw
lb_reopen_seconds             = 200
lb_retrylimit                 = 500
lb_stat_cleanup               = 24
lb_reopen_mode                = 1
resolvegethostbyname          = 1
max_cache_time                = 7

А това на сървъра:

[global]
disablelog                    = 0
loghistorysize                = 4096
serverip                      = 0.0.0.0
logfile                       = /var/log/oscam.log
pidfile                       = 
disableuserfile               = 1
disablemail                   = 1
usrfileflag                   = 0
clienttimeout                 = 5000
fallbacktimeout               = 1500
clientmaxidle                 = 300
cachedelay                    = 120
bindwait                      = 120
netprio                       = 0
sleep                         = 0
unlockparental                = 0
nice                          = 1
serialreadertimeout           = 1500
maxlogsize                    = 32
waitforcards                  = 1
waitforcards_extra_delay      = 500
preferlocalcards              = 0
readerrestartseconds          = 5
dropdups                      = 1
cacheexwaittime               = 150
cacheexenablestats            = 0
block_same_ip                 = 1
block_same_name               = 1
usrfile                       = 
mailfile                      = 
cwlogdir                      = 
emmlogdir                     = 
lb_mode                       = 0
lb_save                       = 100
lb_nbest_readers              = 1
lb_nfb_readers                = 1
lb_min_ecmcount               = 5
lb_max_ecmcount               = 150
lb_reopen_seconds             = 900
lb_retrylimit                 = 600
lb_stat_cleanup               = 24
lb_reopen_mode                = 1
lb_max_readers                = 3
lb_auto_betatunnel            = 1
lb_auto_betatunnel_mode       = 1
lb_auto_betatunnel_prefer_beta= 50
lb_savepath                   = /tmp/.oscam/stat
lb_retrylimits                = 
lb_nbest_percaid              = 
lb_noproviderforcaid          = 
lb_auto_timeout               = 1
lb_auto_timeout_p             = 30
lb_auto_timeout_t             = 300
double_check_caid             = 
ecmfmt                        = 
resolvegethostbyname          = 0
failbantime                   = 60
failbancount                  = 5
suppresscmd08                 = 0
double_check                  = 0
max_cache_time                = 12
max_cache_count               = 5000

[csp]
port                          = 46000
serverip                      = 127.0.0.1
wait_time                     = 0:200:250,0963:100:200
csp_ecm_filter                = 
csp_allow_request             = 0

Благодаря предварително

[njor]

Колеги, днес забелязах странно поведение на кеш-кама. Преди няколко часа, видях, че има един юзер, който прави опити за двойно логване, до тук добре нищо не обичайно, кама го дропи и остава логнат само по веднъж. След още час обаче, още един юзер започна да прави опити за многократни влизания. Към този момент, юзерите правещи двоен логин, вече са 5.... Не съм променял нищо почти месец, все още съм с билд #8068.

Въпросът ми е: само при мен ли се случва тази аномалия, или и при други колеги е така?

P.s.
Имам подозрение, че в някоя от днешните версии има бъг, и сега ъпдейтналите юзери създават проблеми (това е само предположение, не съм сигурен).

И при мен до днес беше така от един юзер и не можахме да го хванем с колегата от който беше.Това до днес,а днес колегата намери в неговия оскам един юзер които превеше двоен лог бил му е сгрешил uniq = 0.След като го оправи и рестартира оскама се оправи и двойния лог на моя кеш.Много нереално звучи но това забелязах и така се оправи при мен.

[galiano]

Писах на всички които правиха дубъл, естествено никой не отговори:). Блокирах им линиите и в рамките на един ден, всички се изреди да обясняват, как чекващите им скриптове пускат по няколко процеса, друг пък ъпдейтвал автоматично бина, като скрипта му стартирал новия без да килва стария и т.н. Както и да е, нещата се оправиха.

[galiano]

Днес направих няколко теста и забелязах, че привидно най-бързия кеш от сървъра, този който локално се вижда 1-2 мс

2013/02/09 13:08:36 B6B48FC0 c DE_1702 (1702&000000/0000/0009/93:B3E394CCDFA79E453EEC841918A02329): cache3 (1 ms) (0/0/1/8)
2013/02/09 13:08:37 B6B48FC0 c DE_1702 (1702&000000/0000/006A/93:4B6498320FBB2F1F3E7D7E45C424795D): cache3 (1 ms) (0/0/2/8)

Минавайки през ццкам клиент се вижда доста по-различно

|home        |192.168.XX.XX    |00d 00:10:30|00d 00:00:01|103 (103)    |0 (0)|2.1.3   |1702:000000:006a (ok) |  2.5865s |

Виждате огромната разлика, а това е в локална мрежа.


Иначе кеша с нормални времена то рода на:

2013/02/09 13:18:07 B6B48FC0 c DE_1702 (1702&000000/0000/006B/93:72F9744DECDF239C5DC806E7041F70E2): cache3 (519 ms) (P/1/1/8)

се показва със същото време и при ццкам клиента. Проблем има само с малките кеш времена от 1-2 мс. Пробвах да вдигна времето на параметъра "cachedelay" на 100 после и на 200 мс., тогава "cache3 (1 ms)" се вдига на "cache3 (100 ms)" съответно 200, но при ццкам-а пак си дава големите закъснения.

Може ли някой да предложи решение на този проблем!?

[stefan.saraev]

Писах на всички които правиха дубъл, естествено никой не отговори:). Блокирах им линиите и в рамките на един ден, всички се изреди да обясняват, как чекващите им скриптове пускат по няколко процеса, друг пък ъпдейтвал автоматично бина, като скрипта му стартирал новия без да килва стария и т.н. Както и да е, нещата се оправиха.

бас държа че има връзка с това

^^ горното дефакто е фикс на проблема :)

[galiano]

Повече от 5 час съм с билд 7938, никаква разлика, абсолютно по същия начин се държи. Мисля, че го прави само на caid 1702, или поне там е много натрапчиво, останалите caids изглеждат нормално.

[turbopower]

Повече от 5 час съм с билд 7938, никаква разлика, абсолютно по същия начин се държи. Мисля, че го прави само на caid 1702, или поне там е много натрапчиво, останалите caids изглеждат нормално.

Аз съм виждал cccam да показва безсмислици реално с тези времена прекъсва или не? На мен лично от кеш с ниско време не ми е насичало до сега.

[galiano]

Не прекъсва, но времената които показва са дразнещо големи. Прекъсванията идват от някакви не логични timeout-и които дава от време на време за които се пише непрекъснато в стриймборда. На един клиент дава "found", на друг който прави искане за същия sid дава timeout.

[marindd]

Днес направих няколко теста и забелязах, че привидно най-бързия кеш от сървъра, този който локално се вижда 1-2 мс

2013/02/09 13:08:36 B6B48FC0 c DE_1702 (1702&000000/0000/0009/93:B3E394CCDFA79E453EEC841918A02329): cache3 (1 ms) (0/0/1/8)
2013/02/09 13:08:37 B6B48FC0 c DE_1702 (1702&000000/0000/006A/93:4B6498320FBB2F1F3E7D7E45C424795D): cache3 (1 ms) (0/0/2/8)

Минавайки през ццкам клиент се вижда доста по-различно

|home        |192.168.XX.XX    |00d 00:10:30|00d 00:00:01|103 (103)    |0 (0)|2.1.3   |1702:000000:006a (ok) |  2.5865s |

Виждате огромната разлика, а това е в локална мрежа.


Иначе кеша с нормални времена то рода на:

2013/02/09 13:18:07 B6B48FC0 c DE_1702 (1702&000000/0000/006B/93:72F9744DECDF239C5DC806E7041F70E2): cache3 (519 ms) (P/1/1/8)

се показва със същото време и при ццкам клиента. Проблем има само с малките кеш времена от 1-2 мс. Пробвах да вдигна времето на параметъра "cachedelay" на 100 после и на 200 мс., тогава "cache3 (1 ms)" се вдига на "cache3 (100 ms)" съответно 200, но при ццкам-а пак си дава големите закъснения.

Може ли някой да предложи решение на този проблем!?

Здравейте,реших да тествам и аз проблема с бързия кеш 1,2,3 мс ,както galiano и за sky italy ми дава по същия начин през cccam клиент големи ECM тайм и се получава фрийз,ако някой има идея как да се оправи да пише.Значи не знам дали е до настройка или до някакъв bug,но наистина има проблем с кеш3 при бързия кеш,тъй като при спрян кеш3 към sky italy и четене само от reader-ите няма проблем със фрийз.