Длительность треков в отчете

  • Автор темы Автор темы Ian
  • Дата начала Дата начала

Ian

Active member
Дмитрий, а когда программа начнёт отправлять в отчётах не физическое время всего трека, а только тот кусок, что расположен между точками "Старт" и "Микс"?
Мы уже писали об этой проблеме: Программа по-прежнему отправляет на наш сервер данные о времени, которые она берёт из заголовка файла, т.е. оно (время) может очень сильно не совпадать. У нас на отправке отчётов завязано автообновление контента, которое не успевает, порой, за целыми треками из-за серьёзного расхождения во времени.
 
Ian сказал(а):
Дмитрий, а когда программа начнёт отправлять в отчётах не физическое время всего трека, а только тот кусок, что расположен между точками "Старт" и "Микс"?
Мы уже писали об этой проблеме: Программа по-прежнему отправляет на наш сервер данные о времени, которые она берёт из заголовка файла, т.е. оно (время) может очень сильно не совпадать. У нас на отправке отчётов завязано автообновление контента, которое не успевает, порой, за целыми треками из-за серьёзного расхождения во времени.
Отмечу на будущие версии, длительность будет определяться по меткам, если они есть - между start и end. Все таки, трек фактически играет и после точки Mix.
 
djsoft сказал(а):
Отмечу на будущие версии, длительность будет определяться по меткам, если они есть - между start и end. Все таки, трек фактически играет и после точки Mix.
Категорическое "Нет"!
Именно между точками "Старт" и "Микс".
Объясняю:
Конечно, хвост трека может играть ещё 20 секунд под заступившим новым треком, но заступивший новый трек может иметь длительность 15 секунд. Для одной из наших радиостанций, где играет не попса, а сложная электроника и сам эфир -- это очень сложная настройка  выхода в эфир всех треков -- вопрос очень важный.
Именно с этим каналом у нас много проблем, т.н. в своих экспериментах над сложной электроникой музыканты не думают о том, как это будет выглядеть в линейном эфире. Это их право и мы приветствуем такой подход. Но эфир строить как-то надо. Эфир у нас наисложнейший, с тончайшими настройками -- и от того получается интересный и офигенно сведённый. Как будто вручную!
Но эта работа. И большая работа. Работа с чудовищно разной музыкой.
Просим учесть это.

Т.е. понимаете, да? На фоне 20 секунд проиграет трек, длиной в 15 секунд, и отчёт об этом проигрывании на сервер не уходит.

С попсой, безусловно, никаких проблем нет. Но мир жив не попсой единой. Есть материал и для думающей аудитории.
 
В таких ситуациях есть простое решение - сделать опционально выбор от каких до каких меток отправлять и каждый себе поставит как ему надо... ну а по умолчанию логично выставить от start до end.
 
Ian сказал(а):
Конечно, хвост трека может играть ещё 20 секунд под заступившим новым треком, но заступивший новый трек может иметь длительность 15 секунд.
Это не должно создавать никаких проблем. Уточните, что не так работает при таком сценарии?

Ian сказал(а):
На фоне 20 секунд проиграет трек, длиной в 15 секунд, и отчёт об этом проигрывании на сервер не уходит.
Уходит для всех запущенных треков. Уточните, о каком отчете идет речь - HTTP запрос?
 
djsoft сказал(а):
Это не должно создавать никаких проблем. Уточните, что не так работает при таком сценарии?
Наш онлайн-плеер имеет "статус-бар" при воспроизведении трека, дающий понимание о продолжительности воспроизводимого трека. Время для статус-бара плеер берёт из отправленных отчётов.
Вот тут-то и начинаются чудеса:
- Сейчас отчёты отправляют продолжительность трека между метками Start и End.
- У некоторых треков, есть длинные "хвосты" (это время между метками Mix и End). Хвосты эти могут быть длиной 20 секунд или более.
- Заступает новый трек. Не поверите -- полноценный трек, продолжительностью в 15 секунд.
- 15-секундный трек заступает на отметке Mix предыдущего трека.
Надо ли объяснять, что происходит со статус-баром?

Совершенно верно. Он показывает всё ещё "хвост" предыдущего трека, хотя в эфир заступил уже третий трек, и конечно, статус-бар резко обновляет время, нарисовав внезапно пройденное время.
С отправкой названий -- то же самое. В описанной ситуации название 15-секундного трека просто не отправляется.
Всё стало бы на свои места, если время отправлять, рассчитанное от меток Start и Mix.
 
Данная ситцация довольно специфическая, поэтому, пока что оставим функционал как есть. Даже как есть сейчас, в вашем случае будет только неправильно отображаться время, сами названия треков будут. Если какой-то короткий трек полностью играет между двумя другими треками за счет микширования, его можно видеть в истории воспроизведения.
 
djsoft сказал(а):
Данная ситцация довольно специфическая
Как вам объяснить, Дмитрий...

