дядя Фёдор

было бы нелогичным, чтобы плейер в нынешнем его, просто убожеском, состоянии вдруг начал понимать субтитры. думаю, этого прийдется ждать очень долго, если вообще когда либо произойдет в прошивках на основе DGS.

нет. это корявость корейских программистов. может, в будущем поправим.

На самом деле все еще проще. На прошивке PGI 0.4(a) не нужно ни 2а (там этого файла нет вообще) ни 2b. Просто удалить все разделы диска на PC, вставить диск и прошивка его отформатирует автоматом как нужно. При этом учтите, что процесс форматирования может длиться до 15 минут.

Ребята, обсуждение 3х разных эффектов под видом одного и того же не приведет ни к чему, кроме бессмыслицы. - Веб ТВ всегда будет оставать, потому что происходит дополнительная передача данных по сети и декодирование потока на компьютере - Улучшайзеры Филипсов известны задержкой до 300мс. У меня лично такой стоит. В компьютерные игры невозможно играть поэтому на таких. А эхо уже будет заметно от 60мс. - Особенности работы софта IPBox вызывают задержку в выводе картинки. Происходит буферизация данных (не знаю для чего, возможно для таймшифта и для веб-тв), поэтому на ТВ идет вывод канала с небольшой задержкой. С этим ничего сделать нельзя, кроме как купить другой ресивер, если это создает неудобства.

Всех тех, кто празднует вчера-сегодня-завтра Рождество, с Праздником! И небольшое объявление, по поводу грядущих планов. PGI 0.4a со всеми известными фиксами будет, если не сегодня или завтра, то послезавтра. PGI 0.5 будет где-то в январе, скорее, ближе к началу, чем к концу В PGI 0.5 скакать по категориям каналов можно будет кнопками PgUp PgDn, а кнопки "вправо" и "влево" будут листать постранично. Это окончательно, бесповоротно, и не подлежит обсуждению ;) Опции "или так или так (по выбору)" в ближайшее время не будет. Когда решим другие проблемы, может быть вернемся к этому моменту. В PGI 0.5 должно быть исправлено все что вылезло боком в 0.4 (фиксированный IP, DVB-C тюнер, автомонтирование и NFS, запрос PIN, инициализация CI) плюс будет пара очень полезных новых фиксов, которые уже давно пора было сделать в оф. прошивке, но корейцы глухи в этом плане. Хочу сообщить заранее, что этот релиз 0.5 вообще не планировался на начало января, но поскольку вылезли проблемы я немножко напряг Пакко (будем надеяться, он по-прежнему будет дружить со мной) ;) Так что не нужно ожидать решения ВСЕХ проблем (которые были до 0.4 и в официальных прошивках) от релиза 0.5. Настоящие исправления по списку из темы о багах будут происходить по мере свободного времени, начиная с релиза 0.6 (если он когда либо появится )

Я нашел решение проблемы с NFS для PGI. Вот так ручками можно примонтировать NFS: Где XX - номер от 1 до 10 (индекс расшаренной папки) Проблема в том, что PGI, по-умолчанию, без опции vers=, пытается пользоваться протоколом NFSv3, поддержки которого в ядре нет (и никогда не было). А с указанием версии и пары других опций все ок. Попробую модифицировать скрипт для автомаунта с поддержкой NFS.

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

Здесь можно обсуждать всё, что не обсуждается в других темах и не противоречит правилам форума. Другими словами, эта тема для всяких вопросов, ответов и просто любого трёпа, который некуда пристроить. То есть, подходящей отдельной темы нет. Желательно, чтобы всё-таки хоть как-то касалось ресиверов Cuberevo/IPBox или по крайней мере спутникового телевидения.

на первой странице в азбуке описано как менять режим видео выхода кнопками передней панели ресивера без участия ТВ.

Сами вы его никак не отключите. Есть параметр, который глушит диск (при условии, что он аппаратно совместим с ядром Linux) через определенный период неактивности (тайм-шифт, запись и проигрывание - это, понятное дело, активность). Этот период устанавливается в скрипте /var/bin/init.d/1.hdd.start. В конце скрипта есть команда: hdparm -S 10 $PART_MEDIA Важно число, которое в PGI 0.4 равно 10. Число это значит сколько ждать перед засыпанием HDD. Но оно не в секундах и не в минутах. Система довольно странная (и PGI тут ни при чем, это у производителей винчестеров такие замашки). 0 = нет засыпания 1 .. 240 = значение умножается на 5 и получается время в секундах! 241 .. 251 = из значения вычитается 240 и умножается на 30. Полученное значение - в минутах! Потому что Пакко увлекся немножко удалением запроса пароля, когда убирал его для редактирования каналов и для редактирования записей. Думаю, в следующей версии поправим.

Не знаю. Не пользуюсь FAR.

Это не "кваканье" в том определении, как оно известно здесь. Речь шла в прошлом о "сносе крыши" ресиверу, когда после начала кваканья ничего не помогало, кроме ребута. У вас же, скорее всего, проблема с сигналом или шароводом.

