liquidsoap. трудности в определении начала _звучания_ песни.

18.08.2017

Здравствуйте, яхонтовые коллеги по увлечению!

У меня назрел следующий вопрос: как более или менее точно вычислить момент начала звучания? Не постановки в очередь на декодирование, что легко можно сделать в момент вызова скрипта, который отдает liquidsoap файл песни, ни момент начала декодировани, легко вычисляемый по radio.remaining, а именно начало звучания музыки на стороне слушателя.
На это дело ведь влияеть кеширование айскаста, бразуер (или плеер) слушателя...

Есть у кого-нибудь идеи?

18.08.2017

за конф. буферизации и время начало игры отвечает секция <limits>


с момента подключения клиентом ) как лог icecast отписал так и считай подключение
зачем вдаваться такие подробности и тонкости? У вас что там 3000 слушателей на каенальчике сидят и жалуются на долгий коннект?

время/буферизацию подкл. к стриму можно проверить еще таким способом: барузер Хром --> сайт радио --> вкл. PLAY--> Просмотреть код --.> вверху будет вкладка Network --> Media, где видно будет время буферизации (ms) и поткл. к стриму (побегут цифры. трафик)

18.08.2017

Не совсем понятно - на стороне слушателя чтоле?
Это же просто как дважды два.
И второй вопрос - зачем оно Вам?

19.08.2017

Проще всего вам зайти на сайт ********** дождаться момента завершения звучания песни и посмотреть в этот момент на плеер и список проигранных песен.

19.08.2017

Про эту секцию я конечно же знаю.

Я выше ответил уже уважаемому юзернейму gyurgin_ - проще посмотреть на сайте на то, как реагирует плеер и список песен на завершение композиции.
Айскаст рапартует о начале проигрывания песни секунд на 5-15 раньше того, как она начинает реально звучать.


а разве это не для только самого первого подключения? далее ведь поток идет без перерыва, там наверняка только на буфферизацию можно будет смотреть. но вообще интересная идея.

19.08.2017

посмотрел ... и что такого? Подумаешь, там, на 2-3 секунды скрипт на сайте отрабатывает быстрее ваши титры.... кто на них вообще обращает внимания? Лучше ссылки на стримы дайте юзеру, чтоб слушать можно было на тлф или комп. + облегчите немного сайт по скриптам jQuery . возможно есть какие конфликты и доп. конфигураци..

для такого простецкого сайта в две колонки грузиться такое кол-во кода, что можно игру написать на нем .. DOOM
jquery.js
jquery-migrate.min.js
ajaxify.js
ajaxify-init.js
openapi.js
regress-history.js
moment.js
featherlight.min.js
core.min.js
widget.min.js
mouse.min.js
resizable.min.js
draggable.min.js
button.min.js
position.min.js
dialog.min.js
mediaelement-and-player.min.js
wp-mediaelement.min.js
jquery.form.min.js
onnn.js
socket.io.js
bundle.js
jquery.swipebox.min.js
front.js
widget.js
soundmanager2.js
scripts.js
script.js
polls-js.js
slider.revolution.js
slider.tools.js
prettyPhoto.js
backstretch.js
carouFredSel.js
easy-ticker.js
hoverex.js
idTabs.js
flexslider.js
royal.js
sdk.js
audioplayer.js
nativeflashradiov3.js
wp-embed.min.js

и icecast тут не причем .... причина в другом. смотрите настройки Ajax / DOM

19.08.2017

Проще надо быть, есть liquidsoap же, на on_meta вешаем асинхронный скрипт генерации всего что надо для сайта, замедляем его насколько нужно и все.

20.08.2017

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

И конечно, искреннее спасибо за дельные советы!

20.08.2017

Интересная идея! Но вот ведь незадача, время замедления тоже будет "плавать" (ведь не для всех песен разница во времени начала декодирования и начала воспроизведения одинаковая) и по сути мы получим лишь частичное решение проблемы.

20.08.2017

оффтоп

20.08.2017

Мне не совсем ясно, зачем вы написали этот желчный комментарий. Без сомнения все некоммерческие проекты делаются "для себя и для друзей". Ну, продемонстрируйте свой высококачественный сайт - возможно мне будет на что равняться.

20.08.2017

С какого перепугу оно плавать будет, не надо выдумывать чего нет.

20.08.2017

я пробовал сделать следующее:

def apply_metadata(m) =
system("/home/nodeuser/rserver/liq.sh")
end
....
radio = on_metadata(apply_metadata,radio)

в результате скрипт liq.sh отрабатывает в тот же момент, что и меняется метадата в icecast, откуда её и берёт плеер.
и в том и в другом случае информация появляется раньше на 5-15 секунд, чем начинает звучать песня.
Время этого опережения разное - вот о чем я говорю.
Можно работать с метадатой асинхронно и замедлить ее, например так, что бы она обновлялась позже на 5 секунд, но это лишь сократит промежуток и не решит полностью вопроса.

20.08.2017

Я по-моему ясно обьяснил как надо сделать, по on_meta ПЕРЕДАТЬ внешнему скипту метаданные, получится что-то в этом роде: system("/home/nodeuser/rserver/liq.sh #{quote(m['artist'])} #{quote(m['title'])} > /dev/null &"). И с чего Вы взяли что временная разница там будет разная, у например все совпадает в ноль.

20.08.2017

В моем случае скрипт просто писал в лог timestamp о том, что сработал, а я наблюдал tail -f и если бы эта строчка появлялась в логе строго на 5 секунд раньше начала звучания - вопрос был бы решен, но вот по какой причине он задерживается на разное количество времени.
Почему - разбираюсь. Откровенно говоря, я в некоторой растерянности.

21.08.2017

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

Итак, если кто-то столкнется с подобным вопросом:

def set_metadata(m) =
title = m["title"]
artist = m["artist"]
system("/home/nodeuser/rserver/liq.sh '#{artist}' '#{title}'")
end

radio = on_metadata(fun(metadata) -> add_timeout(6.7, {set_metadata(metadata); 0.-1.}), radio)

24.08.2017

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