Предложения по улучшению

[Stalker]

Здрасти всем!
Давненько тут не был, вот зашел поделиться своими впечатлениями по поводу видеонета.

Юзаю видеонет начиная с версии 8.0 сп2, 8.4 - небо и земля по сравнению с предыдущими версиями! Все нравится, все работает изумительно. Хотелось бы предложить парочку улучшений:

1. В настройках ИМХО необходимо дать возможность жестко ограничить число одновременно просматриваемых камер из архива. Именно в настройках, а не в проигрывателе.
2. Так же необходимо дать возможность ограничивать максимальную скорость просмотра архива. Например максимальное кол-во камер - 9, максимальная скорость - 4х.
Для чего это нужно? Часто сталкиваюсь со следующей проблемой: Оператор врубает 16 камер со скоростью просмотра - 24х. Видеонет перезагружается (то бишь аварийно завершает работу) и после перезагрузки часть камер не пишет! И писать начинает только после перезагрузки ВН. Этот баг если честно очень напрягает. Разработчики - поправьте его пожалуйста!
3. Сделайте плз так чтобы при включении проигрывателя камеры не были отмечены для выбора. Проблема та же - оператор пытается разместить на экране сразу все камеры (в моем случае это >100) и комп вешается.
4. Не помешал бы встроенный синхронизатор времени. Без него бывают проблемы с экстренным воспроизведением с удаленных серверов.
5. Сохранение кадра: Мне кажется функцию стоит реализовать так - в настройках указываются параметры сохранения кадра (тип файла, качество сжатия, папка для сохранения), а при нажатии кнопки "Сохранить кадр" выдавать всплывающее окошко "Кадр успешно сохранен". Так же кадрам неплохо было бы давать имя, аналогичное камерам, т.е. не "FrameX", а "Название_камеры_дата_время".


Пока вроде все . Если еще что-нибудь вспомню - напишу.

Всех с наступившим Новым Годом!!!

Чуть не забыл!

Что-то надо придумывать с правкой режимов видеоокон:
а) все видеоокна жестко зафиксировать в соотношении 4:3. Для чего это нужно? Для того чтобы при создании нового режима видеоокон не возникало проблем с изменением масштаба.
б) пора написать режимы для вайдовых мониторов. Квадраты все сложней и сложней найти в продаже

[Vibat]

- Если VideoNet перегружаеться, что приводит к сбою архива, наверное не всё так "изумительно", вот например некоторые мои сервера работают на 8.0сп6 и 8.2 перевыпущенной, изумительно не менее.
- чтобы понять почему вышибает 16 камер на 24 скорости надо знать возможности железа (например на 2 камеры в реалтайте нужен один винчестер, или на 8 камер в мультиплексе; ну и процессор с оперативкой..)
- синхронизацию времени надо проводить вручную, при выгруженном VN, иначе возможны сбои (опять-таки !) архива
- последнее твоё утверждение а) и б), вообще противоречат друг другу - зачем фиксировать, если квадраты найти всё сложней ?!

[dr0m0k]

2 Stalker: пожелания лучше отправлять на мыло саппорта, и чтобы по каждому пункту присутстволо: 1 - что нужно сделать, 2 - зачем? и 3 - пример реального использования...

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

а насчет режимов, ИМХО, пусть будет так как есть... проблема с пропорциями легко решается при помощи калькулятора, хотя режимы для широко форматных мониторов всё же нелишне было бы добавить в дистрибутив...

2 Vibat возникновение сбоев в архиве из-за синхронизации - это чисто твоя теория! так что не надо воду мутить, потому что если бы это было так, то у всей страны 2 раза в год падал бы архив железно - когда часы переводят... а поскольку такого не наблюдается, то значит заявление необосновано.

[Stalker]

2 Vibat
"...- чтобы понять почему вышибает 16 камер на 24 скорости надо знать возможности железа (например на 2 камеры в реалтайте нужен один винчестер, или на 8 камер в мультиплексе; ну и процессор с оперативкой..)..."

