kacy

17 часов назад, He1ix сказал:

Т.е. запись на wicard работала с type=DVBAPI3? Как ты этого добился?

Я не в курсе какой был режим - не шарю в этом. Вместо ответа выкладываю конфиг.

Как я уже писал: Стояло CS="" CAM="WICARD", api3wrapper подгружал модуль в ядро стартуя прямо из start.wicard

Конфиг был такой:
 

Кстати, если будете выпускать новую версию аддона включите в фильтры webif диапазон 172.16.0.0/12, который наравне с 10.0.0.0/8 и  192.168.0.0/16 относится к частным сетям.

Да, прошивка была не последняя RC, а последняя из тех, что не RC - PGI-1.4

wicard стоял этот:

 

19 часов назад, He1ix сказал:

Похоже что у тебя проблемы с HDD. Проверь

Проверку запустил для очистки совести, но сомневаюсь, что там есть проблемы, т.к. при включении mgcamd (на порт ..99) запись идет отлично. Проверил в режиме таймшифта с двумя одновременно записываемыми каналами.

)))) Дал команду mount  и нашел флешку, которую года два считал потерянной. ))))

Спасибо большое. Буду пробовать.

Шаровод не халявный - 1*.?n (полагаю, тебе известно, что проблем у него даже меньше, чем у нашего)

Основные проблемы, не считая остановки при выходе с таймшифта, это периодические зависания при переключении с записывающегося канала на 9Е на канал на 36Е.

Или эпикфейл при включении по таймеру записи.

Но после перехода на режим STAPI проблемы, практически, ушли.

А вот с OSCAM-мом все гораздо хуже. Если в фоне начинает записываться канал, то на просматриваемом начинаются фризы. В режиме STAPI толком пока не пробовал, но тоже есть проблемы.

[dvb]
active = 1
type = STAPI
stapi_pmt_map = pmt.tmp:PTI2;pmt2_1.tmp:PTI1;pmt2_2.tmp:PTI1;pmt1_1.tmp:PTI;pmt1_2.tmp:PTI
filter = dvb
debug = 1

Или это не то?

Викард сейчас довольно стабилен, если не пытаться писать с 9Е. А оно как раз и надо. Потому как Испанию больше мне негде смотреть.

А как ОСКАМ в режим STAPI перевести?

Я хочу напомнить, что в линуксах пока не шарю абсолютно. Что там по феншую, а что нет мне тем более неизвестно.

Пытаюсь разобраться, что к чему в силу сложившихся обстоятельств. Раньше все работало как часы. Причем периодически использовались самые тяжелые режимы: два кодированных канала пишется, а третий просматривается с задействованным таймшифтом (не успеваю доехать домой к началу ЛЧ УЕФА). Ресивер купленный в первый месяц появления его в продаже, за все время завис пару раз. После ухода со сцены MGCAMD зависания стали явлениями регулярнейшими. Причем не только WICARD или OSCAM (последний особенно часто) но и всего ресивера. Отсюда и попытки прикрутить ту или иную версию. Но идет очень туго. Минут 10-15, а то и больше, уходит на каждую строчку скрипта. (чтобы понять что к чему и зачем). Дело осложняется тем, что в инете в основном скрипты BASH рассматриваются, а у нас SH, да еще и сильно урезанная версия, в основном засунутая в BusyBox.

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

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

Следовательно необходимо решить вопрос корректного завершения другого (или других [и такое бывает]) эмуляторов с удалением всех подгруженных модулей ядра, временных файлов, линков и прочего до запуска требуемого эмулятора.

Мне показалось наиболее корректно это сделает соответствующий скрипт с параметром STOP. А т.к. в этом скрипте присутствуют паузы (процессу дается время на его завершение), то лучше перед запуском скрипта убедится в необходимости самого запуска, проверив наличие соответствующего процесса в памяти.

Теперь по критике:

8 часов назад, He1ix сказал:

Потом, в процедуре start ты делаешь вызов другого скрипта с параметром stop.

Ключевое слово здесь другого. Нам же при старте важно, чтобы другие эмули были погашены. Куда же эту процедуру засовывать? В стоповую процедуру неправильно - она не отрабатывает, если текущий эмуль не в памяти потому, что рухнул или запускается впервые. (строка: [ -n "$(pidof $BIN_NAME)" ] && do_stop ). А в случае когда скрипт запускается с ключом STOP, нашему процессу "конкуренты" уже неинтересны, да и не должны быть интересны.

9 часов назад, He1ix сказал:

Т.е. в твоем случае при запуске ресивера стартовый скрипт cs.start запускает api3wrapper, потом из него стартует "start.wicard" c параметром "-q", который пытается найти и прибить mgcamd, oscam и перегружает только что запущенный  api3wrapper (выгружает и снова загружает api3.ko) и только после этого стартует wicard.

Нафига такие извращения?

Я же написал, что это старый скрипт. А он запускался при CS="", поэтому api3wrapper не запускался до запуска start.wicard -q.  В сам api3wrapper в кейс restart я добавил проверку наличия модуля в ядре. Строка unload_device теперь выглядит так:

lsmod|grep api3 &>/dev/null && unload_device

Поэтому, при старте, попытки выгрузки еще не загруженного модуля api3.ko не происходит.  Соответственно никаких извращений нет.

В дальнейшем рестарт api3.ko в стартовой секции очень даже нужен потому, что в половине случаев при пропадании картинки простая перезагрузка викарда не помогает. Лечится только перезагрузкой api3.ko с последующей перезагрузкой викарда.

12 часов назад, He1ix сказал:

Гораздо грамотнее было бы на мой взгляд сделать кнопочку "остановить эму", например только через меню плагинов через ПДУ по  кнопке WWW. Ну создай файл "/var/bin/scrplg-stop-emu.sh", chmod 755 (аттрибуты), в нем 3 строчки сделай

Это есть, только по другому реализовано (StopAll), но через www, - долго и не очень удобно. Есть желание сделать, или чтобы кто-то другой сделал - на желтой рестарт текущего эму, а на зеленой смена эму (циклический перебор, если больше двух. Но это маловероятно, что понадобится).

Процессы в состоянии блокировки не завершаются по SIGKILL, как и процессы-зомби.

Я же и писал, что сначала надо попытаться корректно завершить, а уже потом kill, если не понимает по-хорошему.

Wrapper я у себя перезагружал. Вот мой старый скрипт:

#!/bin/sh
# title:Restart Wicardd
BIN_NAME="wicardd"

