RadioBOSS 6.2 [beta]

Статус
Закрыто для дальнейших ответов.
Если не трудно, добавьте, пожалуйста, сюда возможность обзывать уведомления (поле ввода при добавлении/редактировании) и столбик с названием, было бы очень удобно.
Как пример, нужно создать несколько уведомлений с запуском разных заданий и хотелось бы сразу видеть и понимать что за что отвечает, а то все что видно в запросе это ID задания, а оно вообще ни о чем не говорит.

1661767993035.png
 
Еще по АПИ:
1. действие playbackinfo возвращает данные, среди которых
Код:
<Playback pos="20172" len="218162" state="play" playlistpos="1" streams="2" netstream="n/a"/>
- что тут означают вот эти 2 параметра streams="2" netstream="n/a" ?

2.
Можно ли как-то получить по АПИ (я не нашел) текущее время сервера с РБ, сколько прошло в часе и сколько осталось до конца часа? Если нет, то было бы хорошо добавить сюда (в результат playbackinfo или в status) эту инфу, это позволит делать дополнительные проверки скриптом и запросы в конце часа.

3. Было бы очень удобно если бы сюда (в playbackinfo) можно было через параметры указать количество отображения предыдущих и следующих треков, хотя бы в рамках до 10-15 шт. Не нужно было бы городить лишних кодов и запросов для вывода на сайт.
 
Еще по типам файлов...

1661772038892.png


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

И еще вот при добавлении типа файла там по умолчанию идентификатор прописывается вида :FType16 - это двоеточие играет какую-то роль? И если вот допустим указать звездочку * - она несет в себе какую-то логику типа "все файлы" или тупо как символ и все?

И как допустим выделить конкретную команду, то есть не просто по признаку .command а с указанием части команды и т.п. то есть конкретную. Можно как-то скомбинировать идентификатор типа .command+XXXX, что будет означать команда содержащая в себе такой-то XXXX идентификатор (сочетание символов)? Ну и не только для команды так...
 
Если не трудно, добавьте, пожалуйста, сюда возможность обзывать уведомления (поле ввода при добавлении/редактировании) и столбик с названием, было бы очень удобно.
Спасибо за предложение, в одном из обновлений, думаю, сделаем.

что тут означают вот эти 2 параметра streams="2" netstream="n/a" ?
Это технические данные: сколько аудио потоков используется программой и статус интернет потока если играет поток по URL.

Можно ли как-то получить по АПИ (я не нашел) текущее время сервера с РБ, сколько прошло в часе и сколько осталось до конца часа? Если нет, то было бы хорошо добавить сюда (в результат playbackinfo или в status) эту инфу, это позволит делать дополнительные проверки скриптом и запросы в конце часа.
Время ведь везде синхронизировано, то есть всегда можно это вычислить и так.

3. Было бы очень удобно если бы сюда (в playbackinfo) можно было через параметры указать количество отображения предыдущих и следующих треков, хотя бы в рамках до 10-15 шт. Не нужно было бы городить лишних кодов и запросов для вывода на сайт.
Следующий трек вычисляется только один. Для получения предыдущих треков есть отдельная команда getlastplayed.
 
И сейчас не дает оставить поле идентификатора пустым.
Да, потому что это нарушает другой функционал - когда через Track Tool треку принудительно назначается тип, используется идентификатор. В случае с пустым это работать не будет. Если он не нужен то можно туда любую строку ввести.

И еще вот при добавлении типа файла там по умолчанию идентификатор прописывается вида :FType16 - это двоеточие играет какую-то роль? И если вот допустим указать звездочку * - она несет в себе какую-то логику типа "все файлы" или тупо как символ и все?
Это сделано чтобы снизить вероятность того, что эта строка вдруг встретится в каком-то музыкальном треке.

И как допустим выделить конкретную команду, то есть не просто по признаку .command а с указанием части команды и т.п. то есть конкретную. Можно как-то скомбинировать идентификатор типа .command+XXXX, что будет означать команда содержащая в себе такой-то XXXX идентификатор (сочетание символов)? Ну и не только для команды так...
Можете попробовать stop.command если для команды stop. Должно сработать.
 
Это технические данные: сколько аудио потоков используется программой и статус интернет потока если играет поток по URL.
Ниче не понял... что за потоки имеются в виду... и о каком интернет потоке идет речь?

