Авторизация
€
$
₴
₽
EN
RU
Vmeste.EU
Услуги
Проверка
Форумы
Основное
Radiotalk
Пользовательское
Технологии вещания, софт, скрипты
7 •
Посмотреть все темы
Эфирная сетка в sql-таблице
1
5
Krieger
@Krieger
26.06.2010
Здравствуйте. Прошу помощи-совета.
Настроен icecast, ices обращается за именем след. трека к скрипту стандартным способом (ices_get_next), тот выдаёт имя трека по sql-запросу
$now = gmdate('U');
$que='select * from schedule where startts >= '.$now.' order by startts limit 1'
В таблице другим скриптом будет расписано время, в которое должен начинаться трек.
В ней, попросту говоря, есть поля filename и startts (timestamp of start).
Так вот, предвижу следующую проблему:
Допустим, скрипт, создающий расписание (он ещё не написан), будет добавлять песню, а затем следующую - с startts со значением, большим на длительность предыдущего трека в секундах. Но тогда, когда при воспроизведении первый трек кончится, пойдёт запрос к базе, и какой-то промежуток времени займёт выполнение запроса. И вторая песня начнётся позже назначенного момента. И этот "дрейф" будет нарастать. В результате в какой-то система "проскочит" какой-то трек в расписании, и пойдёт дальше.
Если же добавлять к startts следующего трека пару секунд "про запас", то будет иметь место рассинхронизация в обратную сторону.
Чувствую, что нужно использовать killall -USR1 ices в заданный момент, но опасаюсь, что это будет давать "заикание" трека, который чуточку недозакончился, или который уже начал проигрываться.
Внимание, вопрос: как же зарание расписать эфирную сетку, и соблюдать её с точностью до 1-2 секунд?
Все юниксовые навороты, crond, atd доступны, правда, пока не вижу, как их применить.
Надеюсь, я доступно объяснил свою ситуацию и проблему.
Мне кажется, кто-то уже должен был сталкиваться с такой проблемой.
Использовать winamp, sam broadcaster не предлагать. Для составления расписания будет использоваться скрипт, основанный на "бызнес-логике" :) Так как от системы требуется программируемость на долгое время вперёд, без необходимости человеческого участия в качестве жокея.
0
6245
Тарас
@tarasian666
27.06.2010
проще продумать плейлист а не каждый трек тыкать посекундно.
и тот же плейлист сунуть в базу и уже из плейлиста поочередно брять треки
0
5
Krieger
@Krieger
27.06.2010
tarasian666
пишет:
проще продумать плейлист а не каждый трек тыкать посекундно.
и тот же плейлист сунуть в базу и уже из плейлиста поочередно брять треки
А одно из требуемых к реализации правил такое - некоторую группу песен крутить только в ночное время. И тому подобные правила. В общем, надо время знать.
0
6245
Тарас
@tarasian666
28.06.2010
ну так в определенное время запускать определенный плейлист, у которого определенное время проигрывания
0
5
Krieger
@Krieger
28.06.2010
tarasian666
пишет:
ну так в определенное время запускать определенный плейлист, у которого определенное время проигрывания
Благодарю за участие, но мне такое решение не нравится - нестройно это.
Я лучше влезу в код ices :)
0
6245
Тарас
@tarasian666
28.06.2010
лезте не в код ices а в его плейлист на модуле perl ))
просто ваша задача похожа на тот же плейлист, только он будет складыватся в режиме realtime но он ничем не будет отличатся от заранее спланированого плейлиста
0
2
moZes
@moZes
09.07.2010
sql запрос выполняется в доли секунд так что на мой взгляд этого будет незаметно
0
5
Krieger
@Krieger
09.07.2010
Решение данных опасений выбрано такое (обкатки пока нет, система не достроена, но должно работать).
К startts следующего трека добавляется запас в 2 секунды, и в get_next пхп-скрипте добавлена строка
time_sleep_until($row['startts']);
Но вы возразите - будут неприлично большие паузы? В этом случае добавим crossfade и вычтем длину фэйда из длины "запаса".
Отредактировано Krieger -
09.07.2010
0
6245
Тарас
@tarasian666
09.07.2010
можете пользоваться liquidsoap там есть функция задать проигрывания трека(ов) в строго назначеное время
0
цвет
черный
красный
синий
зелёный
оранжевый
фиолетовый
серый
-
1
2
3
4
5
6
7