MainRadiotalkCustom
Технологии вещания, софт, скрипты
4   •   Посмотреть все темы

Эфирная сетка в sql-таблице

 

5
Krieger @Krieger
Здравствуйте. Прошу помощи-совета.
Настроен 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 не предлагать. Для составления расписания будет использоваться скрипт, основанный на "бызнес-логике" :) Так как от системы требуется программируемость на долгое время вперёд, без необходимости человеческого участия в качестве жокея.

6245
Тарас @tarasian666
проще продумать плейлист а не каждый трек тыкать посекундно.
и тот же плейлист сунуть в базу и уже из плейлиста поочередно брять треки

5
Krieger @Krieger
tarasian666 пишет:

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

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

6245
Тарас @tarasian666
ну так в определенное время запускать определенный плейлист, у которого определенное время проигрывания

5
Krieger @Krieger
tarasian666 пишет:

ну так в определенное время запускать определенный плейлист, у которого определенное время проигрывания

Благодарю за участие, но мне такое решение не нравится - нестройно это.
Я лучше влезу в код ices :)

6245
Тарас @tarasian666
лезте не в код ices а в его плейлист на модуле perl ))
просто ваша задача похожа на тот же плейлист, только он будет складыватся в режиме realtime но он ничем не будет отличатся от заранее спланированого плейлиста

2
moZes @moZes
sql запрос выполняется в доли секунд так что на мой взгляд этого будет незаметно

5
Krieger @Krieger
Решение данных опасений выбрано такое (обкатки пока нет, система не достроена, но должно работать).
К startts следующего трека добавляется запас в 2 секунды, и в get_next пхп-скрипте добавлена строка
time_sleep_until($row['startts']);
Но вы возразите - будут неприлично большие паузы? В этом случае добавим crossfade и вычтем длину фэйда из длины "запаса".

Отредактировано Krieger - 09.07.2010
6245
Тарас @tarasian666
можете пользоваться liquidsoap там есть функция задать проигрывания трека(ов) в строго назначеное время