У вас есть возможность подключиться к ресиверу через COM-порт для снятия лога? Это бы очень помогло решению проблемы. Пакко сделал ряд изменений в алгоритме выбора тюнера (если их несколько) и видимо новый алгоритм некорректно работает с DVB-C. Прогресс в этой области есть полный, что только может быть. Скорость в прошивках DGS была искусственно занижена до 5MБ/с. В прошивках PGI это ограничение полностью снято. То, что вы видите скорость выше 5, тому доказательство. Почему нет 10? Потому что интерфейс и таймшифт отжирают ресурсы. Выключите ресивер в Standby и попробуйте перекинуть с ресивера файл по FTP - получите искомые 10MБ/c. Делаете поспешные выводы! "перестает работать шара" - этому могут быть десятки причин... Для начала, стоит проверить, что mgcamd запускается. делается командой pgrep mgcamd Если запущен, то смотрим в лог. Если лога нет по сети, но есть доступ по Telnet - меняем mg_cfg для вывода лога в файл или просто запускаем его из Telnet c выводом на консоль: killall mgcamd ; mgcamd А не могли бы вы выложить свой db.dat куда-нибудь? Существует вероятность, что проблема с вашей базой. Узнаю еще раз. Последний раз, когда спрашивал, сказали - нельзя.

PPP никогда не работал. В прошивках корейцев никода не было бинарника pppd. Об этом регулярно им напомниаю, но никто не чешется. Проверим Корейцы заплатили за лицензию AAC только для каналов DVB-T (эфирные). Спутниковые (пока?) поддерживать AAC не будут. Откуда мне знать, что случилось? Такие вопросы нужно подкреплять логами mgcamd. И не в этой теме. И проверьте свои настройки файла mg_cfg, как описано здесь. По-моему, тут все перешли на новую, до того как она вышла ;) Попробуйте здесь: http://www.dreambox.info/dreamboxdb/board.php?boardid=216 Это бывает при неправильном выключении ресивера или если паника возникла не в том, где нужно месте. Пакко написал скрипт для лечения этой проблемы. Скрипт восстанавливает MAC в памяти EEPROM при выключении ресивера. Нужный MAC прописать в файл /var/etc/my.ethaddr в следующем формате: xx:yy:zz xx, yy, zz - это три последних байта MAC адреса. Первые 3 менять нельзя. Без модификации исходников (которых у меня нет) такое невозможно. Другой вариант - это отдельный плагин. Попробую заняться в следующем году. Может быть. А вообще-то это опять не для этой темы вопрос. Есть тема по хотелкам и багам для таких вещей.

Вот скрипт. Скопируйте его в /var/bin. Как его прикрепить на цветную кнопку, см. ЧаВо в азбуке. http://rapidshare.de/files/48854645/changemode.zip.html

Ничего страшного, пойдет. Не путаем параметр CWS_KEEPALIVE из newcamd.list и параметр Q: И для того чтобы работал Q, нужен обязательно N: {7} .... Покажите лог, где по-вашему "часто коннектится". Когда вы смотрите открытые каналы, ничего никуда не может коннектится. Идет только пинг с интервалом, указанным в CWS_KEEPALIVE из newcamd.list.

http://tinyurl.com/yeukq3k А вообще-то проще всего запустить его - там прекрасный HELP.

Каким боком это имеет отношение к e2 на IPBox? Есть масса других тем о ключах и настройках эмулятора!

для начала, убедиться, что у вас есть в локальной сети (к которой ресивер, надеюсь, подключен) есть устройство, которое раздает IP адреса по протоколу DHCP.

теоретически можно для любой прошивки на основе 11102. только я вас предупреждаю, что не виноват, если вам все заново придется перешивать.

ГРАНДИОЗНЫЕ НОВОСТИ! Похоже мы с Pacco продвинулись еще на один шаг в теме кваканья! Сегодня после целого дня совместных экспериментов у нас есть некая уверенность утверждать, что мы сумели победить кваки. По крайней мере на 9000HD. Это нуждается в подтверждении, но лично я пока заставить квакать ресивер не смог своими стандартными тестами. Нужна помощь и тщательное тестирование. Проверить мы не можем вообще на 910/900, поэтому полагаемся на вас, друзья. Загружаем нужный файл и прошиваем как обычную прошивку. Затирается только ядро, поэтому все настройки должны остаться на месте. Но, на всякий случай, сделайте резервную копию ваших каналов и настроек. После первой загрузки может быть паника - это нормально. Проверяем все пакеты вместе с mgcamd (Радуга, Поверхность, Орион, Немецкий Скай, Греческая Нова, Немецкий Кабель Дойчланд) Поведение с мультибутами непредсказумо!

