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