Дык это понятно все. 28 цв. камер, 704х288, резкость 6, чувствительность 1, темп - 5 к/с. кодек - DvPack2.
Проц Е7200, 2 гига оперативы, 1 винт - 80 Гб (сист), 4 винта 500 Гб (арх). Т.е. в рамки просмотра/записи конфиг укладывается. При просмотре 16 (и более) камер при скорости 24х нагрузка просто конская и под такое мощности сервера закладывать на стадии проектирования - пустая трата денег. Проще программно обрезать кол-во одновременно просматриваемых камер и скорость просмотра.

"...- синхронизацию времени надо проводить вручную, при выгруженном VN, иначе возможны сбои (опять-таки !) архива..."

Не факт. На прошлой работе у меня стояла прога Dromoka для синхронизации - все работало идеально. Максимум что возникало - ВН не мог писать в архив 1-2 сек, о чем выдавалась соотв. ошибка в журнал.

"...- последнее твоё утверждение а) и б), вообще противоречат друг другу - зачем фиксировать, если квадраты найти всё сложней ?!..."

Ну и фиксировать по-разному можно ведь! Как для 4:3 так и для 16:9.

2 dr0m0k

Точно. На мыло напишу, но чуть позже С широкоформатниками тоже надо будет поразбираться.... режимы 3х3 и 4х4 уже вряд ли туда покатят. По наличию свободного времени попробую нарисовать.

[dr0m0k]

для широкоформатных подходят идеально 3х2 и 6х4

[Vibat]

Дык это понятно все. 28 цв. камер, 704х288, резкость 6, чувствительность 1, темп - 5 к/с. кодек - DvPack2.
Проц Е7200, 2 гига оперативы, 1 винт - 80 Гб (сист), 4 винта 500 Гб (арх). Т.е. в рамки просмотра/записи конфиг укладывается. При просмотре 16 (и более) камер при скорости 24х нагрузка просто конская и под такое мощности сервера закладывать на стадии проектирования - пустая трата денег. Проще программно обрезать кол-во одновременно просматриваемых камер и скорость просмотра.

Не понятно дык, как организованы тома (составляющие) VideoNet на этих 4х винтах ?! Запись на них ?
Должно быть 4 тома (винт - том) без составляющих, 28 камер равномерно поделены между ними (т.е. 7 камер на том). Так ли ?

2 Vibat возникновение сбоев в архиве из-за синхронизации - это чисто твоя теория! так что не надо воду мутить, потому что если бы это было так, то у всей страны 2 раза в год падал бы архив железно - когда часы переводят... а поскольку такого не наблюдается, то значит заявление необосновано.

тут надо понимать, что когда производиться запись данных, в системе не должно быть сбоев; может 10 раз аварийно перегрузиться сервер, 20 раз пройти синхронизация времени - всё будет ОК, а на 21 раз этот архив зависнет.. и кранты ..архивы это не самое надежное место в VideoNet, даже самое ненадежное..
синхронизация обычно проводиться ночью (как и смена времени), когда запись данных минимальна.. и почему "железно" , я же пишу "возможно" ?!

[Stalker]

Не понятно дык, как организованы тома (составляющие) VideoNet на этих 4х винтах ?! Запись на них ?
Должно быть 4 тома (винт - том) без составляющих, 28 камер равномерно поделены между ними (т.е. 7 камер на том). Так ли ?

Да, совершенно верно. по 7 камер на винт. 4 тома, по одному тому на каждый винт. Размер кластера 64 к, индексирование отключено, антивирей нет.

Запись с 7 камер на один винт это 7*5=35 к/с. Просмотр камер с одного винта при скорости 24 это 7*5*24= 840 к/с, плюс запись 35 к/с. Многовато однако будет!

Просмотр 16 камер при скорости 24 это 16*5*24=1920 к/с, плюс запись 28*5=140 к/с Тут уже никакой сервер не справится.... Упрется и в дисковый интерфейс и в мощности процессора....

По поводу синхронизации - полтора года без сбоев проработало... проблем замечено не было....

[Vibat]

Запись с 7 камер на один винт это 7*5=35 к/с. Просмотр камер с одного винта при скорости 24 это 7*5*24= 840 к/с, плюс запись 35 к/с. Многовато однако будет!
Просмотр 16 камер при скорости 24 это 16*5*24=1920 к/с, плюс запись 28*5=140 к/с Тут уже никакой сервер не справится.... Упрется и в дисковый интерфейс и в мощности процессора....