Как настроить priority.list / ignore.list / replace.list для mgcamd Подразумевается, что вы полностью понимаете смысл происходящего при работе mgcamd и умеете читать и понимаете лог файл. Если это не так, читайте все, что находится выше. Итак, вы обнаружили, что некоторые из ваших каналов открываются почти мгновенно, а некоторые через 5-10 секунд, а иногда и дольше. Одна из причин такого поведения заключается в том, что некоторые каналы кодируются не одной, а несколькими кодировками или провайдерами, поскольку одни и те же каналы на спутнике могут входить в разные пакеты или у некоторых провайдеров совпадают CAID:ProvID и запрос идет "не по адресу". Получается, что один и тот же канал, в принципе, можно открыть совершенно разными картами, но на сервере обычно, доступна какая-то одна из них, а не все возможные карты. При включении канала mgcamd смотрит какими кодировками и провайдерами закодирован канал и начинает перебирать PIDы (комбинации карта+провайдер) по-порядку. Если получится так, что PID, который открывает канал, не первый в этом списке, то возникает задержка, пока mgcamd доберётся до нужной карты и откроет канал. Для избежания такой ситуации служит файл ignore.list, где можно указать какие CAID и/или ProvID нужно игнорировать, чтобы нужный вам PID (т.е. комбинация CAID+ProvID) оказался на первом месте в списке. Ещё хуже, когда у вас коннект на несколько разных серверов (или портов) шары и из за того, что у некоторых провайдеров одинаковые ID для разных пакетов, запрос от вас может вообще пойти не на тот сервер, из-за того, что нужный именно для ЭТОГО канала PID стоит не на первом месте в списке PIDов. В таком случае каналы могут вообще открываться по 10 и 20 секунд и больше (смотря как настроены тайм-ауты mgcamd), пока от сервера куда пошёл запрос "не по теме" не прийдет отказ. Для избежания такой ситуации используется файл priority.list. Для более сложных ситуаций, иногда приходится использовать оба файла в комбинации друг с другом, хотя это необязательно, вопреки тому, что иногда пишут на форумах. Оба файла не зависят друг от друга, но файл ignore.list берет верх над priority.list. Поэтому бессмысленно иметь в этих файлах одинаковые записи. Файл replace.list используется для "супер-тонкой" настройки, когда вы хотите достигнуть идеальной ситуации с открытием каналов (для чего придется немного попотеть, зато результат будет стоить того). Так какой же результат можно считать идеальным? Какова финальная цель всего этого мероприятия? Ответ прост - для каналов, у которых в потоке кодирования больше, чем один PID (то есть, грубо говоря, для каналов, которые кодированы сразу несколькими кодировками) наша цель - это используя файлы ignore.list/priority.list/replace.list сделать так, чтобы в списке PIDов остался только один, который откроется картой, доступной нам именно для этого канала. В очень редких случаях, цели могут быть другими, но когда вы поймете систему, вы разберетесь сами по обстоятельствам. Рассмотрим на конкретных примерах с нарастающей сложностью. Ценный совет: 1) Использование ignore.list для запрета карт Допустим, мы смотрим исключительно один пакет каналов, переключаемся на кодированный канал этого пакета и видим в логе mgcamd такое: Из строк, начинающихся с ECM видно, что канал кодируется двумя кодировками: Viaccess (PID=040A) и Irdeto (PID=07F2), и первой в списке у нас идет кодировка Viaccess. К сожалению, у нас нет ни подходящего ключа в SoftCam.Key, ни доступной карты Viaccess, о чем свидетельствуют собщения "No viaccess key(s) found..." и "network can't decode". Дальше видно, что у нас есть доступная карта Irdeto c CaID=0654, мы обращаемся к ней и получаем ключ. Что здесь можно улучшить? Можно сказать mgcamd, что поскольку у нас нет и не будет карты Viaccess (c CaID=500), нужно просто игнорировать все PIDы с такой картой, чтобы они "не мешались под ногами". Создаем файл ignore.list и пишем в него следующее: X: {0500} Иногда 0500 разбивают на пары цифр через пробел. Для mgcamd это непринципиально: Х: { 05 00 } Перезапускаем наш mgcamd, снова включаем тот же канал и видим теперь следующее: Больше нет никакого упоминания о карте Viaccess. Больше нет никаких побочных действий, и проб, и ошибок. Запрос ECM идет сразу, куда нужно, без задержек. Цель достигнута. Что мы сделали? Cтроки, начинающиеся с X: в файле ignore.list (их может быть сколько угодно), означают что для всех каналов нужно игнорировать все PIDы, где CaID=0500. То есть, по сути дела, мы полностью запретили использование любых карт Viaccess: mgcamd теперь просто не будет видеть эту кодировку вообще. Осталось прощелкать по всем каналам нашего пакета и убедиться, что для всех каналов теперь находится только один PID с кодировкой Irdeto. Если возникают еще какие-то "левые" CaID, заносим их также в ignore.list по аналогии с Viaccess. 2) Использование ignore.list для запрета провайдеров Польза от первого примера больше академическая. Понятно, что взять и запретить полностью все карты Viaccess - это мало кому пригодится. Шансы того, что вам понадобится карта Viaccess для того или иного пакета, в наши дни довольно велики, так как на оди и тот же CaID может быть куча разных провайдеров. В таких случаях мы можем использовать ignore.list для игнорирования только ненужных нам провайдеров той или иной кодировки, а не всю кодировку целиком. Для примера, откроем один из каналов, где есть больше чем один PID с кодировкой Viaccess, но нужный нам - только один: Из этого куска лога видно, что открывается канал только картой провайдера Viaccess, у которого ProvID=024400. Все остальные провайдеры нам не нужны и только замедляют открытие канала. Поэтому исключим их, используя такой файл ignore.list: V: {032920} V: {020810} S: {003D} V: {025100} Проверим теперь (после рестарта mgcamd) что имеется у нас в логе после переключения на этот же канал: Все ненужные провайдеры испарились, остался только один единственный, нужный, и канал открывается быстрее! Вы заметили, что в этом примере мы использовали тот же файл ignore.list, но разные буквы в начале строк. Все варианты строк для ignore.list приведены ниже: X: { XXXX } # для глобального игнорирования карт с CaiD=XXXX V: { VVVVVV } # для глобального игнорирования провайдеров Viaccess (у которых CaiD=0500) S: { SSSS } # для глобального игнорирования провайдеров Seca/Mediaguard (у которых CaiD=0100) I: { IIII } # для глобального игнорирования чидов Irdeto (у которых CaiD=06xx) Всё прекрасно, но бывают ситуации посложней. Представим, что у нас есть 2 разных пакета каналов A и B. Пакет A открывается провайдером X, а пакет B открывается провайдером Y. И при этом, пакет А также может открываться провайдером Y в принципе (то есть, присутствует ECM для провайдера Y), но не именно той картой, что доступна нам. Получается так, что если глобально запретить провайдера Y, чтобы он не мешался под ногами для пакета A, то пакет B вообще перестанет работать. Если не запрещать Y, то каналы будут открываться медленно в пакете A, потому что если не повезет, то при открытии канала A, сначала будет пробоваться провайдер Y и только потом уже провайдер X. Для борьбы с подобной ситуацией есть два способа. Первый, с использованием файла priority.list, второй - с использованием файла replace.list. У обоих методов есть преимущества и недостатки. Рассмотрим их по-порядку. 3a) Использование priority.list для изменения порядка PIDов Вот кусок лога, где мы включаем канал с несколькими провайдерами Viaccess: Из лога видно, что канал открывается провайдером Viaccess 023B00, и при этом очень долго. Получилось так, что первыми идут PIDы с другими провайдерами, один из которых (024100) нам тоже доступен, но для другого канала. Поэтому начинают идти запросы не на ту карту, которая, естественно, в ответ молчит. А на экране темно (иногда очень долго темно в зависимости от настроек в mg_cfg), пока mgcamd не перейдет к следующему, правильному PID. Все бы ничего, но взять и избавиться от "неправильного" провайдера 024100 мы не можем, потому что он нам нужен для другого канала, и если мы просто впишем его в ignore.list, то другой канал у нас работать не будет. Исходя из этого, нам нужно решить проблему приоритета PIDов. Нужно сделать так, чтобы провайдер 023B00 шел первым в списке PIDов. Это позволит сразу пробовать правильный PID для открывания канала. Пусть даже останутся другие PIDы, до них очередь не дойдет, потому что сразу придет нужный ответ от сервера. Для глобального изменения приоритета провайдеров используется файл priority.list. В нашем случае нужно занести в него всех провайдеров, которые у нас есть в списке ECM, в той последовательности, в которой мы хотим чтобы шел их перебор. В нашем случае, нам нужно оставить 2 провайдера: 023B00 и 024100 (остальные можно в ignore.list, чтобы не путались под ногами). Нам также нужно, чтобы 023B00 имел приоритет над 024100. Поэтому создаем два файла: ignore.list: V: {020810} priority.list: V: {023B00} V: {024100} Перезагружаем эмулятор и снова включаем тот-же канал. Теперь видим такое: У нас осталось 2 провайдера и первым идет тот, что нужен - запрос сразу идет на нужную карту без промедления. Ценный совет: Самая нехорошая ситуация возникает, когда у нескольких каналов есть два (или более) провайдера и оба эти провайдеры нужны (запретить их нельзя). Более того, для одной части каналов нужно чтобы в приоритете был один провайдер, а для другой части каналов - другой провайдер. Если мы будем пользоваться только файлом priority.list, то только одна часть каналов будет иметь правильный порядок провайдеров, а другая часть всегда будет натыкаться на ненужный PID. Это происходит потому что настройки из priority.list глобальны, и с помощью этого файла нельзя сказать: "вот этим каналам - такой нужен приоритет провайдеров, а вот этим каналам - другой". На помощь приходит файл replace.list Что позволяет файл replace.list, в чем его суть? Он позволяет "волшебным образом" заменять CaID и/или ProvID и/или PID отдельно взятого канала на любые значения! Сперва можно подумать, мол, "зачем это вообще нужно?" Но на самом деле, это позволяет произвести тончайшую настройку PIDов для каждого канала персонально! При этом, по сути дела мы можем имитировать функциональность и ignore.list, и priority.list, используя только replace.list. Вы спросите, зачем же тогда вообще нужны ignore/priority, если можно гораздо точнее все настроить и без них? Недостаток replace.list в том, что если вы решите пойти таким путем, то вам придется прописать в этот файл по строчке для каждого кодированного канала. По одной строчке на каждый канал, это если в потоке канала только 2 PIDa, а если в потоке канала больше чем два PIDа, то на каждый канал нужно будет прописывать несколько строк (чтобы конфигурация PIDов была идеально "чистой"). Для ленивых - это точно неподходящее занятие. Те, кто готов потрудиться, будут вознаграждены самым быстрым возможным открыванием каналов, без задержек, железно, на 100%. 3b) Использование replace.list для упорядочивания PIDов (альтернатива priority.list + ignore.list) Возьмем пакет каналов где используются три разных провайдера Viaccess: 023700, 020710 и 030600. Для одной части каналов нужен один провайдер на первом месте, для другой части каналов - другой, а для HD - третий. Если просто вписать их в priority.list (как это часто советуют на форумах), то хорошо будет только одной из этих трех частей каналов. Две же других части будут напарываться каждый раз на ненужный PID, а одна из трех частей (самая невезучая) будет напарываться на целых 2 ненужных PIDa. Запретить провайдеров с помощью ignore.list тоже нельзя, тогда просто перестанет открываться часть каналов. Вот тут и приходит на помощь replace.list! Включим для примера HD канал (без ignore.list и без priority.list) и увидим в логе такое (все данные, которые нам потребуются для создания replace.list выделены): Видно, что первым попадается провайдер 023700, который не работает (идет запрос на сервер, но он нас посылает подальше). Видно, что в конце концов канал открывается по PIDу 0BBB, у которого карта=0500 и провайдер=030600. Создаем новый файл replace.list и пишем в него следующее: Что это значит? Это значит, что мы предписываем mgcamd следующее: Для канала, у которого Service ID (или SID) = 2F47, поменяй PID с параметрами CaID=0500, ProvID=023700 и CaPID=0FA3 на PID, с параметрами CaID=0500, ProvID=030600 и CaPID=0BBB. Что получается при перезапуске mgcamd? А вот что: [mg0] stoping camd.. [mg0] service 2F47 index 0 pmt pid 0 (45) ECM: CaID: 0x0500 -> CaPID: 0x0BBB ProvID: 030600 [mg1] service 2F47 already started with index 0 [mg1] service 2F47 index 1 pmt pid 0 (46) [mg0] -> ECM to newcamd server1.com:1234 [mg0] <- CW from newcamd server1.com:1234 (174ms) [mg0] 174 msec -- Wed Jun 10 01:15:31 2009 ===== Viaccess ECM on CaID 0x0500, pid 0x0bbb ====== prov: 030600 cw0:0 78 03 FF 7A 67 98 00 FF сw1:0 DF 33 18 2A 19 3E 1F 76 Одной строчкой в replace.list мы сделали сразу две вещи: 1) убили ненужный PID 2) превратили убитый PID в правильный, который работает Только нужно помнить, что это мы сделали для одного единственного канала! У каждого канала на отдельно взятом транспондере всегда свой уникальный service ID (SID). Поэтому, для полного счастья поступаем таким же образом для остальных HD каналов, открывающихся по провайдеру 030600, и получаем вот что в replace.list для пяти каналов: R:{{2F45}{0500}{023700}{0FA1}{0500}{030600}{0BB9}} R:{{2F46}{0500}{023700}{0FA2}{0500}{030600}{0BBA}} R:{{2F47}{0500}{023700}{0FA3}{0500}{030600}{0BBB}} R:{{2F48}{0500}{023700}{0FA4}{0500}{030600}{0BBC}} R:{{2F49}{0500}{023700}{0FA5}{0500}{030600}{0BBD}} Теперь для этих пяти каналов будет совершенно не важно, что вы напишете в priority.list, ведь мы практически создали "локальный" ignore и priority специально для этих каналов, в результате чего всегда будет оставаться только один нужный PID.

