He1ix

Конфигурационные файлы WICARD и OSCAM (новый аддон эмуляторов для PGI )

В теме 306 сообщений

привет хеликс, я с мая так и не настроил сезам 901. на оскаме работало, но очень плохо.

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

Спойлер

20:54:54.131 wicardd: wicardd-sh4 version 1.19 beelive (Dec 28 2015) http://wicard.tv
20:54:54.132 wicardd: Build options: [AutoConf] [TuxBox SCI] [DVBAPI] [STAPI] [WEBIF] [ExMLog] [TWIN]
20:54:54.134 wicardd: disabling internal CAS - -1
20:54:54.137 under_app_detect: procname: green.sh, daemonize = 1
20:54:54.138 under_app_detect: PPID: 854
20:54:54.141 under_app_detect: procname: sh, daemonize = 1
20:54:54.143 under_app_detect: PPID: 762
20:54:54.145 under_app_detect: procname: sbox, daemonize = 1
20:54:54.147 under_app_detect: PPID: 278
20:54:54.159 dvb: Filter object created.
20:54:54.162 shara3001: activity_timeout = 0 ms
20:54:54.175 shara3001: using default secure key
20:54:54.192 shara3001: not decoded cache initialized, size: 64, ttl: 3000
20:54:54.195 shara3001: reader thread started, pid 866, tid 695960808
20:54:54.198 wicardd: creating default balancer.
20:54:54.200 default: [balancer] chain key missed, creating default chain including all readers.
20:54:54.202 default: balancer object created, 1 stage(s).
20:54:54.205 DVB: Detected API: STAPI
20:54:54.219 DVB0[STAPI]: PMT association 0 [PTI:pmt1_1.tmp]
20:54:54.221 DVB0[STAPI]: PMT association 1 [PTI:pmt1_2.tmp]
20:54:54.223 DVB0[STAPI]: PMT association 2 [PTI:pmt1_3.tmp]
20:54:54.225 DVB0[STAPI]: PMT association 3 [PTI1:pmt2_1.tmp]
20:54:54.226 DVB0[STAPI]: PMT association 4 [PTI1:pmt2_2.tmp]
20:54:54.228 DVB0[STAPI]: PMT association 5 [PTI1:pmt2_3.tmp]
20:54:54.229 DVB0[STAPI]: PMT association 6 [PTI2:pmt3_1.tmp]
20:54:54.231 DVB0[STAPI]: open PTI device: PTI2
20:54:54.236 DVB0[STAPI]: STAPI filter handler thread started, pti_no = 0 [PTI2], pid 867, tid 697505000
20:54:54.238 DVB0[STAPI]: open PTI device: PTI1
20:54:54.242 DVB0[STAPI]: STAPI filter handler thread started, pti_no = 1 [PTI1], pid 868, tid 698553576
20:54:54.244 DVB0[STAPI]: open PTI device: PTI
20:54:54.247 DVB0[STAPI]: STAPI filter handler thread started, pti_no = 2 [PTI], pid 869, tid 699602152
20:54:54.251 webif: server worker thread started, pid 870, tid 700650728
20:54:54.253 wicardd: registered 1 filter(s), 1 reader(s), 1 balancer(s), 0 tuner(s) and 0 server(s)
20:54:54.254 wicardd: loaded 0 user account(s)
20:54:54.256 wicardd: ECM cache size = 0
20:54:54.269 wicardd: main thread, pid 864, tid 694906880
20:54:54.697 shara3001: connect to [scrubbed]
20:55:14.701 shara3001: host lookup of he6dr9r4.spyip.org failed
20:55:14.702 shara3001: reconnecting... failed
20:55:15.204 shara3001: connect to [scrubbed]
20:55:34.274 wicardd: Discovery thread terminated.
20:55:35.208 shara3001: host lookup of he6dr9r4.spyip.org failed
20:55:35.209 shara3001: reconnecting... failed
20:55:35.711 shara3001: connect to [scrubbed]

 

Изменено пользователем nikelplumbum1

Поделиться сообщением


Ссылка на сообщение
6 часов назад, He1ix сказал:
Спойлер

