MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

[fenbg]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Попробуй
# network mode, use summ for several clients
G: { 01 }
# network retry, use summ for several options
N: { 01 }

[PICachu]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

[quote author=fenbg link=topic=3909.msg52341#msg52341 date=1261749290]
@PICachu
зачем,причем здесь первое место ,укажи то что тебе надо и посмотри ,что ты, там забацал в OpenXCAS /openxcas.conf
[/quote]
Только вчера решали аналогичную проблему. Все решилось именно перемещением камд на первое место...

[fenbg]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Опиши pls,какой был проблем.До сих пор я ни один раз не перемещял камд на первое место. ??? и все шло без проблем и newcs i mpcs i oscam i т.д. ???

[PICachu]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Проблема была в том, что мгкам коннектился к серверу, логинился, принимал данные карты, а вот обмена CW-DW не было.

[Sergei.r]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

[quote author=pekser link=topic=3909.msg45904#msg45904 date=1257973540]
На кэш влияет также параметр Е:. Должно быть примерно так:

Spoiler

# keep ecm cache, seconds
E: { 15 }

# cache option, summ of:
# 00 Off (default)
# 01 Ecm pids cache, store pids used to decode in /tmp/ca_cache.list at exit, load at startup, same syntax as restore.list
# 02 Ecm data cache, remember CW for (E time
# 04 Emm cache for network cards, do not resend the same emm twice, cache not cleared until restart
H: { 07 }

Чтобы быть уверенным, что все нормально, включи на запись просматриваемый канал и посмотри лог. Должно быть вроде этого:

Spoiler

22:39:05 192.168.1.5 [mg0] -> ECM to newcamd <IP сервера>:<порт>
22:39:06 192.168.1.5 [mg0] <- CW from newcamd <IP сервера>:<порт> (484ms)
22:39:06 192.168.1.5 [mg0] 484 msec -- Wed Nov 11 20:35:08 2009
22:39:06 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa3 ======
22:39:06 192.168.1.5 prov: 023700
22:39:06 192.168.1.5 cw0:0 57 1E 4F C4 70 9C 40 4C
22:39:06 192.168.1.5 cw1:0 75 0B 31 B1 82 7A E9 E5
22:39:06 192.168.1.5 [mg1] Cached -- Wed Nov 11 20:35:08 2009
22:39:06 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa3 ======
22:39:06 192.168.1.5 prov: 023700
22:39:06 192.168.1.5 cw0:1 57 1E 4F C4 70 9C 40 4C
22:39:06 192.168.1.5 cw1:1 75 0B 31 B1 82 7A E9 E5
22:39:15 192.168.1.5 [mg1] -> ECM to newcamd <IP сервера>:<порт>
22:39:16 192.168.1.5 [mg1] <- CW from newcamd <IP сервера>:<порт> (571ms)
22:39:16 192.168.1.5 [mg1] 571 msec -- Wed Nov 11 20:35:18 2009
22:39:16 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa3 ======
22:39:16 192.168.1.5 prov: 023700
22:39:16 192.168.1.5 cw0:1 57 1E 4F C4 70 9C 40 4C
22:39:16 192.168.1.5 cw1:1 4B 8E 90 69 08 A6 3C EA
22:39:16 192.168.1.5 [mg0] Cached -- Wed Nov 11 20:35:18 2009
22:39:16 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa3 ======
22:39:16 192.168.1.5 prov: 023700
22:39:16 192.168.1.5 cw0:0 57 1E 4F C4 70 9C 40 4C
22:39:16 192.168.1.5 cw1:0 4B 8E 90 69 08 A6 3C EA

Т.е. один процесс получает ключ с сервака, а второй берет из кэша.

При отключенном кэше, когда E: { 0 } или H: { 0 }, оба процесса запрашивают ключи с сервака. Результат примерно такой

Spoiler

22:43:17 192.168.1.5 [mg0] <- CW from newcamd <IP сервера>:<порт> (1217ms)
22:43:17 192.168.1.5 [mg0] 1217 msec -- Wed Nov 11 20:39:19 2009
22:43:17 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa4 ======
22:43:17 192.168.1.5 prov: 023700
22:43:17 192.168.1.5 cw0:0 00 AF 50 FF D5 32 BA C1
22:43:17 192.168.1.5 cw1:0 44 84 2A F2 34 54 02 8A
22:43:17 192.168.1.5 [mg1] -> ECM to newcamd <IP сервера>:<порт>
22:43:17 192.168.1.5 [mg1] <- CW from newcamd <IP сервера>:<порт> (59ms)
22:43:17 192.168.1.5 [mg1] 59 msec -- Wed Nov 11 20:39:19 2009
22:43:17 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa4 ======
22:43:17 192.168.1.5 prov: 023700
22:43:17 192.168.1.5 cw0:1 00 AF 50 FF D5 32 BA C1
22:43:17 192.168.1.5 cw1:1 44 84 2A F2 34 54 02 8A
22:43:26 192.168.1.5 [mg1] -> ECM to newcamd <IP сервера>:<порт>
22:43:27 192.168.1.5 [mg1] <- CW from newcamd <IP сервера>:<порт> (1212ms)
22:43:27 192.168.1.5 [mg1] 1212 msec -- Wed Nov 11 20:39:29 2009
22:43:27 192.168.1.5 ===== Viaccess ECM on CaID 0x0500, pid 0x0fa4 ======
22:43:27 192.168.1.5 prov: 023700
22:43:27 192.168.1.5 cw0:1 54 05 35 8E B1 B6 E9 50
22:43:27 192.168.1.5 cw1:1 44 84 2A F2 34 54 02 8A

В итоге получаем бан.

[/quote]
везде двойные запросы.за получение ключа из кэша бан так же
Ресс может ошибится иль прога антикаскадинговая. Уже было такое про дрим 500. Когда плюсы ввели длинный ключ. Вроде думали что он с кэша а он и с сервака хапал. В итоге баны полетели
стоит кому то отключится с того канала который ты пишешь и кэш твой обрубится. Это не решение.

[pekser]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Если мгкамд берет ключ из кэша, то запрос он никуда не посылает, т.к. кэш находится внутри ресивера. И в логе это отображается (пишет слово Cached). Три месяца активно пользуюсь записью и бана ни разу не было. А поначалу тоже поймал, спасибо добрые люди на этом форуме помогли. Вот ссылка на конфиг, который меня спас
http://www.pristavka.de/index.php/to....html#msg40420

[Sergei.r]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Кэширование в рессивере происходит и этот рессивер назад на сервер отправляет. Если кто то смотрит канал какой и ты то твой кэш будет работать. А стоит с него мне допустим уйти и ресс начинает метаться, где взять. А где ещё как не второй запрос.
Или это неправельное суждение?

[pekser]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Я это дело понимаю так. Когда смотришь по шуре канал, мгкамд ([mg0]) отправляет на сервер запрос ключа, получив ответ дешифрирует поток и идет картинка. В логе выглядит примерно так
22:39:05 192.168.1.5 [mg0] -> ECM to newcamd <IP сервера>:<порт>
22:39:06 192.168.1.5 [mg0] <- CW from newcamd <IP сервера>:<порт> (484ms)
Если включаешь запись просматриваемого канала, запускается еще один экземпляр мгкамд ([mg1]) и начинает раскодировать данные для записываемого файла. При этом если кэш отключен, он тоже шлет запросы на сервер.
Типа
22:43:16 192.168.1.5 [mg0] -> ECM to newcamd <IP сервера>:<порт>
22:43:17 192.168.1.5 [mg0] <- CW from newcamd <IP сервера>:<порт> (1217ms)
22:43:17 192.168.1.5 [mg1] -> ECM to newcamd <IP сервера>:<порт>
22:43:17 192.168.1.5 [mg1] <- CW from newcamd <IP сервера>:<порт> (59ms)
Получается бан.
Если же включить кэш, первый процесс [mg0] записывает в него полученные ключи (хранятся там столько секунд, сколько задашь параметром Е) и второй мгкамд [mg1] проверяет кэш, находит ключ и берет его уже оттуда, без запроса к серверу
22:39:05 192.168.1.5 [mg0] -> ECM to newcamd <IP сервера>:<порт>
22:39:06 192.168.1.5 [mg0] <- CW from newcamd <IP сервера>:<порт> (484ms)
22:39:06 192.168.1.5 [mg1] Cached -- Wed Nov 11 20:35:08 2009
Бана нет.
Если переключишься на другой канал, а запись будет продолжаться, то оба процесса будут вынуждены запрашивать ключи с сервера, т.к. каналы у них разные и ключи из кэша не подходят. Тоже бан. Но это уже нарушение правил, так и должно быть.
Если в чем ошибаюсь, пусть спецы поправят.
Собственный опыт показывает, что с включенным кэшем при записи баны не ловятся. А с выключенным нарывался.
Контролировать это дело очень удобно программой Openbox MgCamd Explorer - кроме лога, показывает количество отправленных запросов и полученных ответов, среднее время отклика, средний интервал между запросами. Сразу видно, когда что не так.

[Sergei.r]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Впринцыпе, я так и думал, спасибо за подробное объяснение.
Ну хорошо, а можно вообще избежать 2 запросов при записи при других EMU?
Просто только недавно с этим столкнулся, а помощи не у кого попросить. Приходиться задавать уже наверное заданные вопросы.

[pekser]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Тут конкретно ничего сказать не могу, т.к. другими EMU почти не пользовался. Пробовал Multicas, вроде нормально работает, но не открывает плюсовские ХД каналы, поэтому отказался. Почитай в других ветках, может найдешь ответ.

[GrandCru]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

Кстати вижу в инете активно обсуждают 1.34d, там добавили какие-то новые параметры для просмотра D+

[sluch]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

что то он не запустился у меня. сегодня провозился пол дня.

[Alex1808]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

[quote author=sluch link=topic=3909.msg54242#msg54242 date=1263052485]
что то он не запустился у меня. сегодня провозился пол дня.
[/quote]

Новерно его поэтому так активно обсуждают...

[Fitter]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

У меня выдает:
Bus errror
когда руками его стартую.
Может у кого осталась старая версия mgcamd-a? Выложите плз.

Спасибо.

P.S. Обновился ...... .

[nitrogen14]

Re: MGcamd 1.34c (осторожно БАГ- нужно использовать replace.list)

1.читай красную тему
2.посмотри какую версию эмулятора ты скачал и не пиши в непрравильной теме