Как увидеть и распознать проблему, используя лог Рассмотрим теперь проблемные ситуации, когда все должно вроде бы работать, но не работает. Или работает, но не так как хотелось бы. Во первых, нужно убедиться, что mgcamd вообще для начала пытается подсоединиться к серверу при начальном запуске (обычно во время старта ресивера). Это должно выглядеть так: Этих строк должно быть по две на каждую строку "CWS=" из newcamd.list. Если таких строк нет, то проверяйте ваш файл newcamd.list. Проверьте, чтобы файл находился там, где ему положено и имел правильный формат. Во-вторых, по какой угодно причине может отсутствовать доступ к серверу. Либо из-за проблем с Интернетом (включая неверные настройки вашей домашней сети), либо из-за глобальных проблем на сервере, либо из-за проблем лично с вашим логином (не на тот сервер или порт коннектитесь, отключены за неуплату или по причине бана из-за нарушения правил пользования). Во всех этих случаях вы получите в логе нечто вроде такого: Чтобы убедиться, что связь с сервером есть, нужно зайти на ресивер по Telnet и дать команду ping server1.com, где server1.com нужно поменять на имя или IP адрес вашего сервера. Остановить команду можно, нажав CTRL+C. Если ответа не придет, то нужно смотреть что у вас с Интернетом (в крайнем случае, если пингуются другие адреса, кроме вашего сервера, то скорее всего сервер мертв). Если ответ есть, то нужно выяснить почему вас сервер не пускает (не тот логин или пароль; не тот сервер, если их несколько у провайдера; повторный логин одновременно с уже активным логином, бан на сервере и т.д.) В-третьих, допустим все заработало, вы смотрите канал, и вдруг, ни с того ни с сего картинка и звук останавливаются и продолжаются чере несколько секунд (или через несколько десятков секунд). Открываем лог, а там что-то вроде такого: Здесь приведено классическое определение "затыка". Это когда либо по причине плохого качества связи, либо по причине проблем на сервере вам не приходит во время или вообще не приходит ответ на ECM-запрос. В здешнем примере мы видим, что сервер ответил только с 4-го раза, при этом ключ поменялся уже два раза (или больше): "WARNING, both cws changed !". Бороться с затыками можно только двумя способами: улучшать качество Интернет коннекта или (если вы уверены, что с Интернетом у вас все впорядке) менять провайдера шары. Простейший тест на предмет "где затык: на сервере или в Интернете?" состоит в запуске команды (из ресивера) ping server1.com, или (из Windows) ping -t server1.com, где server1.com нужно поменять на имя или IP адрес вашего сервера (остановить команду можно, нажав CTRL+C). Нужно, следить за результатами ping во время просмотра канала и одновременно смотреть лог mgcamd. Как только вы увидите в логе mgcamd, что на запрос ECM нет ответа нужно сразу же смотреть на результаты ping, есть ли потери и там. При этом картинка на экране ТВ - это не показатель затыка, так как изображение продолжается еще некоторое время, даже без ответа от сервера. Если есть потери данных в ping (команда перестает выдавать информацию в этот момент в Linux или выдает "Request timed out" в Windows), и, особенно, если это происходит в момент затыка, то, скорее всего, сервер тут ни при чем - улучшайте свой Интернет коннект. Если же ping идеальный, без потерь и с более-менее одинаковым временем отклика при каждом запросе, то у вашего шаровика проблемы (перегруз карты, криво настроен софт, и т.д.). Так выглядит идеальный ping c 0% потерь: Так выглядит плохой ping с потерями и плохим коннектом: Когда возникает затык, подобный описанному выше, два параметра настройки mgcamd являются очень важными в плане того, как mgcamd будет реагировать на затыки (что по сути дела значит, как скоро можно ожидать возвращение картинки на экран). Это параметры K:{} и N:{} из файла mg_cfg. Параметр K:{} описывает какое максимальное количество времени (в секундах) нужно ждать ответа от сервера на ECM запрос, по истечении которого mgcamd решает, что ответа нет. Чем больше это число, тем больше шансов получить ответ, если у вас плохой Интернет или глюкавый сервер шары. Кроме того, еще зависит от того, какие пакеты вы смотрите. Большинство карт обычно отвечают меньше, чем за 1 секунду. Но есть некоторые карты, где нормальное время отклика 1-2 секунды. В экстремальных случаях (известный пример - пакет Nova), ответ может приходить и за 3-5 секунд. Естественно, если вы установите K:{} равным 1 секунде, а сервер будет пытаться вам ответить через 2-3 секунды, то ничего хорошего из этого не выйдет. mgcamd все время будет думать, что сервер не ответил (по истечении секунды) и слать запросы повторно. От этого будет плохо всем, в основном, конечно, серверу, который будет завален запросами, ну и ресиверу тоже, который будет работать в таком случае неоптимально. С другой стороны если взять и увеличить параметр K:{} на неразумно большую величину, типа 5 или больше секунд, то возникнет совершенно неблагоприятный эффект для вас. Представьте, что обычно вам ответы приходят за 0,5 секунды, и один раз ответ по какой-то причине не пришел. Теперь вы будете ждать целых 5 секунд, до тех пор, пока mgcamd не попытается снова послать запрос. За это время на некоторых каналах уже может случиться и затык, в то время, как если бы у вас повторный запрос пошел через, скажем, 2 секунды и пришел бы успешный ответ, никто бы ничего (на экране ТВ) не заметил! Грубо говоря, когда есть проблемы с ответами от сервера, то чем меньше K:{}, тем хуже серверу шары из-за большего количества запросов, и чем больше K:{}, тем вероятнее вы получите затык. Хотя это все очень относительно и сильно зависит от конкретных пакетов. Есть пакеты (Премьера HD, Скай Италия и т.д.), где время ответа от карты критично. Для таких пакетов с кодировкой Videoguard, если вы не получите ключ за 0.6сек, то будет однозначный затык. Здесь можно спокойно ставить единицу в значение K:{}. С другой стороны, для таких пакетов, как Премьера SD или Nova и 2х секунд иногда недостаточно, и правильным значением должно быть 3. Ценный совет: Дальше, параметр N:{7} X Y влияет на то, как mgcamd ведет себя когда понимает, что ответ от сервера все же не пришел. Число X устанавливает количество неуспешных запросов на сервер (каждый из них длиной в K:{} секунд), после чего mgcamd отваливается от сервера и пытается к нему приконнектиться заново. Эта процедура нередко помогает, когда на сервере какие-то глюки, хотя конечно, постоянно это недолжно происходить. Параметр Y говорит mgcamd о том, что нужно отваливаться и реконнектиться заново, если не было никаких признаков жизни у сервера в течение Y секунд. Обычно до Y доходит дело крайне редко, потому как реконнект обычно происходит из за параметра X (в комбинации с K:{}). Лучше всего смотреть в логи, анализировать происходящее и подбирать параметры под свою конкретную ситуацию.

