Разве что происходит регулярно, раз в неделю последние три недели. Аккурат после перехода на версию 5_0_13
Если вы грешите на 5.0.13, то :
1)программа OnAir не менялась с апдейта 5.0.3
2)откатите на предыдущую версию и посмотрите будет ли повторяться проблема.
1. Антивирус работает - AnVira.
Можно ли ему указать какие типы файлов не нужно сканировать?
2. Файлов в папке - 680 штук.
Попробуйте в программе OnAir эту файловую страничку не держать открытой все время. Имеется ввиду следующее - после формирования расписания (когда вы добавили файлы с этой страницы) в программе OnAir выбрать какую-нибудь другую страничку. Например, с расписаниями. Может быть проблема связана с периодическим сканированием странички с файлами - это процесс достаточно тяжелый.
Сегодня снова возникло зависание.
Третий ролик в блоке на последних двух секундах воспроизведения завис. "Program not responding ... " и все дела.
Ничего не трогаем. Через секунд 30 пошел воспроизводиться следующий ролик (четвертый) в том же блоке. И на середине завис.
Больше ждать не стали, ушли в перезагруз компа.
(((
Ролики все в MSDV. Все одинаковые, с одной машины ОТК пришедшие.
Та же проблема, ролики случайные собственного изготовления - стали перекодировать их в мпег2 вместо dv-avi, но не помогло. В связи с этим просто написал скрипт сторож потребления процессорного времени FDOnAir с последующим перезапуском с ключом /restart.
Может, встроите перезапуск треда импорта если он не отвечает каждую секунду например?
И еще, не нашел настройки упреждающего кеширования в *оперативную память* с диска - вроде бы вполне очевидно необходимая вещь, которую хотелось бы выставить например в 500 мег или даже 1 гиг, а то OnAir как бумажный - не то что гигабитную, а иногда даже и 100мбитную сеть не поюзаешь на всю катушку...
в данном случае показывается П05окт11перед10.mpg и последний кадр висит непредсказуемое кол-во времени, в сетке желтая надпись LOAD на следующем ролике (аБратьяОруж8_сег_35.mpg).
тут пришлось убить процесс FDOnAir в Task Manager - иначе не закрывался, посему и предложил автоперезагрузку треда импорта для увеличения надежности эфирной программы.
на счет рамдиска шутко оценил - я понимаю, что задрали вас умники, но зачем уж так толсто-то... 40-60 гигов рамдиска это уже из BFG-9000 по воробьям в нашем случае и еще см. ниже
суть в том, что OnAir слишком нежный без большого read-ahead (надеюсь хоть какой-то он у вас есть, ведь даже в примитивных двд и мп3-плеерах уже лет 5-10 используют упреждающее кеширование контента)
> в данном случае показывается П05окт11перед10.mpg
Погодите. Выше вы говорили, что проблемы с DV. Так с DV или mpg нужно разбираться?
> автоперезагрузку треда импорта для увеличения надежности эфирной программы
Не всё так просто, к сожалению.
> суть в том, что OnAir слишком нежный без большого read-ahead
Проблема не в read-ahead, а в том, что есть проблемы с конкретными файлами. Нужно разбираться с этим, а не бездумно увеличивать количество памяти, которое OnAir может "сожрать". От того, что файл будет лежать полностью в памяти, проблема с зависанием вовсе не факт, что решится.
Проблема может быть в MPEG-декодере, например, и периодически мы такие проблемы находим. Декодер у нас не свой, а компании Elecard, и решение подобных проблем через них занимает, к сожалению, некоторое время (иногда месяц и даже дольше). Поэтому как раз лучше будет, если файлы будут в формате AVI - с такими файлами мы сами можем разобраться.
> (надеюсь хоть какой-то он у вас есть
Да, предчтение есть, но не на весь файл, а на его некую начальную часть. Кроме того, предчтение делается только для текущего и следующего файла - дальше смысла нет, т.к. расписание может измениться в любой момент.
*абсолютно идентичная проблема*, как я написал выше, была с DV, и с этими же роликами скодированными в mpeg2 - подвисает непредсказуемо раз в неделю или реже, хотя комп перегружается каждое утро, систему тоже меняли (хр и 7ка). И что самое характерное, все такие подвисания именно на связке заставка + анонс. С DV-avi подвисало чаще.
p.s. Увеличение read-ahead сделает OnAir гораздо более устойчивым к пиковым случайным нагрузкам на диск - как вызванными пользователем, так и системным, это никак не связано с декодером мпег2 или нашей проблемой, а всего лишь предложение очевидного улучшения программы.
А кстати, "подготовка с соседним" могла бы помочь, если бы в программе не было такого малюпасенького ограничения в 9 секунд - я бы выставил "начинать не позднее, чем за" 10 минут и лимит ролика в 35 секунд, например. Не было бы ли это своего рода настраиваемым буфером read-ahead в озу?
Так ведь в установках FDOnAir 1.21.100 в закладке "подготовка видеофайлов" настройка "Подготавливать файл вместе с соседним, если его длина меньше чем" - пишу нужное мне число, а программа ограничивает его на 9 секунд. Действительно смешно.
Не вижу ничего смешного. Всего несколько лет назад, когда была сделана эта настройка, памяти в компьютерах было не очень много.
Видимо, если увеличить это ограничение, тогда и впрямь файлы большего размера будут целиком загружаться в память. Надо уточнить у наших разработчиков, которые точнее могут сказать, так это или нет.
Проблему проигрывания большой группы файлов как один можно, если играть их, например, как tml-файл (подготавливается в программе FrwClip - файлы, положенные в одну дорожку) или как SLBlock (в программе SLBlockEditor).
Размер "упреждающего кеширования" можно увеличить в Установках OnAir'а на закладке Конфигурация. Там есть строчка "Память сервера". Можно увеличивать её до тех пор, пока будет позволять размер оперативной памяти. Только проблему это всё равно не решит. Нужно выяснять, почему на проигрывании роликов программа зависает. Что за ролики.