Есть длинные миксы и треки, где мы в TrackTool удаляем длинные "заборы" во всяких хаус-миксах. Эти "заборы" могут быть и по 2 и по 3 минуты.
Естессно, время трека (и статус-бар) показывает, что трек идёт 8 минут. Хотя он отыграл 3 минуты из 7.
И вот уже играет следующий трек, а время продолжает отсчитываться предыдущего трека.
вот эта ситуация у нас абсолютно на всех радиостанциях. Даже на попсе.
 
Ian сказал(а):
Естессно, время трека (и статус-бар) показывает, что трек идёт 8 минут. Хотя он отыграл 3 минуты из 7.
Ведь по факту он и играет 7-8 минут, у него длительный период Mix, но трек ведь это время играет. И все же, период наложения треков по 3-4 и более минут, и необхожимость при этом показывать что-то на сайте - нетипичная ситуация. Поэтому, не думаю, что в RadioBOSS будет поддержка подобных ситуаций.
 
djsoft сказал(а):
нетипичная ситуация

Да почему сразу "нетипичная" или "специфическая", вполне обычная ситуация? Для вывода куда-либо наружу данных важно. Неужели опционально сделать никак?
 
djsoft сказал(а):
Ведь по факту он и играет 7-8 минут
Нет. По факту он играет 3 минуты из 8 8)
Оставшееся время он не накладывает и даже не играет. Он отправляет отчёт о длительности трека (8 минут), Вы можете это понять?
Постоянные прыгания даже в 15-20 секунд воспринимают наши пользователи как баг. Мы же не можем им объяснить, что это проблема отчётов, а не сайта или приложения!
Этот самый баг нам портит и статистику и отвлекает нас на постоянные вопросы. Фишку, которую мы сделали --- она прекрасна и её нет ни у кого, но блин, эти отчёты... всё портят.
Вот отправлял бы РБ время в промежутке между Start  и Mix -- проблем бы не было! Да и логически даже вернее на Mix заканчивать отсчёт времени трека, ведь на точке Mix заступает уже новый трек.
Кого уже интересуют доигрываемые "хвосты"?
Вот и получается, что на точке Mix отправляется ложная информация о заступившем треке, т.к. заступивший трек обязательно будет "подрезан" следующим треком. И так -- до бесконечности.
Ну куда это годится?
 
scorp сказал(а):
Да почему сразу "нетипичная" или "специфическая", вполне обычная ситуация? Для вывода куда-либо наружу данных важно. Неужели опционально сделать никак?
Длительность считается от Start до End, этого достаточно для чуть менее, чем 100% случаев, тем более, что это и есть фактическая длительность трека. Трек отыграет в пределах этих меток.

Ian сказал(а):
Постоянные прыгания даже в 15-20 секунд воспринимают наши пользователи как баг. Мы же не можем им объяснить, что это проблема отчётов, а не сайта или приложения!
Не могу поверить, что кто-то вот так следит, ладно названия треков, но длительность? Большинство радио вообще ее не показывает. Не совсем понятно, зачем это вообще нужно.
 
djsoft сказал(а):
Длительность считается от Start до End, этого достаточно для чуть менее, чем 100% случаев, тем более, что это и есть фактическая длительность трека. Трек отыграет в пределах этих меток.

Ну да от Старт до Енд это само собой, это как бы по умолчанию логично (и тут я не согласен Ian, что логичнее до Микс), но тут просят добавить также возможность отправлять длин от Старт до Микс, можно наверно сделать опцию выбора какую отправлять до Енд или до Микс.
 
scorp сказал(а):
просят добавить также возможность отправлять длин от Старт до Микс, можно наверно сделать опцию выбора какую отправлять до Енд или до Микс.
Добавление подобных опций в конечном итоге превратит программу в "монстра", который просто невозможно использовать, тяжело будет найти что-то среди тысяч настроек, которые регулируют какие-то малозначимые, зачастую никому не нужные, мелочи.

Я просто не могу представить ситуацию, в которой длительность трека была бы необходима слушателям, кроме как справочно (то есть, ни на что не влияющая информация). Какая аудитория у таких радио, что они делают с информацией о длительности?
 
djsoft сказал(а):
Не могу поверить, что кто-то вот так следит, ладно названия треков, но длительность? Большинство радио вообще ее не показывает. Не совсем понятно, зачем это вообще нужно.
Скачайте наше приложение и понаблюдайте за прогресс-баром вокруг кнопки Play. Всё сразу станет понятно. :)
 