Что можно увидеть из лога? Увидеть можно очень много! Практически всё! ;) Для начала, собственно, старт mgcamd. В этом примере мы сделаем вид, что у нас прописано два разных сервера в newcamd.list. Первый сервер называется server1.com и у него порт 1234, второй - server2.com с портом 5678. Для логина на оба сервера используется имя username (пароль в логе не отображается). Итак, пример лога: Отсюда уже сразу видно много интересного. Во-первых, видны типы карт, которые шарятся (число сразу за "caid"). CAID - это идентификатор карты, а точнее идентификатор системы защиты, которую использует карта. Вот список наиболее часто используемых идентификаторов: 01xx = Mediaguard/Seca 05xx = Viaccess 06xx = Irdeto 09xx = NDS Videoguard 0Bxx = Conax 0Dxx = CryptoWorks 17xx = BetaCrypt 18xx = NagraVision 2600 = BISS 4Axx = DreCrypt (который mgcamd обзывает как @Sky в своих логах) Там где стоит xx может быть любое число, которое может обозначать версию системы защиты или, скажем так, разновидность этой системы защиты, иногда заточенную под определенную вещательную компанию. Из примера выше видно, что мы подключились к двум серверам. Первый шарит несколько карточек с кодировкой Viaccess (потому что CaID 0500 начинается с 05xx). Также видно какие именно провайдеры карт шарятся - их 4 штуки. Это становится ясно из поля Idents, которое перечисляет все идентификаторы провайдеров Viaccess. В чем смысл понятия "провайдер" и "Provider ID" (Ident) в этом контексте? Систем кодирования не так уж много (см. список выше для примера), но у каждой системы защиты есть разновидности (различные версии одной и той же системы защиты, различные виды карт определенных пакетов каналов и т.д.) Чтобы различать между такими картами, помимо основного CAID вводится еще один идентификатор, который обозначает уже вполне конкретную карту с конкретным пакетом каналов. Скажем так, "карта плюсовиков последнего выпуска", а не просто "карта Виаксесс". Впрочем, для некоторых кодировок провайдер (Ident) всегда равен 00000, и там обходятся только CAID (таким образом работают Видеогард и Конакс, например). Для Ирдето вместо провайдеров или идентов показывают так называемые ChID (чиды). Видно, что второй сервер шарит карту в кодировке Ирдето (CaID 0654 начинается с 06xx). Выглядит так, что как будто бы тоже несколько провайдеров с идентами 0, 1, 2 и 3, но это только одна карта. Это особенность кодировки Irdeto (и Betacrypt, которая основана на Irdeto). Эти иденты называются чидами (ChID) и действуют также как и ProvID у других кодировок. Разница лишь только в том, что одна и та же Irdeto карта может иметь несколько ChID, а другие кодировки обычно имеют только один ProvID. Говоря проще, отдельная карта всегда идентифицируется двумя числами: CaID и ProvID. И бывает нередко такое, что у одной и той же компании есть несколько разных карт на одни и те же каналы (например, выпущенные в разное время карты или карты на новые пакеты каналов). Нужные комбинации CaID:ProvID для интересующих вас каналов всегда можно взять на сервере. Итак, чтобы подвести предварительный итог, получается, что при включении кодированного канала, у него должен совпасть CaID:ProvID (или CaID:ChID для Irdeto) с теми, что прислал сервер при подключении к нему. Только в этом случае на сервер пойдет запрос "ключа". В такой ситуации mgcamd отошлёт на сервер так называемую последовательность Entitlement Control Message или ECM. Если на сервере всё впорядке, то он должен ответить на такой запрос последовательностью, которая называется Control Word или CW. Если вы получаете правильный код CW, то канал открывается. В зависимости от системы кодирования интервал смены ECM (живучесть ключа) может быть от 2-3 секунд до целой минуты. После чего повторяется ECM запрос и ответ CW и так далее. Посмотрим как это выглядит в логе (важные цифры выделены): Пояснение к происходящему, где важна практически каждая строка. Первые две строки - это стандартное сообщение при переключении канала. У каждого канала есть свой Service ID (SID), который уникален в пакете каналов. Из второй строки видно, что мы включили канал, у которого SID равен 2EA. Дальше имеем две строки, начинающихся с ECM. В этих строках информация о кодировании канала (если канал открыт, то вы никаких ECM не увидите). В нашем примере мы включили кодированный канал, и открывается он либо картой Viaccess (CaID:500, ProvID:022B00) либо картой Irdeto (CaID:654, ProvID:000000). Каждой комбинации CaID и ProvID на каждом отдельно взятом канале присваевается свой уникальный идентификатор: PID. В нашем случае получается, что PID 040C "олицетворяет" SID=02EA, взятый вместе с CAID=0500, вместе с ProvID=022B00. Точно также, PID 07F4 обозначает SID=02EA вместе с CAID=0654 и ProvID=000000. Посмотрим теперь в начало лога, где перечислены все CaID и ProvID, которые нам предлагают оба сервера. Есть ли там хотя бы одна из двух комбинаций CaID:ProvID, которая подходит ко включенному каналу? Есть одна, это - 654:000000, то есть то, что ответил нам server2.com при подключении к нему. К сожалению, у нас нет доступной карты Viaccess 0500:022B00, но mgcamd этого (ещё) не знает, поэтому он будет идти по списку кодировок, пока не наткнется на ту, которая подходит. Из чего следует, что сначала мы смотрим, нет ли у нас уже ключа Viaccess (в кэше или в локальном файле SoftCam.Key): "No viaccess key(s) found for id 22B00 keynr 08". То есть, ключа нет. Дальше мы смотрим, не доступен ли ключ по сети. К сожалению, как мы уже установили, для Viaccess - у нас нет подходящего сервера. Поэтому мы получаем сообщение в логе "network can't decode". Теперь, когда все попытки исчерпаны mgcamd рапортует о том, что нам не удалось открыть канал, используя PID 040С (то есть комбинацию 0500:022B00). Это сообщение "pid 0x040C failed to decode", то есть канал не удалось открыть по кодировке Viaccess. Переходим ко второму PID. Опять смотрим, нет ли у нас уже ключа Irdeto (в кэше или в локальном файле SoftCam.Key): "No irdeto key(s) found for id 0 keynr 00" - ключа нет. Теперь мы смотрим, доступен ли ключ по сети. У нас есть подходящая комбинация, объявленная сервером sever2.com при логине. Поэтому, следующая строка - это посылка ECM-запроса на сервер server2.com. Далее виден ответ от сервера с кодом CW. Ответ пришел за 481мс, на что стоит обратить внимание при проблемах (об этом ниже). Последние 5 строк - подтверждение проделанной работы по запросу на сервер. Показаны кодировка, которая окрылась (Ирдето), идентификатор карты (CaID), идентификатор кодировки (PID), идентификатор провайдера (ProvID), сама последовательность CW0 и CW1, то есть "ключик" к каналу, полученный от сервера и используемый этим каналом ChID (это дело присутствует только у Ирдето). Дальше всё повторяется снова и снова, каждый раз когда меняется ECM.