Следующий трек вычисляется только один. Для получения предыдущих треков есть отдельная команда getlastplayed.
Дмитрий, вы пишите в ответ то, что и так ежу понятно. Я понимаю, что проще, как всегда, отфутболить... но вы подумайте лучше сколько нужно городить лишнего чтобы вывести предыдущие/следующие. Почему бы не добавить 2 параметра в то действие - один отвечает за количество предыдущих, другой за следующих и все. И не надо ничего городить, одним запросом все получил и вывел. Если без них то выводится как сейчас. Ничего нигде не нарушает никакой совместимости и удобно. Для других каких-то целей уже можно городить огород, а так зачем вынуждать пользователя все усложнять, лишние запросы и т.д.

Можете попробовать stop.command если для команды stop. Должно сработать.
Причем тут stop? Читайте, пожалуйста, внимательно... речь идет про любую команду... Короче нельзя так...

1661781817032.png

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

И еще в результат действия getlastplayed не хватает рейтинга. И вообще, хотелось бы, чтобы все действия, где возвращаются треки содержали в себе сразу все данные о треках. Например, тот же trackinfo тоже без рейтинга... в playbackinfo тоже...

Почему readtag возвращает названия атрибутов маленькими буквами, когда все остальные большими, то есть Title вместо TITLE?

Реализация АПИ - полный кошмар... не устану повторять..


1661783529454.png
-вот это не понятно... что значит "только тег типа файла", то есть в типе файла Джингл можно искать по типу файла Комментарий или как тут это понимать? Или тут как-то не так обозвано... или я туплю..
 
Последнее редактирование:
action=setcasttitle&title=%casttitle [%listeners]

Как сделать, чтоб это работало?... надо через скрипт обрабатывать и для треков с определенным тегом отправлять по разному. Сейчас пока не удалось добиться, чтоб переменные обрабатывались посланные через этот запрос в action=setcasttitle

А еще хотелось бы через АПИ управлять отправляемым названием в энкодерах, в типах файлов, этими главными метатегами в настройках, переключать режим обновления, включать/отключать в типах файлов
1661850088362.png
 
Не могу понять, что является разделителем тегов, как их в скрипте разбивать по какому символу, отделять друг от друга, чтоб читать/писать по АПИ через readtag/writetag.