do_stop() {
	/var/bin/api3wrapper stop
	echo -e "Stopping $BIN_NAME...\c"
	killall $BIN_NAME &>/dev/null
	sleep 1
	killall -9 $BIN_NAME &>/dev/null
	echo "done!"
	rm -f /tmp/*info /tmp/ca_cache.list
}

do_start() {
	pgrep mgcamd &> /dev/null && /var/bin/start.mgcamd stop
    pgrep oscam &> /dev/null && /var/bin/start.oscam stop
    /var/bin/api3wrapper restart
	echo -e "web_show_mess 3 \0042Starting Wicardd...\0042" >/dev/commander
	sleep 1
	/var/bin/$BIN_NAME -d -c /var/etc/wicardd.conf &>/dev/null
	sleep 1
	[ -n "$(pidof $BIN_NAME)" ] && echo "done!" || echo -e "web_show_mess 3 \0042Error: could not start $BIN_NAME!\0042" >/dev/commander
}

[ ! -f "/var/bin/$BIN_NAME" ] && echo "$BIN_NAME is not found in /var/bin" && exit 1
[ "$1" != "-q" ] && [ "$1" != "stop" ] && echo -e "web_show_mess 3 \0042Preparing...\0042" >/dev/commander
[ "$1" = "stop" ] && echo -e "web_show_mess 3 \0042Stopping $BIN_NAME...\0042" >/dev/commander
[ -n "$(pidof $BIN_NAME)" ] && do_stop
[ "$1" != "stop" ] && do_start

 

Что конкретно я перепутал?

Я написал, что перед запуском эмулятора, т.е. в функции do_start(), надо проверить и поубивать, если таковые имеются, процессы альтернативных эмуляторов.

Получение сигнала Kill процес отрабатывает далеко не всегда, и ты сам в этом убеждался на практике.

Я попробую в скриптах разобраться, но слишком это внове для меня.

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

Во-первых, эти строчки не там. В do_stop()  oscam-a надо останавливать oscam, а не все три. Альтернативные процессы надо прибивать в  do_start().

Во-вторых, прежде, чем килять процес надо проверить его существование (через pidof у меня не всегда срабатывает, а вот через pgrep всегда)

В-третьих, останавливать процесс надо, посылая сигнал SIGTERM  (killall -15 wicard), а не сигнал SIGKILL (killall -9 wicard).

Вернее, сначала  SIGTERM  (killall -15 или просто killall, т.к. 15 - значение по умолчанию), дать время на корректное завершение процесса, проверить процесс на существование и если процесс все еще в памяти, тогда уже SIGKILL.

Я думаю, что killall -9  с wicard'ом может не прокатывать потому, что в тот момент, когда ему прилетел SIGKILL, wicard вполне может находится в состоянии ожидания ввода-вывода и, соответственно, в этом состоянии ему этот SIGKILL "до лампочки".

Добрый вечер.

Есть пара вопросов по новому Add-on:

1) Если собственных карт нету, надо ли в CS указывать OSCAM (WICARD), и если да, то зачем?

2) Это допустимо, что при переключении эмуляторов, старый остается висеть в процессах? Может в функцию do_start() например, для oscama, добавить:

 pgrep mgcamd > /dev/null && /var/bin/start.mgcamd stop
 pgrep wicardd > /dev/null && /var/bin/start.wicardd stop
 

@wsnake, я Вас и не просил проверить возможность Полного выключения.

Я просил проверить - сохраняется ли база при корректном полном выключении Вашего тюнера.

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

Попробуйте перезагрузку через "Полное выключение". Помнится мне, были приколы с "не обновлением" базы каналов, почти всегда, если перезагрузка выполнялась кнопочкой в PCeditor, и иногда, если с пульта. Через "Полное выключение" все всегда ОК.

Возможно, изменения в базе (как справедливо заметил ProFanas, данные расписания записи хранятся в общей базе в таблице sheduledinfo) в какой-то из веток алгоритма не сохраняются. Забыли comit, или ожидание его выполнения в код забить. Правда, там же все сложнее. Как минимум одна из записей полностью или частично должна копироваться в аппаратный "будильник" для включения ресивера по таймеру из режима полного выключения.

Насчет, переполнения базы, не уверен. У меня база "тянется" с самых первых версий PGI, возможно даже с более давних времен - лень повороткой полтора десятка спутников ловить, и ничего - не переполняется. Правда, я регулярно сжимаю базу PCeditor-ом.

...Обычно /var полностью "переформатируется" при прошивании имиджа во флеш и ничего делать не надо....

Спасибо. Перепрошью 1.4

Кстати, после нескольких попыток загррузить ресивер (около 5) система загрузилась создавши новый db.dat.

В /var появился файл db.dat.err размером 95 кб, рабочий файл весил 170 кб.

Спасибо.

Похоже внутренняя флеш загибается.

Как бы ее проверить?

Я так понимаю, надо /var проверить, но ни размонтировать, ни перемонтировать только для чтения (mount -o remount ro -t jffs2 /var) не получается.

Д.Федор, где можно найти коды ошибок PGI?

Поймал ERR79 сразу после LOADING. Траблу предшествовало зависание в диалоге установки таймера сна.

Нашел упоминание о такой ошибке только на ab-forum.info, но к сожалению не силен в словацком.

Что-то я стал испытывать проблемы с вызовом меню по длительному нажатию кнопки POWER.

Батарейеи свежие поставил - непомогло. Да и не в батарейках дело. Если долго держать кнопку - свет в комнате включается (стоит хитрый выключатель с ИК управлением, отличающийся низкой чувствительнстью).

Это я к тому, что сигнал с пульта достаточно мощный.

снова ставлю 1.2 ...

Поставьте 0.9 на флешку, а лучше и 1.2 для тестов туда же, прошейте и настройте мультибут. Слава Богу (и д. Федору) на этом форуме все инструкции для этого есть.

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

Например, тестирование с почти пустыми базами - 1 транспондер отсканирован.

... почему при включеном таймшифте данные не перезаписываются? Флешка 8 гиг один раз заполняется под завязку и далее - "диск переполнен".

Перезаписываются, только не все временные файлы удаляются. Настройте регулярную очистку.

И длительность буфера таймшифта подобрать эксперементально.

Я думаю, флешку надо на несколько разделов разбить. Основная часть под таймшифт, остальное под SWAP и EPG, чтобы таймшифт не мешал функционированию остального.

А не, если эту базу опять выгрузить на комп и начать заливать обратно в ресс, то так-же будет вылетать сообщение, что у вас старая баз. Увы это самообман!

Это глюк PCEditor-а. Реально в базе прописана новая версия R13489.

В этом, собственно, и конвертация заключалась - update options set value="R13489" where name="schema_revision";

...дайте такую команду в Telnet:

sqlite3 /var/db.dat 'DROP INDEX idx_grp_seq; CREATE INDEX idx_grp_seq ON FAVListInfo (grp_id, seq);'

У меня в базе нет индекса idx_grp_seq.

Не вижу также индексов таблиц каналов, транспондеров. Раньше точно были.

Какие вообще должны быть сейчас индексы в базе?

У меня другой ресивер - последовательность другая.

Попробуй импортировать вложение PCEditor-ом.

(Расширение изменить на CSV)

channels_1_.txt

С помощью команды chmod в telnet, либо через меню FTP-клиента.

Подробно: http://chmod.ru/

Сам не проверял, но читал неоднократно, что а этом случае под фат32 надо обязательно первый раздел отводить.

В 1.0 диск нужен для свопа, для ЕПГ. Если это работает неправильно - будет подтупливать.

Запись не работает - возможной причиной может быть неправильно настроенный шарик - либо надо увеличить кеширование до пары часов, либо разрешить двойные запросы в случае, если пров за это не банит, либо использовать МГлончер с разными аккаунтами. Скорее всего это в азбуке расписано.

....

Решила видеотеку сделать на одном HDD , подключенном к роутеру асус wl500

....

На этих ресиверах софтовые пееры - слабое место. Для здоровья дешевле купить "железный" медиаплеер.

.....

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

....

Какая прошивка в wl500 стоит?

У меня больщинство конверторов с четырьмя выводами, есть с двумя и с одним - подобного эфекта нигде не наблюдается.

Когда уровень сигнала ниже 35% (30-34) квакает и замирает ненадолго, сообщение "Нет сигнала" не появляется.

Я бы еще USB версию прошил и на ней проверил, чтобы исключить проблемы с внутренней флешкой.