Как снять лог от mgcamd? Лог - это первое, что нужно исследовать, если что-то не работает. Лог - это первое, что от вас попросят на форуме, если вы захотите помощи. Поэтому, крайне важно знать как правильно и эффективно снять лог с ресивера. Как уже было написано в примере конфига mg_cfg выше - есть 2 способа увидеть лог. Либо заставить mgcamd писать в файл прямо на самом ресивере, либо заставить mgcamd слать тот же лог по сети, скажем на ваш обычный компьютер. В первом случае не понадобится никакого дополнительного софта, и для просмотра лога можно просто зайти на ресивер через Telnet и наблюдать за работой mgcamd в реальном времени, выводя содержимое файла на экран Linux командой tail -f имя-лога. Хотя это кажется самым log-ичным способом, это не совсем так. Это неудобно, потому как во-первых, нужно коннектиться к ресиверу и работать с командной строкой Linux, а во-вторых, лог будет все время расти (хотя и медленно). Если его своевременно не стирать, то в один день просто забъёт всю флеш-память, а это, мягко говоря, лишние хлопоты. Гораздо более удобней просто напросто наблюдать за логом с компьютера, который находится в локальной сети с ресивером, без каких либо логинов в сам ресивер. Для этого нужно просто установить параметр L: { 01 } как показано выше в примере mg_cfg и запустить на вашем компьютере бесплатную программку (просмотрщик сообщений в формате syslog), которая будет принимать сообщения от mgcamd и выводить их в виде лога на экране компьютера. Бесплатных программ для этой цели есть несколько. На большинстве сайтов рекомендуют древнюю программу 3CSyslog, которую можно взять здесь. Архив весит чуть меньше мегабайта и всё работает, в принципе ок. Хотя слишком уж эта программа древняя, без минимальных дополнительных функций. А самый главный её минус в том, что она показывает все сообщения "задом наперед", то есть самые новые сообщения всегда в самой верхней строке. Обычно это удобно, но вот в случае с mgcamd это как раз совсем неудобно (по крайней мере для тех, кто привык смотреть в обычный лог mgcamd). mgcamd выплёвывает в лог по нескольку сообщений на каждую смену ECM/CW и этот "блок" сообщений отображается "задом наперед", что может затруднить понимание происходящего. Рекомендую попробовать другую софтину, написанную нашим человеком, chewbacca c форума sat-expert.com. Для работы, правда, требуется очень немаленькая (232 МБ) библиотека .Net 3.5 SP1, но работает программа ГОРАЗДО лучше и совершенно бесплатно. Можно взять софт здесь: traysyslog_setup.zip Принцип действия этого типа логирования очень простой. mgcamd посылает текстовые сообщения (используя протокол UDP) на IP адрес и порт, который вы установили в параметре L: { 01 } в файле /var/keys/mg_cfg (к слову, стандартный порт для протокола Syslog - 514). Программка на вашем компьютере принимает сообщения с этого порта и выводит на экран. Если программка на компьютере не запущена, сообщения просто будут "растворяться" вникуда без побочных эффектов для ресивера или вашего компьютера (это свойство протокола UDP). Так что такую настройку можно сделать постоянной и просто включать на компьютере Tray Syslog, если понадобится посмотреть отчего там вдруг не работает (или насколько правильно работает) mgcamd. Если вы только поменяли свой mg_cfg и прописали туда IP своего компьютера для отсылки лога, нужно перезапустить mgcamd (если не знаете как это сделать, просто перезагрузите ресивер).