Код:
Array
(
    [File] => Array
        (
            [@attributes] => Array
                (
                    .....
                    [TagsList] => 80-90 Summer      THE BEST        О лете
                    .....

И сейчас порядок тегов в списке тегов один, а в файл записывается по алфавиту. Можно ли добавить настройку, чтоб включать порядок сохранения в файл такой же как они отсортированы вручную в списке?
 
Ниче не понял... что за потоки имеются в виду... и о каком интернет потоке идет речь?
Это внутренняя информация для отладки.

Дмитрий, вы пишите в ответ то, что и так ежу понятно. Я понимаю, что проще, как всегда, отфутболить... но вы подумайте лучше сколько нужно городить лишнего чтобы вывести предыдущие/следующие. Почему бы не добавить 2 параметра в то действие - один отвечает за количество предыдущих, другой за следующих и все. И не надо ничего городить, одним запросом все получил и вывел
Плохой дизайн API если результат команд дублируется. И потом отлаживать это в двух местах для нас. Смысла нет, то, что вам нужно, уже делается средствами программы.

ричем тут stop? Читайте, пожалуйста, внимательно... речь идет про любую команду... Короче нельзя так...
Аналогично можно и другую команду, стоп был как пример.

Можно в поиске добавить комбинированный вариант, чтоб искало одновременно и по названии и по исполнителю и по имени файла ( с удалением дублей в результате), а то надоедает переключаться туда-сюда...
Да, добавим.
 
И потом отлаживать это в двух местах для нас.
Что ж там отлаживать - всего лишь задаётся сколько треков показывать предыдущих и следующих и все... никакой доп. отладки там нет, не выдумывайте. Что один выводить, что 5... А удобства куча, не нужно городить лишнего кода и лишних запросов. Как же вы этого не понимаете то ну...

Аналогично можно и другую команду, стоп был как пример.
Вот допустим как пример есть команда run _тут путь к файлу_ и вот в этом пути допустим есть сочетание АБВГД, вот если оно есть то тип такой-то, если нет то обычный для команд... напишу я допустим run.command - а дальше чего, как указать, что в команде должно быть сочетание АБВГД вот в этом вопрос.
 
Последнее редактирование:
И еще в результат действия getlastplayed не хватает рейтинга. И вообще, хотелось бы, чтобы все действия, где возвращаются треки содержали в себе сразу все данные о треках. Например, тот же trackinfo тоже без рейтинга... в playbackinfo тоже...
Учтем на будущее.

Почему readtag возвращает названия атрибутов маленькими буквами, когда все остальные большими, то есть Title вместо TITLE?

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

от это не понятно... что значит "только тег типа файла", то есть в типе файла Джингл можно искать по типу файла Комментарий или как тут это понимать? Или тут как-то не так обозвано... или я туплю..
Это значит будет работать только ручная установка типа через Track Tool или редактор треков в базе.
 
Не могу понять, что является разделителем тегов, как их в скрипте разбивать по какому символу, отделять друг от друга, чтоб читать/писать по АПИ через readtag/writetag.
Символ TAB (0x09).

Что ж там отлаживать - всего лишь задаётся сколько треков показывать предыдущих и следующих и все... никакой доп. отладки там нет, не выдумывайте. Что один выводить, что 5... А удобства куча, не нужно городить лишнего кода и лишних запросов. Как же вы этого не понимаете то ну...
Это не нужно потому что есть команда для получения последних треков и она полностью решает задачу.

Вот допустим как пример есть команда run _nen путь к файлу_ и вот в этом пути допустим есть сочетание АБВГД, вот если оно есть то тип такой-то, если нет то обычный для команд..
Тут не получится. Или пробовать идентификатор вроде .exe но тут уже могут быть ложные срабатывания.
 
Еще, пожалуйста, везде где в результате запроса АПИ выводится инфа о треках добавьте там атрибут с названием тип файла, тот что назначается через тректул, если не назначен то Музыка или автоопределение по идентификатору/папке, чтоб через скрипт по этому параметру обрабатывать по разному.

Также в действии getplaylist2 есть чудесный параметр "cnt" - максимальное количество треков в результате, 0 = все треки
Добавьте, пожалуйста, аналогичный в действие getlastplayed
 
Блин, уперся в еще один косяк... http запросы уходят не при смене трека, а при смене названия... весь скрипт ушел в цикл... Можно ли добавить опцию на что реагировать ибо это жесть?
 
И сейчас порядок тегов в списке тегов один, а в файл записывается по алфавиту. Можно ли добавить настройку, чтоб включать порядок сохранения в файл такой же как они отсортированы вручную в списке?
Не думаю, что такая настройка имеет смысл, если честно.

запроса АПИ выводится инфа о треках добавьте там атрибут с названием тип файла, тот что назначается через тректул, если не назначен то Музыка или автоопределение по идентификатору/папке, чтоб через скрипт по этому параметру обрабатывать по разному.
Зависит от запроса. Тип файла определен если вы получаете список треков из плейлиста. Если просто чтение тегов - там тип файла не определяется.

Также в действии getplaylist2 есть чудесный параметр "cnt" - максимальное количество треков в результате, 0 = все треки
Добавьте, пожалуйста, аналогичный в действие getlastplayed
Зачем это нужно? Вы можете получить список (он в любом случае не будет очень большим) и взять оттуда нужное кол-во треков. Ограничение для плейлиста есть т.к. иногда плейлисты могут быть очень большими.

http запросы уходят не при смене трека, а при смене названия... весь скрипт ушел в цикл... Можно ли добавить опцию на что реагировать ибо это жесть?
Запрос отправляется как только получены все необходимые значения, чтобы его сделать. Это происходит чуть позже, чем трек начал играть.
 
Не думаю, что такая настройка имеет смысл, если честно.
Имеет конечно, потому что в колонке в муз.базе, в плейлисте и т.д. у треков сразу видно какие-то важные теги, которые специально отсортированы первыми.

Тип файла определен если вы получаете список треков из плейлиста. Если просто чтение тегов - там тип файла не определяется.
В общем нужно иметь возможность определять тип файлов через скрипт, всех и любых(!), хоть каким запросом, но любых, и проигранных и в плейлисте и текущего и в муз.базе. Уже понятно что надо городить через скрипт все что надо, но хотя бы надо, чтоб была эта возможность получить все по максимум про любой файл, хоть через один запрос хоть через 100, но для любого файла... иначе нафиг такой апи.

Зачем это нужно?
Как зачем, для экономии времени, памяти, трафика и т.д. Зачем постоянно дергать результат из 100 треков если надо грубо говоря всего пару байт получить..

Запрос отправляется как только получены все необходимые значения, чтобы его сделать. Это происходит чуть позже, чем трек начал играть.
Какие значения? Я через сrhипт отправляю названия на сервер через setcasttitle в зависимости от того какие теги заданы треку. Это происходит через http запросы при смене трека (как думалось). И вот каждая такая отправка запускает http запрос, ибо при смене названия оно реагирует типа как новый трек и дергает запрос, в итоге скрипт уходит в цикл и все начинает тупить... и лог застирается чисто запросами ежесекундными. Надо чтоб запрос отправлялся не по тригеру смены названия, а именно при переходе на следующий трек.

Вы на этот ответите или нет? - https://radioboss.ru/community_ru/threads/radioboss-6-2-beta.4622/post-34446
 
Имеет конечно, потому что в колонке в муз.базе, в плейлисте и т.д. у треков сразу видно какие-то важные теги, которые специально отсортированы первыми.
Список внутренне сортируется для оптимизации скорости работы с тегами. Менять здесь ничего не будем.

В общем нужно иметь возможность определять тип файлов через скрипт, всех и любых(!), хоть каким запросом
Когда вы получаете содержимое плейлиста через getplaylist2 тип файла находится в поле FT_IDX (2 - первый тип в списке типов в настройках, 3 - второй и так далее).

Как зачем, для экономии времени, памяти, трафика и т.д. Зачем постоянно дергать результат из 100 треков если надо грубо говоря всего пару байт получить..
Это разве представляет какую-то значимую проблему, которую нужно решать? Там данных в любом случае несколько килобайт - ничто по современым меркам.

И вот каждая такая отправка запускает http запрос, ибо при смене названия оно реагирует типа как новый трек и дергает запрос, в итоге скрипт уходит в цикл и все начинает тупить...
Откуда здесь возьмется цикл? Ваш скрипт отправляет название, RadioBOSS делает HTTP запрос - на этом все.
 
Когда вы получаете содержимое плейлиста через getplaylist2 тип файла находится в поле FT_IDX (2 - первый тип в списке типов в настройках, 3 - второй и так далее).
Это хорошо, но нужно получать не только тип файлов которые в плейлисте, но и любых других. Для этого нужна какая-то команда типа trackinfo (такое вроде универсальное название у действия trackinfo, а работает тоже только треками в плейлисте, хотя для этого как раз можно использовать действие getplaylist2 с параметром pos.... а по trackinfo логично было бы получать инфу о любом указанном), где параметром fn можно передать путь и получить тип (если не относится ни какому типу ни по идентификатору ни по папке то возвращает по дефолту music и все).


Откуда здесь возьмется цикл? Ваш скрипт отправляет название, RadioBOSS делает HTTP запрос - на этом все.
ЕЩЕ РАЗ! Пожалуйста, уделите минутку и прочитайте внимательно и вдумчиво..

http запрос отправляется не при смене трека, а при смене НАЗВАНИЕ, то есть я скриптом в зависимости о наличия тега отправляю название через setcasttitle вида http://IP:PORT/?pass=PASSWORD&action=setcasttitle&title=тут_название, скрипт отрабатывает и опять срабатывает http запрос, так как название обновилось (причем даже если оно еще не поменялось, все равно реагирует) и оно так уходит в цикл, каждый запрос дергает скрипт который отправляет название и так по кругу. Причем вместе с этим дергаются и другие запросы, которые трогать не нужно, но они все там реагируют на смену названия, или точнее даже на просто приход названия, включая по запросу АПИ через setcasttitle - еще раз! даже если оно еще не поменялось! Вы можете просто сделать по уму, чтоб запрос отправлялся именно при смене трека либо добавить такую опцию, чтоб убрать эту проблему! ОНА ЕСТЬ!!! Я конечно добавлю костыль-проверку скриптом смену названия, чтоб убрать это повторение, но это не решает проблему в целом, а только для конкретного запроса на мой скрипт, другие запросы дергаться будут все равно не при смене трека, а при смене названия в потоке и это можно решать только в программе исправив или доп. настройкой, где можно будет указать для запроса, что должно быть триггером для его отправки. Не все запросы должны реагировать на смену названия.

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


Про порядок тегов? Отвечено ранее.
Извините, ошибся ссылкой (сообщение 107) - https://radioboss.ru/community_ru/threads/radioboss-6-2-beta.4622/post-34445
 
Статус
Закрыто для дальнейших ответов.
Назад
Верх