djsoft сказал(а):
Добавление подобных опций в конечном итоге превратит программу в "монстра", который просто невозможно использовать, тяжело будет найти что-то среди тысяч настроек, которые регулируют какие-то малозначимые, зачастую никому не нужные, мелочи.
1) Вам не стоит бояться "монстроидальности" программы. До реальных монстров (Maya или Adobe) вам ещё далеко в плане супернавороченных и трудно воспринимаемых инструментов.
2) Не бойтесь делать сложный и тонко настраиваемый инструмент, ведь поолная автоматизация возможно только там, где учтены даже нюансы. Дьявол -- он кроется в мелочах, Дмитрий :)
3) В монстроидальных интерфейсах давно применяются т.н. "пресеты" для быстрой адаптации программы под нужды пользователя. Так что не вижу проблем.
4) И да, кстати. Тот же "Стереотул" куда более сложная вещь, а ведь это всего лишь плагин! Но заметьте, никто не говорит "ой, как всё сложно, да ну его, да ещё такой дорогой". Настоящих профессионалов привлекает только гибкий инструментарий.
 
Ian сказал(а):
1) Вам не стоит бояться "монстроидальности" программы. До реальных монстров (Maya или Adobe) вам ещё далеко в плане супернавороченных и трудно воспринимаемы инструментов.
2) Не бойтесь делать сложный и токо настраиваемый инструмент, ведь поолная автоматизация возможно только там, где учтены даже нюансы. Дьявол -- он кроется в мелочах, Дмитрий
3) В монстроидальных интерфейсах давно применяются т.н. "пресеты" для быстрой адаптации программы под нужды пользователя. Так что не вижу проблем.

+++++++++++++++++ ВОТ, и я о том же... Полностью поддерживаю... Именно тонкая настройка это не моонстрообразность, а главный плюс программ, тем более таких которые разные люди используют в разных ситуациях по своим условиям и потребностям, это просто как само собой разумеющееся должно быть... но нет... боязнь превратить в монстра..
 
Ian сказал(а):
Скачайте наше приложение и понаблюдайте за прогресс-баром вокруг кнопки Play. Всё сразу станет понятно.
Попробуйте на новой версии 5.8.4, там исправлена ошибка с длительностью - иногда даже метки Start/End не учитывались.

Ian сказал(а):
где учтены даже нюансы
Они должны иметь смысл, есть вещи, которые просто не нужны, их польза теоретическая (обычно из разряда "неплохо бы..."). И есть вещи, которые нужны 1-2 пользователям (не процентам, а в абсолюте). Такое делать экономически нецелесообразно.

scorp сказал(а):
Именно тонкая настройка это не моонстрообразность, а главный плюс программ, тем более таких которые разные люди используют в разных ситуациях по своим условиям и потребностям
В любом случае есть границы. Делать все подряд это путь в никуда.
 
djsoft сказал(а):
Они должны иметь смысл, есть вещи, которые просто не нужны,
Дмитрий, мы не играемся здесь в радио или что-то подобное. Всё, что мы просим -- оно нужно; так или иначе используется или архивостребованно. В RB есть почти всё, что нам необходимо, но некоторые инструменты в программе реализованы так, что с ними затруднительно работать.
Я уже писал, что с отработкой заданий есть большой косяк, либо их выполнение реализовано не очевидным образом.
Приведу пример, с которым мы сталкиваемся каждый раз, когда в эфир выходит тематический блок:

Генератор создал блок из джингла, вступления, самой передачи, заключения и джингла.
Блок должен выйти, скажем, в 23:00 и закончиться в 00:24.
Выглядит так:

- Jingle
- Introduction podcast
- Podcast
- Outro podcast
- Jingle


Однако если подкаст, выходя в 23:00 заканчивается в 00:24, то у нас возникают проблемы с очерёдностью воспроизведения, в связи с генерацией ночного плейлиста, который Планировщик вставляет ровно в 00:00.
Обязательное условие при этом -- очищение плей-листа от отыгранного дневного контента.
И что мы получаем?
А получаем мы то, что из плейлиста удаляется дневной список треков и текущее задание (подкаст со всеми сопровождающими его Outro и Jingle).

Отыграв, подкаст завершается и тут же заступает ночной плейлист. Запрограммированный выход Outro и Jungle не выходит.

Что мы только не делали: Ставили галочку "Вставить, как обычные треки плейлиста", активировали пункт "Если в плейлисте есть задания, поставить в очередь". Ничего не помогает! Вместе с очищением плейлиста очищается и очередь на воспроизведение из запущенного задания. Это, Дмитрий, реальная проблема!

Предложение, как можно исправить ситуацию.
Я вижу это это так:
При очищении плейлиста, программа смотрит, не играет ли что-то из последнего задания? Если да, то программа очищает в плейлисте всё, что было сгенерировано до последнего вставленного блока -- и после него.
Затем вставляются треки из новой генерации, а после отыгрывания всех треков из предыдущей генерации, не вошедшую в команду удаления --- стираются.
В итоге мы имеем выполнение всех условий:
- Очищение дневного плейлиста
- Отыгрывание в полном объёме последнего задания
- Вставка ночного плейлиста
- Стирание отыгранной группы подкаста, как части дневного эфира.
 
Назад
Верх