Это кто ж так учил считать ? Где учет размера записанного кадра ?
Я бы воспользовался таблицей №4 http://www.videonet.ru/index.php?id=86
ваш размер кадра 6050 байт (обратите внимание на требования к компьютеру!), 16 камер создадут поток 775 кбит в секунду х 5 (темп записи) , через интернет можно смотреть.

[Stalker]

А размер какого кадра брать - опорного или промежуточного? И как соотнести размер кадра с мощностью процессора (при просмотре в подобном режиме загрузка проца - 100%).

Да и вообще немного ушли от темы Есть проблема, есть решение - нужно только это решение реализовать!

[Vibat]

Да от темы мы не отошли, прежде чем рекомендовать лишить оператора настроек скорости, надо понять почему так происходит .. загрузка 100 % это не нормально, надо обратиться в техподдержку, прислать им саб файл. Я так понял у вас платы PowerVN8 , нагрузка на процессор при них меньше, чем в таблице. Может у вас архивы уже "больны", надо пролечить утилитой восстановления, возможно сидит вирус (антивируса то нет !) "С помощью бесплатной утилиты Dr.Web CureIt!® без установки Dr.Web в системе Вы можете быстро проверить Ваш компьютер, и, в случае обнаружения вредоносных объектов, вылечить его. "

А размер какого кадра брать - опорного или промежуточного?

Ничего брать не надо, кодирование уже произошло.

[Stalker]

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

А загрузка 100% в подобном режиме - вполне нормальное явление. Вот смотри - вывод изображения на два монитора от 28 камер, плюс их запись. На все это уходит 45-50% мощности процессора ( при моих настройках это штатный режим работы сервера). А тут еще такой просмотр....

[Stalker]

з.ы. и архивы не больны. уверен на 100%

[Vibat]

з.ы. и архивы не больны. уверен на 100%

Признаками сбоя архива являются:
• некорректная работа сбора информации о Томе ;
• зависание системы при завершении архива (выход из системы, применение изменений в конфигурации, синхронизация версий конфигураций);
• отсутствие карты фрагментов или источников в проигрывателе (в случае, когда точно известно, что запись производилась);
• информация об ошибках в журнале событий VideoNet (невозможно произвести запись, ошибка монтирования тома и т.д.);
• резкое увеличение загрузки процессора во время работы VideoNet при аномальной активности дисковой подсистемы;
• потеря емкости архива.

http://www.videonet.ru/forum/viewtopic.php?t=484

P.S.

По поводу синхронизации - полтора года без сбоев проработало... проблем замечено не было....

симптомы налицо, да и причины проглядываються ..

[Stalker]

Stalker писал(а):
з.ы. и архивы не больны. уверен на 100%



Признаками сбоя архива являются:
• некорректная работа сбора информации о Томе ;
• зависание системы при завершении архива (выход из системы, применение изменений в конфигурации, синхронизация версий конфигураций);
• отсутствие карты фрагментов или источников в проигрывателе (в случае, когда точно известно, что запись производилась);
• информация об ошибках в журнале событий VideoNet (невозможно произвести запись, ошибка монтирования тома и т.д.);
• резкое увеличение загрузки процессора во время работы VideoNet при аномальной активности дисковой подсистемы;
• потеря емкости архива.

http://www.videonet.ru/forum/viewtopic.php?t=484

И чо?

Stalker писал(а):
По поводу синхронизации - полтора года без сбоев проработало... проблем замечено не было....


симптомы налицо, да и причины проглядываються ..

Читаем внимательней:

Не факт. На прошлой работе у меня стояла прога Dromoka для синхронизации - все работало идеально. Максимум что возникало - ВН не мог писать в архив 1-2 сек, о чем выдавалась соотв. ошибка в журнал.

После этого еще раз перечитываем фразу:

По поводу синхронизации - полтора года без сбоев проработало... проблем замечено не было....

И вот эту:

Видеонет перезагружается (то бишь аварийно завершает работу) и после перезагрузки часть камер не пишет! И писать начинает только после перезагрузки ВН. Этот баг если честно очень напрягает. Разработчики - поправьте его пожалуйста!