11:32:52.808 wicardd: wicardd-sh4 version 1.19 beelive (Dec 28 2015) http://wicard.tv
11:32:52.809 wicardd: Build options: [AutoConf] [TuxBox SCI] [DVBAPI] [STAPI] [WEBIF] [ExMLog] [TWIN]
11:32:52.811 wicardd: disabling internal CAS - -1
11:32:52.813 under_app_detect: procname: yellow.sh, daemonize = 1
11:32:52.815 under_app_detect: PPID: 2469
11:32:52.817 under_app_detect: procname: sh, daemonize = 1
11:32:52.819 under_app_detect: PPID: 763
11:32:52.822 under_app_detect: procname: sbox, daemonize = 1
11:32:52.823 under_app_detect: PPID: 278
11:32:52.832 rlst,rlst1: Filter object created.
11:32:52.835 shara3001: activity_timeout = 0 ms
11:32:52.840 shara3001: using default secure key
11:32:52.865 shara3001: not decoded cache initialized, size: 64, ttl: 3000
11:32:52.868 shara3001: reader thread started, pid 2481, tid 695960808
11:32:52.871 wicardd: creating default balancer.
11:32:52.873 default: [balancer] chain key missed, creating default chain including all readers.
11:32:52.875 default: balancer object created, 1 stage(s).
11:32:52.892 DVB0[STAPI]: PMT association 0 [PTI2:pmt.tmp]
11:32:52.894 DVB0[STAPI]: PMT association 1 [PTI:pmt1_1.tmp]
11:32:52.895 DVB0[STAPI]: PMT association 2 [PTI:pmt1_2.tmp]
11:32:52.897 DVB0[STAPI]: open PTI device: PTI2
11:32:52.902 DVB0[STAPI]: STAPI filter handler thread started, pti_no = 0 [PTI2], pid 2482, tid 697505000
11:32:52.904 DVB0[STAPI]: open PTI device: PTI
11:32:52.908 DVB0[STAPI]: STAPI filter handler thread started, pti_no = 1 [PTI], pid 2483, tid 698553576
11:32:52.911 webif: server worker thread started, pid 2484, tid 699602152
11:32:52.913 wicardd: registered 1 filter(s), 1 reader(s), 1 balancer(s), 0 tuner(s) and 0 server(s)
11:32:52.914 wicardd: loaded 0 user account(s)
11:32:52.916 wicardd: ECM cache size = 0
11:32:52.929 wicardd: main thread, pid 2479, tid 694906880
11:32:53.369 shara3001: connect to [scrubbed]
11:33:13.373 shara3001: host lookup of he6dr9r4.spyip.org failed
11:33:13.375 shara3001: reconnecting... failed
11:33:13.877 shara3001: connect to [scrubbed]
11:33:32.935 wicardd: Discovery thread terminated.
11:33:33.881 shara3001: host lookup of he6dr9r4.spyip.org failed
11:33:33.882 shara3001: reconnecting... failed
11:33:34.384 shara3001: connect to [scrubbed]
11:34:14.392 shara3001: host lookup of he6dr9r4.spyip.org failed
11:34:14.394 shara3001: reconnecting... failed
11:34:14.895 shara3001: connect to [scrubbed]

не получается

Поделиться сообщением


Ссылка на сообщение

@nikelplumbum1 в ЛС загляни

ДНС на ресивере не настроен.

host lookup of he6dr9r4.spyip.org failed
Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

@nikelplumbum1 В личку данные по Teamviewer давай, посмотрю,только не тяни, мне тоже есть чем заняться.

Поделиться сообщением


Ссылка на сообщение

спс хеликс большое. а я так и не понял бы что сетевые настройки не верные ) 

Поделиться сообщением


Ссылка на сообщение

Подскажите, как на оскаме настроить БИСС? А то некоторое время(почти год) не смотрел тарелку, а тут куча новостей.

Поделиться сообщением


Ссылка на сообщение

@Helge До чего беспомощные. файл с ключами дал. ридер осталось настроить

https://www.google.com/search?q=oscam+constantcw+reader&ie=utf-8&oe=utf-8&gws_rd=cr&ei=mqahWY7DBaLm6ATjprGIDA

gi_spark2_094.jpg

Надеюсь, догадаешься, куда прописать путь к файлу с ключами?

Поделиться сообщением


Ссылка на сообщение
2 часа назад, Helge сказал:

Спойлер не открывается((((

У меня всё  открывается

Поделиться сообщением


Ссылка на сообщение

Есть один непонятный момент с оскам - на бисс иногда не открывается канал - жму кнопку на перезапуск эмулятора и сразу показывает. Куда копать?

 

# oscam.server generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r11342
# Read more: http://www.streamboard.tv/svn/oscam/trunk/Distribution/doc/txt/oscam.server.txt

[reader]
label                         = ntv+custom
protocol                      = newcamd
device                        = сервер,порт
key                           = 0102030405060708091011121314
user                          = логин
password                      = пароль
inactivitytimeout             = 15
reconnecttimeout              = 20
ident                         = 0500:060A00
group                         = 1

[reader]
label                         = Biss
protocol                      = constcw
device                        = /var/etc/oscam/constant.cw
group                  = 1

 

 

# oscam.user generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r8999
# Read more: http://www.streamboard.tv/svn/oscam/trunk/Distribution/doc/txt/oscam.user.txt
# Compiled by Gianni8127

[account]
user                          = pgi
pwd                           = local
group                  = 1
numusers                      = 0
penalty                       = 0

 

# oscam.conf generated automatically by Streamboard OSCAM 1.20-unstable_svn SVN r11245
# Read more: http://www.streamboard.tv/svn/oscam/trunk/Distribution/doc/txt/oscam.conf.txt

[global]
logfile                       = stdout

[cache]

[dvbapi]
enabled                       = 1
au                            = 1
pmt_mode                      = 0
boxtype                       = ipbox-pmt

[webif]
httpport                      = 8888
httpallowed                   = 127.0.0.1,192.168.0.0-192.168.255.255,10.0.0.0-10.255.255.255,255.255.255.255

 

 

Изменено пользователем Helge

Поделиться сообщением


Ссылка на сообщение

 Есть такое дело. На викарде, кстати, тоже. Косячность корейского ядра. Писал об этом.

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

На мгкамде не замечал...

кстати, есть шанс, что допилят мгкамд? Или уже некому этим заниматься?

Поделиться сообщением


Ссылка на сообщение

@Helge исходников нет, как и на викард. Oscam - опенсорс, больше шансов. Да и ресиверы наши староваты.

Поделиться сообщением


Ссылка на сообщение

@Helge Соврал, на викарде все норм. БИСС не глючит.

 

На oscam изменить секцию dvbapi до такого вида в файле oscam.conf.

[dvbapi]
enabled                       = 1
pmt_mode                      = 4
delayer                       = 60
write_sdt_prov                = 1
boxtype                       = dreambox

Запись норм, старт норм, таймшифт не проверял. БИСС не глючит

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

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

Есть пара вопросов по новому 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
 

Поделиться сообщением


Ссылка на сообщение

@kacy

1. Только для того, чтобы не лезть глубоко в  код web-интерфейса при добавлении wicard. Просто было лень. Да и Oscam не может быть просто клиентом, он всегда CardServer. И вообще, так было задумано Д.Федором.

2. Не допустимо. Если посмотришь в рестартовый скрипт, то там есть строки в do_stop()

killall $BIN_NAME &>/dev/null
killall -9 wicard >/dev/null
killall -9 mgcamd >/dev/null 

Но, по непонятной причине, с wicard'ом не прокатывает, процесс не убивается скриптом командой killall -9 wicard >/dev/null. Oscam прибивается. А с командной строки - без проблем. При переключении эмуляторов в вэбке - выскакивает предупреждение что ресивер нужно рестартовать.

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

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

Во-первых, эти строчки не там. В 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 "до лампочки".

Изменено пользователем kacy

Поделиться сообщением


Ссылка на сообщение

.@kacy Ну, прибивание эмуляторов в скрипте придумал Николаси, чтобы прям по кнопке ПДУ, переназначать эмулятор, там даже строчка с перепрописыванием cs.conf осталась. К тому же ты все перепутал с точностью до наоборот.

Дааа и какая разница, запущен процесс или нет, команда kill отработает в любом случае, с ошибкой или без. Ну а в третьих - попробуй сам поиграй со скриптом - запилим ещё один аддон для мертвой прошивки, никто не против.

Большинство народа после смены IDENT уже выкинули mgcamd и прикрутили оскам или викард, кому что понравилось. 

Вообще есть подозрение, что do_stop вообще не отрабатывает, там условия в конце файла слишком навороченные. Я если честно особо туда не копал - пилил только скрипты вебки и стартовый.

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

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

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

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

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

Изменено пользователем kacy

Поделиться сообщением


Ссылка на сообщение

@kacy

Ващета там killall а не kill, так что пофиг на PID

Спойлер

#!/bin/sh
# title:Restart wicard
# insmod /var/lib/api3.ko
BIN_NAME="wicard"

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

do_start() {
        echo -e "Starting $BIN_NAME...\c"
        /var/bin/$BIN_NAME -d -c /var/keys/wicardd.conf &>/dev/null
#       echo -e 'cs="newcs"\ncam="wicard"' > /var/etc/cs.conf
#       sleep 1
        sleep 2
#       touch /tmp/tmp.info
        [ -n "$(pidof $BIN_NAME)" ] && echo "done!" || echo -e "\nError: could not start $BIN_NAME!"
}

[ ! -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 \0042Starting $BIN_NAME...\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
 

Сигнал SIGTERM может и не остановить процесс (например, при перехвате или блокировке сигнала), SIGKILL же выполняет уничтожение процесса всегда, так как его нельзя перехватить или проигнорировать. SIGKILL -9, SIGTERM -15. 

Нафиг что-то проверять, киляем все процессы. От того что чего-то там не запущено ниче не сделается...

Ну этот отход от темы.

А по теме, в конце скрипта добавь в строку &&do_stop перед &&do_start

[ "$1" != "stop" ] && do_stop && do_start

А уж на то пошло, то и wrapper dvbapi тоже перегружать нужно, обнаружил старый баг с oscam - проблема с исходниками библиотеки api3.ko

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

Процессы в состоянии блокировки не завершаются по 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

 

Поделиться сообщением


Ссылка на сообщение

@kacy Ну, вообще-то не по феншую в процедуре "старт" делать "стоп" чего либо. Как правило, в /etc/init.d/*  (Linux) скрипты запускаются с параметрами start/stop/restart, а в процедуре restart таких скриптов как правило вызов процедуры stop и затем процедуры start. Так меньше путаницы.

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

Завтра добавим в аддон (в чем сильно сомневаюсь) MCAS или CCCAM, что, все скрипты править? Еще раз повторю, "килляние" других эму в рестартовом скрипте - проделки Николаси, вообще это не правильно, т.к. рестартовый скрипт является так же и стартовым, который запускается при старте ресивера (см. /var/bin/init.d/start.cs) с параметром -q.

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

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

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

#!/bin/sh
# title:Stop current Softcam
/var/bin/yellow.sh stop

Останавливаешь эму, меняешь через вебку настройки, жмешь "рестарт" по желтой - телемаркет

А если в стартовые скрипты прописать (точнее расскоментировать, оно там уже есть) "echo -e 'cs="wicard"\ncam="wicard"' > /var/etc/cs.conf " (для oscama  - oscam соотв-но и т.п.) то в вебку вообще лазить не придется. ну и добавить ln -s /var/bin/start.wicard /var/bin/yellow.sh, чтобы меньше телодвижений делать

Я к чему. Дело твое полезное, но цель - сомневаюсь что кроме тебя это кому-то интересно.

 

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

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

Пытаюсь разобраться, что к чему в силу сложившихся обстоятельств. Раньше все работало как часы. Причем периодически использовались самые тяжелые режимы: два кодированных канала пишется, а третий просматривается с задействованным таймшифтом (не успеваю доехать домой к началу ЛЧ УЕФА). Ресивер купленный в первый месяц появления его в продаже, за все время завис пару раз. После ухода со сцены 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, - долго и не очень удобно. Есть желание сделать, или чтобы кто-то другой сделал - на желтой рестарт текущего эму, а на зеленой смена эму (циклический перебор, если больше двух. Но это маловероятно, что понадобится).

Поделиться сообщением


Ссылка на сообщение

@kacy С оскамом есть один косяк, но он связан с модулем api3.ko. а так как разработчик этой приблуды не известен, как и исходников нет, то проблему с редкими вылетами oscam, решить можно только если использовать версию STAPI. Как собсно и в Wicard. 

По крайней мере за последние полгода я ещё ни разу не рестартовал wicard по жёлтой кнопке. Все фризы были кратковременны и то из-за интернета. Но админить удобнее oscam, у него классный вебинтерфейс.

Так что наверное тебе лучше заняться выбором стабильного шаровода, fallback и балансировкой.

Что кстати у тебя в dvbapi разделах?

ЗЫ, для wicard в режиме STAPI, api3.ko не нужен, и запись работает, правда есть косяк с таймшифтом

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение
[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 перевести?

Поделиться сообщением


Ссылка на сообщение

@kacy А с 9Е случайно не "бесплатный" пакет от известного шаровода? если да, то там затыки постоянно, хотя другие пакеты идут норм.

С твоей конфигурацией wicard загружать api3wrapper совершенно не нужно (нужно только для type=DVBAPI3 ну и для oscam) , к сожалению ты не указал в чем проявляются косяки wicard'а, но явно не из-за api3.ko. Предполагаю, что остановка кина после таймшифта, если нет, то поправь.

А с оскамом вообще беда бывает. Бессимптомные зависоны при переключении с одного кодированного канала на другой. Правда очень редко, не больше раза в неделю, зато намертво, только перезагрузкой ресивера или выгрузкой api3.ko.  При чем виснет на каком то канале одном, перключаешься обратно на тот который шел - все ок, назад идешь на тот на котором "не показывает" - в логах "Can't open device /dev/dvb/adapter0/demux0 (errno=24 Too many open files)". Как оказалось, баг 2-х летней давности, и не лечится, т.к. проблема как раз в api3.ko от неизвестного разработчика. И, как написано в багрепорте, " The error does not occur if you use only ECMs, but if you need any EMMs => go for STAPI version."

В аттаче oscam-emu-stapi (прикручен эмулятор, в дополнению к streambord'овскому, выкладывают на sat-universe)

Единственное отличие, в разделе [dvbapi]

[dvbapi]
enabled                       = 1
pmt_mode                      = 2
delayer                       = 60
write_sdt_prov                = 1
boxtype                       = dreambox

 а файле oscam.dvbapi дописать:

### Stapi Tuner 1 ###
S: PTI pmt1_1.tmp
S: PTI pmt1_2.tmp
S: PTI pmt1_3.tmp
### Stapi Tuner 2 ###
S: PTI1 pmt2_1.tmp
S: PTI1 pmt2_2.tmp
S: PTI1 pmt2_3.tmp
### Stapi Timeshift ###
S: PTI2 pmt.tmp
### Stapi Playback ### - на счет этого не совсем уверен что нужно
S: SWTS1 pmt1_1.tmp
S: SWTS2 pmt2_1.tmp
S: SWTS0 pmt3_1.tmp

 

oscam-svn11391-sh_4-webif-stapi-emu.zip

ну и закоментировать запуск api3wrapper в стартовом скрипте, хотя это уже ни на что не повлияет.

Проверил у себя, работает. Запись тоже

Изменено пользователем He1ix

Поделиться сообщением


Ссылка на сообщение

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Похожий контент

    • От Ippolitovich
      Компания Qtum Foundation считает, что обслуживать блокчейн-сети довольно дорого, но если отправить вычислительные мощности на орбиту, то можно сэкономить электроэнергию и деньги. За космическим майнингом будущее — решили в Qtum, поэтому уже начали разработку специальных платформ, способных эффективно функционировать в космосе.
       

       

      Потребление электричества для сети Биткоин постоянно увеличивается, а с ним растут и денежные затраты. Чтобы их уменьшить, Qtum Foundation объединила усилия с компанией SpaceChain, чтобы совместно разработать и начать выводить на орбиту сверхмалые майнинг-спутники, весом в несколько килограммов.
      Кубсаты будут оснащать микрокомпьютерами на базе Кaspberry Pi и программным обеспечением, созданным специалистами Qtum. Спутники будут майнить криптовалюту на орбите, используя алгоритм PoS. Это алгоритм достижения консенсуса, чем-то напоминающий Proof-of-Stake — право подтверждения транзакции предоставляется узлам, на счетах которых находилось больше средств за определенное время.
      Добыча криптовалюты в космосе не только позволит сэкономить электричество, но и применять для этого дешёвые микрокомпьютеры вместо дорогого специализированного оборудования.
    • От Ippolitovich
      Больше никаких консервных банок. С конца этого года продукты для космонавтов Международной космической станции, которые ранее упаковывались в железные банки, теперь будут упаковываться в емкости из ламистера, представляющего собой алюминиевую фольгу с ламинированным покрытием из полипропиленовой пленки. Переход на ламистеровую упаковку будет пробным, а поэтому частичным. Но в будущем эта тара может полностью заменить используемые сейчас банки.
       


      Выбор ламистера объясняется тем, что этот материал весит значительно меньше прежней тары, а потому позволит снизить стоимость доставки продуктов питания на орбиту, сообщают «Известия» со ссылкой на НИИ пищеконцентратной промышленности и специальной пищевой технологии (НИИ ППиСПТ), где часть продуктов уже начали упаковывать в ламистеровую упаковку. Пока в представленном меню продуктов с новой упаковкой имеются четыре блюда – кабачковая икра, пюре из кураги, дробленая брусника и «Закуска аппетитная».
      Линия по упаковке в ламистер была запущена в институте еще в 2016 году. Но потребовалось время для отработки режимов производства, изготовления первой тестовой партии, а также испытания ее качеств. Ожидается, что первые продукты в новой таре появятся на МКС в конце этого – начале следующего года.
      Технологи отмечают, что пища сохраняет свой вкус в ламистере гораздо лучше, чем в алюминиевой таре. Кроме того, новая упаковка легче, что является, несомненно, важным фактором при учете стоимости вывода полезных грузов на орбиту. В конце концов, ламистеровую упаковку проще открывать. После использования ее можно легко смять (для экономии места). Вполне возможно, что через несколько лет космические консервы в банках можно будет встретить разве что только в музеях, как это в свое время было с тюбиками для еды. Их тоже постигла такая участь, пожалуй, разве что за редкими исключениями некоторые продукты до сих пор используют такую тару.
      Сейчас в основном все продукты для российского экипажа МКС отправляются на станцию в сублимированном виде или в виде консервов. В том числе и супы. Исключения составляют лишь несколько пунктов меню, которые упаковываются в специальных тубах: соус томатный «Молдова», приправа яблочно-клюквенная, мед и горчица.
      Космонавт Александр Самокутяев рассказал «Известиям», что снижение массы упаковки и возможность смять ее после приема пищи — дело хорошее. Но необходимо протестировать эргономичность ламистера в условиях невесомости.
      «Если новая упаковка будет легче, это выгоднее», — считает Александр Самокутяев.
       



       
      «Другой вопрос — удобство ее использования в условиях невесомости. Открывая шпроты, вы прилагаете усилия, чтобы не разбрызгать масло. То же и в космосе — мы всегда пытаемся придержать салфеткой крышку, чтобы брызги не летели по станции. Для этого нужен специальный навык: с первого раза ни у кого не получается открыть банку без проблем. Возможно, новая упаковка позволит такие риски снизить. С другой стороны, если жесткости у баночки не будет, возможно, понадобится особая сноровка, навык. Это надо пробовать, испытывать. На Земле такое не смоделируешь. Возможность смять упаковку — это тоже хорошо. Экипажи стараются сплющить металлические банки, чтобы в мусоре они занимали меньше места. Конечно, пластиковые емкости можно плотнее набивать в мешки».
    • От Ippolitovich
      Компания Huawei объявила о начале комплексных испытаний 5G-платформы «Широкополосная беспроводная связь до домохозяйств» (Wireless to the Home, WTTx) — системы передачи данных следующего поколения.
       

       

      Беспроводные сервисы на базе 5G способны дополнить решения типа «оптоволоконная связь до точки Х» (Fibre To The Home, FTTx), предоставляя альтернативу при подключении «последней мили». Способность реализовать беспроводные 5G-решения в городской и сельской местности поможет снизить расходы операторов и повысить доступность технологии 5G для конечных пользователей. Сетевое 5G-оборудование также требует гораздо меньшего пространства для развёртывания, чем традиционные мобильные сети, что упрощает установку новых вышек.

      Сообщается, что в тестовом проекте Huawei участвует компания Telus. Испытания проводятся в лаборатории 5G Living Lab в центре Ванкувера — это одна из первых инициатив подобного рода в мире.
       

       

      Экспериментальная система работает в диапазоне 28 ГГц с шириной частотного канала 800 МГц. В состав платформы входят многие ключевые технологии 3GPP, такие как Massive MIMO, F-OFDM и Polar Code. Кроме того, задействовано уникальное домашнее оборудование 5G.
      В ходе тестов уже показана скорость однопользовательской загрузки данных свыше 2 Гбит/с. Проведённые испытания — это ещё один шаг на пути коммерческого внедрения мобильных сетей пятого поколения.
      Беспроводные 5G-сервисы, как ожидается, создадут множество преимуществ для потребителей, операторов, бизнеса и госсектора за счёт использования передовых IoT-устройств, приложений на базе больших данных, систем «умного» города и других технологий будущего. 
    • От Ippolitovich
      Корпорация Samsung Electronics сократит производство OLED-дисплеев в ответ на решение Apple урезать выпуск смартфонов iPhone X на фоне слабого спроса на них, сообщает японское деловое издание Nikkei.
      Теперь входящая в Samsung компания Samsung Display намерена изготовить в первом квартале 2018 года не более 20 млн OLED-панелей для iPhone на заводе в южнокорейском городе Чхунчхон, тогда как изначально речь шла о 45–50 млн экранов. В результате загрузка предприятия, выполняющего заказы Apple, упадёт ниже 50 %.
       

       
      Что касается производственных планов на вторую четверть, то Samsung Display ещё пока не определилась с ними, однако вполне вероятно дальнейшее снижение объёмов производства, отмечает источник.
      После появления в СМИ информации о сокращении выпуска OLED-дисплеев акции Samsung Electronics подешевели более чем на 2 % к закрытию биржи во вторник, 20 февраля. Также произошло падение котировок японских производителей OLED-компонентов, включая Hodogaya Chemical и Hirata.
       
       


      В январе 2018 года Nikkei сообщало, что Apple уменьшила вдвое (до 20 млн штук) план производства iPhone X в январе–марте 2018 года по причине слабых продаж флагманской модели.
    • От Ippolitovich
      Компания Colorful анонсировала системную плату C.B250A-BTC Deluxe V21, предназначенную для формирования ферм по добыче криптовалют.
       

       
      Новинка оснащена набором логики Intel B250 и предназначена для процессоров Intel в исполнении LGA1151. Для модуля оперативной памяти имеется только один разъём SO-DIMM; поддерживается работа с ОЗУ DDR4-2400/2133.
      Габариты материнской платы составляют 485 × 195 мм. В общей сложности можно задействовать до двенадцати карт для майнинга. В частности, есть восемь слотов PCI Express 3.0 x16 (семь функционируют в режиме х1). Ещё четыре карты можно подключить при помощи PCI-E/USB-адаптеров.
      Плата наделена портами mSATA и SATA 3.0, гигабитным сетевым контроллером, интерфейсом HDMI, а также четырьмя разъёмами USB 2.0.
       


      Информации об ориентировочной цене модели Colorful C.B250A-BTC Deluxe V21 и сроках поступления в продажу на данный момент, к сожалению, нет.
      Добавим, что в последнее время многие пользователи озадачились созданием специализированных систем для добычи криптовалют. Бум майнинга привёл к тому, что всё больше производителей выпускают специализированные аппаратные решения для соответствующих целей. Это касается прежде всего материнских плат и графических карт.