И ищем хотя бы одно упоминание о падении архива. Как найдем - сразу отписываемся на форум

[Vibat]

И чо?
.. ищем хотя бы одно упоминание о падении архива. Как найдем - сразу отписываемся на форум

не надо только так переживать, ладно ? как будто сейчас все кинуться искать ..
что ты понимаешь под "падением" архива ? должно все остановиться и зависнуть ?
Достаточно того что ненормальная загрузка процессора.
Это уже сбой. Записи в журнале и пропадания кусков фрагментов, еще один сбой.
На 24 скорости я кручу свои архивы и ничего не вылетает, потому и предположил что архив болен.
Чем заводить этот бесполезный спор лучше проверь:
- чтобы не было вирусов
- пролечи архив утилитой StoragRecovery
- отключи синхронизацию времени
Если ничего не измениться, напиши. ОК ?

[Максим]

А еще архив банально слетает при синхронизациях конфигураций серверов. Особенно заметно в связке 8.3+8.4.

[Максим]

Предлагаю ввести простую опцию.

При "отваливании" тома, сделать опцию "Переподключить существующие тома". Смысл...слетает том, для того что бы его заново подключить как существующий приходится удалять и добавлять "уже существующий том". Если делать удаленно, то не всегода помнится как он обозван на диске и на каком именно диске лежит. Вот такая опция была бы желательна. Просто ВН автоматом берет и , грубо говоря, автоматически переподключает отвалившиеся тома, которые были в конфигурации до "отваливания". Можно было бы вообще автоматически отслеживать отваливание и осуществлять переподключение без участия админа.

[Vibat]

Автоматически как опрелелить что он "отвалился" ?
Однозначно 8.4 , создать два тома. Подключайся по сети , проверяй ..
Лучше всего "сбор информации о томе" , его отсутствие подразумевает начало отвала. Т.е. один том лечиться StRec , во второй продолжаеться запись.

[OW]

Автоматически как опрелелить что он "отвалился" ?
Однозначно 8.4 , создать два тома. Подключайся по сети , проверяй ..
Лучше всего "сбор информации о томе" , его отсутствие подразумевает начало отвала. Т.е. один том лечиться StRec , во второй продолжаеться запись.

Тоесть изначально предполагается что VN ненадёжный и надо иметь по два тома, по две платы, ..... а лучше второй резервный сервер ? так на всякий случай

[Vibat]

У меня такой стоит в офисе, резервный...
Редко, но бывает нужен.
Доказать заказчику, клиенту, что виноват именно он, особо не трудно.
Причина почти всегда - нештатные выключения.
"тыкаешь носом" в EventLog - берёшь деньги

[Максим]

Автоматически как опрелелить что он "отвалился" ?
Однозначно 8.4 , создать два тома. Подключайся по сети , проверяй ..
Лучше всего "сбор информации о томе" , его отсутствие подразумевает начало отвала. Т.е. один том лечиться StRec , во второй продолжаеться запись.

Вот именно "Сбор информации" в виде "Нет данных" и дает флажок о том что том отвалился Что мешает проверять автоматом присутствие или отсутсвие информации о томе ? В конце концов просто ввести признак "онлайн"/"оффлайн"/"n/a" и по нему определять необходимость переподключения. Ведь в большинстве случаев том остается неповрежденным.

Каким образом это разработчики реализуют нам вобщемто относительно побоку .

[dr0m0k]

абсолютно надежных систем не существует...

[Максим]

А подключаться по сети, сидя за праздничным столом в ресторане как- то не очень греет )) И кстати в некотором роде это повысило бы общую надежность ВН. Меньше вмешательств в систему = больше надежность. Другое дело если том с ошибками, то можно и табличку вывалить юзеру.

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

[Vibat]

Чет непойму, удалили чтоль ..

Я предлагаю по улучшению VideoNet использовать штатное событие
"ошибка при работе с жесткими дисками"
которое и отправлять на e-mail

[Max]

Чет непойму, удалили чтоль ..

Я предлагаю по улучшению VideoNet использовать штатное событие
"ошибка при работе с жесткими дисками"
которое и отправлять на e-mail

читайте ЛС и более внятно задвайте вопросы...