RadioBOSS 6.2 [beta]

Статус
Закрыто для дальнейших ответов.
И еще было бы хорошо рядом с Log добавить вкладку Log API, где бы можно было отслеживать все запросы по АПИ.
 
Еще просьба сделать пару улучшений:

1) когда в поиске или через муз.базу отфильтровать треки по тегам или другим параметрам и выбрать их для редактирования через тректул, то сейчас после последнего из выбранных кнопка След. переключает на какой-то не из списка. Короче суть в том, чтоб навигация в тректуле была в пределах выбранных и кнопка Пред/След либо была неактивная когда первый/последний из выбранных смотришь.

2) просьба добавить опцию выбора при фильтрации по тегам - искать по любому из указанных (то есть ищет все треки где встречаются выбранные теги) либо по искать по всем указанным (то есть ищет как сейчас, чтоб встречались все указанные теги в треках).
Доп. вариант поиска по любому указанному очень упростит.

3) ну и еще было бы круто, если б поиск срабатывал даже при наборе в неверной раскладке, типа как в гугле когда вместо "осень" забыл переключить раскладку и набрал как бы русскими но английскими "jctym", а заодно еще и сразу, чтоб искало по транскрипции. Понимаю что это из области фантастики для вас, но вдруг у вас будет хорошее настроение и вам в кое веки захочется сделать что-то полезное для пользователя. :)
 
Уже просил, но напомню. Когда много тегов крайне неудобно крутить вертикально километр искать. Сделайте, пожалуйста, чтоб при расширении окна список переносился вот так колонками, это уберет ненужную прокрутку во многих случаях и намного упростит работу с тегами, их сортировку и т.д. В идеале к этому еще добавить поле фильтрации, когда вводишь символы и показывает только те, где встречается такое совпадение (как в поиске по трекам), это еще больше упростит и ускорит с ними работу. Доработайте, пожалуйста.

1662201510436.png
 
Начался трек, решил подправить название внизу плейлиста, скорректировал, сохранил, но в центральном окне сверху "В эфире" осталось старое название. Почему не меняется сразу?
Также пробовал переключить туда-сюда в Настройках - Вид что показывать в этом окошке - ничего не поменялось. Как эта опция работает не очень понятно, результата не вижу?
 
Это хорошо, но нужно получать не только тип файлов которые в плейлисте, но и любых других. Для этого нужна какая-то команда типа trackinfo (такое вроде универсальное название у действия trackinfo, а работает тоже только треками в плейлисте, хотя для этого как раз можно использовать действие getplaylist2 с параметром pos.... а по trackinfo логично было бы получать инфу о любом указанном), где параметром fn можно передать путь и получить тип (если не относится ни какому типу ни по идентификатору ни по папке то возвращает по дефолту music и все).
Какое у этого применение?

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

Тут вообще можно было бы добавить несколько триггеров (смена названия, смена трека, подключение к потоку слушателя, запрос трека (чтоб его сразу запросом добавить в плейлист, вместо того, чтоб на стороне сервера дергать постоянно кучей запросов кучу скриптов на проверки каждую секунду, но вы этого вообще не понимаете и об этом не думаете) и т.д. и т.п.), это если прям совсем осознанно делать по уму
Можно что угодно наворотить, но на это нулевой спрос, поэтому этого нет.
 
Как сделать, чтоб это работало?... надо через скрипт обрабатывать и для треков с определенным тегом отправлять по разному. Сейчас пока не удалось добиться, чтоб переменные обрабатывались посланные через этот запрос в action=setcasttitle
При вызове setcasttitle переменные не обрабатываются, запрос обрабатывается просто как текст.

А еще хотелось бы через АПИ управлять отправляемым названием в энкодерах, в типах файлов, этими главными метатегами в настройках, переключать режим обновления, включать/отключать в типах файлов
В будущих версиях будет команда API для редактирования некоторых настроек, там это должно быть.
 
И еще было бы хорошо рядом с Log добавить вкладку Log API, где бы можно было отслеживать все запросы по АПИ.
Их может быть очень много. Только если логгировать в файл. Много команд вообще не влияет на работу - вродe playbackinfo или подобные.

1) когда в поиске или через муз.базу отфильтровать треки по тегам или другим параметрам и выбрать их для редактирования через тректул, то сейчас после последнего из выбранных кнопка След. переключает на какой-то не из списка. Короче суть в том, чтоб навигация в тректуле была в пределах выбранных и кнопка Пред/След либо была неактивная когда первый/последний из выбранных смотришь.
Эти кнопки не должны срабатывать в таком случае. Проверим.

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

3) ну и еще было бы круто, если б поиск срабатывал даже при наборе в неверной раскладке, типа как в гугле когда вместо "осень" забыл переключить раскладку и набрал как бы русскими но английскими "jctym", а заодно еще и сразу, чтоб искало по транскрипции. Понимаю что это из области фантастики для вас, но вдруг у вас будет хорошее настроение и вам в кое веки захочется сделать что-то полезное для пользователя.
Русский язык для программы не основной, как и пользовательская база, экономического смысла здесь немного.

Уже просил, но напомню. Когда много тегов крайне неудобно крутить вертикально километр искать. Сделайте, пожалуйста, чтоб при расширении окна список переносился вот так колонками
Сейчас там сам по себе элемент управления из одной колонки, переделка его под много колонок пока неоправдана с точки зрения трудозатрат и финансового результата.
 
Также пробовал переключить туда-сюда в Настройках - Вид что показывать в этом окошке - ничего не поменялось. Как эта опция работает не очень понятно, результата не вижу?
Она обновляется только при смене трека, или обновлении названия если играет поток.
 
Какое у этого применение?
Нужно для обработки в скриптах и вывода на сайте.

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

Можно что угодно наворотить, но на это нулевой спрос, поэтому этого нет.
Ну так и спроса нет потому, что этого нет.

При вызове setcasttitle переменные не обрабатываются, запрос обрабатывается просто как текст.
Да, добавьте, пожалуйста, их обработку при отправке в этом действии.

Их может быть очень много. Только если логгировать в файл. Много команд вообще не влияет на работу - вродe playbackinfo или подобные.
Это надо для отладки и чтоб видеть что вообще все запросы приходят как нужно и т.д.

Пока подождем будут ли еще запросы на это.
Это правда нужно, потому что можно выбрать нужные теги и увидеть сразу все, что с ними, а не перебирать отдельно каждый. А сейчас получается вводишь 2-3 тега и находит только то где они все встречаются. Понимаете насколько это неудобно? Иногда да нужно указать конкретные и чтоб нашло только где они как сейчас это работает, но в основном надо "любой из указанных"

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

Главная проблема еще и в том, что вы и сами не хотите сделать по уму и у пользователя такой возможности нет, ибо нет возможности многое реализовать или через АПИ или через плагины (так как их нет) и т.д. То есть вы просто тупо ставите пользователя перед фактом - вот я так захотел и сделал, так мне нравится и проще, потратил 5 минут всего-то тяп-ляп, а ты пользователь хочешь пользуйся, хочешь нет, мне как бы пофиг на твои потребности. Вот так это звучит каждый раз, когда появляются словосочетания "неоправданно", "финансово необоснованно" и т.п.
 
Последнее редактирование:
Обращаюсь к народу, кто пользуется РадиоБосс - вы бы хоть поддержали предложения, или вам неинтересно, чтоб продукт был удобнее и функциональнее? Даже если вы пока какими-то опциями не пользуетесь, но видите в них плюсы.
 
Обращаюсь к народу, кто пользуется РадиоБосс - вы бы хоть поддержали предложения, или вам неинтересно, чтоб продукт был удобнее и функциональнее? Даже если вы пока какими-то опциями не пользуетесь, но видите в них плюсы.
Я восторгаюсь Вашей настойчивость и естественно поддерживаю, и не только эти предложения. Три года ждём нормальную систему ретрансляции и её резервирования. На все предложения : нет смысле, не востребован и тд. Прога интересная и перспективная, но отношение автора... Мы махнули рукой и ушли к конкурентам. К сожалению. Да дороже, но всё работает как надо пользователю. Может со временем и вернёмся но не сейчас, нервы дороже
 
Нужно для обработки в скриптах и вывода на сайте.
Если вы выводите плейлист, то там информация о типе файла есть.

Дмитрий, в snjkmrj вдумайтесь в тот бред, который вы сейчас пишите. Я же пояснил вам все подробно и четко видно, что http-запросы реагируют на любую смену названия, а поскольку скрипт как раз и отправляет(обновляет) название в зависимости от наличия в треках определенных тегов, то и получается, что поменялся трек и соответственно название, на эту смену названия среагировали http-запросы, запустился скрипт, он отправил новое название и на это опять среагировали http-запросы и опять дёрнули скрипт и все ушло в цикл
Вы так настроили, что у вас происходит зацикливание. Как вариант можете настроить локальный веб сервер, который будет проксировать и фильтровать запросы. Вы же понимаете, что менять поведение программы ради одного вашего конкретного случая - это не то, что будет происходить.

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

Да, добавьте, пожалуйста, их обработку при отправке в этом действии.
Если честно я не вижу как и где это можно применить.

Это правда нужно, потому что можно выбрать нужные теги и увидеть сразу все, что с ними, а не перебирать отдельно каждый. А сейчас получается вводишь 2-3 тега и находит только то где они все встречаются. Понимаете насколько это неудобно? Иногда да нужно указать конкретные и чтоб нашло только где они как сейчас это работает, но в основном надо "любой из указанных"
По тегам обычно интересно как раз выбор где все сразу, чтобы сузить количество результатов. Опять же подождем если у кого-то что есть добавить на этот счет.

Вот так это звучит каждый раз, когда появляются словосочетания "неоправданно", "финансово необоснованно" и т.п.
У вас очень много запросов. Причем по всем секторам программы, и много из них, по вашему же признанию - вам даже не нужно, а просите добавить "пусть будет мало ли когда-нибудь пригодится". В плане развития программы - лучше меньше, но лучше. Я вам уже говорил про это. Увешивать программу кучей настроек, как новогоднюю елку, и когда эти настройки нужны 0.001% пользователей, а остальным они не просто не нужны, а мешают и воруют их время (надо разобраться зачем оно, плюс возможность что-то испортить). Вот такое нам не нужно, разработки больше, программа сложнее (то есть, хуже), продаж меньше.
 
Три года ждём нормальную систему ретрансляции и её резервирования. На все предложения : нет смысле, не востребован и тд.
Да, вот про резервирование - это мало кто просил поэтому мы решили делать другие функции пока что.
 
Если вы выводите плейлист, то там информация о типе файла есть.
Я не только плейлист хочу выводить но и все остальное и до и после и т.д.. И мне нужна вся инфа по любому треку, чтобы обрабатывать все так как мне нужно. Поэтому и говорю, что если бы какое-то действие типа trackinfo или readtag и т.п. возвращало по пути к файлу всю инфу о нем, то можно было бы везде ее получить... хоть в плейлисте хоть где. А так везде тупик... только там где вы дали возможность и есть... а дальше хоть бейся головой об стенку..

Вы так настроили, что у вас происходит зацикливание.
Что значит я так настроил? Это программа дергает http-запросы на каждую смену названия, поэтому оно и уходит в цикл.
И я не предлагаю что-то менять, я предлагаю просто добавить опцию, где можно включить реагирование http-запросов не на смену названия, а именно на смену треков и все, вопрос отпадет, и плюс не будут дергаться другие запросы когда не нужно. Даже если я там примудрю какую-то фильтрацию, то другие скрипты и запросы оно все равно дергает на каждый чих (смену названия), когда этого делать совершенно не нужно. Поймите вы наконец, что это просто дичь!

У вас очень много запросов. Причем по всем секторам программы, и много из них, по вашему же признанию - вам даже не нужно, а просите добавить "пусть будет мало ли когда-нибудь пригодится".
Не правда, не "много из них", а лишь некоторые, которые могут пригодиться позже. 99% мне нужно уже!

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

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


Просто поражает такой подход... сделать такой толковый софт и сделать его как-попало и нежелание довести до ума... доработать, чтоб было удобно пользователю и т.д. Таких упертых я еще не встречал. Это прям железобетонная стена какая-то...
 
Последнее редактирование:
это мало кто просил
Если память мне не изменяет как минимум трое ещё сразу же подключились. И вы обещали, что в 6.0 это будет. Но потом как обычно: в следующем обновлении и т.д. А обращений нет конкретно по ретрансляции, потому что достаточно поиском по форуму поискать на эту тему и ответ очевиден: как нибудь потом сделаем. А Роскомнадзор ждать не будет и за перебои в вещании не погладит по головке, да и головные станции на это не будут смотреть сквозь пальцы. Вот и результат. У нас регион не богатый, ваш софт был бы очень востребован ибо доступен. Я знаю многих своих коллег - технарей по области, они не перешли на радиобосс только из за не работающей нормально системы резервирования ретрансляции. Это порядка 40-45 станций, и это только одна область. А в России таких не богатых регионов ой сколько. В общем доказывать что то не буду. У вас своё видение развития программы. Удачи. Но пока нам не по пути
 
Я не только плейлист хочу выводить но и все остальное и до и после и т.д.. И мне нужна вся инфа по любому треку, чтобы обрабатывать все так как мне нужно. Поэтому и говорю, что если бы какое-то действие типа trackinfo или readtag и т.п. возвращало по пути к файлу всю инфу о нем, то можно было бы везде ее получить... хоть в плейлисте хоть где. А так везде тупик... только там где вы дали возможность и есть... а дальше хоть бейся головой об стенку..
Отдельной команды для этого точно не будет, посмотрим, можно ли это включить в результат для команды readtag.

Что значит я так настроил? Это программа дергает http-запросы на каждую смену названия, поэтому оно и уходит в цикл.
И я не предлагаю что-то менять, я предлагаю просто добавить опцию, где можно включить реагирование http-запросов не на смену названия, а именно на смену треков и все, вопрос отпадет, и плюс не будут дергаться другие запросы когда не нужно. Даже если я там примудрю какую-то фильтрацию, то другие скрипты и запросы оно все равно дергает на каждый чих (смену названия), когда этого делать совершенно не нужно. Поймите вы наконец, что это просто дичь!
Пока что на это никто не жалуается, а раз так, то что-то там менять не нужно. В вашем случае фильтрация это решение.

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

Просто поражает такой подход... сделать такой толковый софт и сделать его как-попало и нежелание довести до ума... доработать, чтоб было удобно пользователю и т.д. Таких упертых я еще не встречал. Это прям железобетонная стена какая-то...
Ваше видение - это большое количество настроек, на каждую мелочь, пусть они не нужны даже, пусть будут. У нас видение другое, чтобы оно без возни с настройками сразу работало.
 
Если память мне не изменяет как минимум трое ещё сразу же подключились. И вы обещали, что в 6.0 это будет. Но потом как обычно: в следующем обновлении и т.д.
Эта функция все еще в очереди, поэтому да, как-нибудь сделаем. Ретрансляции уделено много внимания было, и нужно заниматься и другими вещами тоже.
 
Команды
generate preset_nameСгенерировать плейлист используя пресет preset_name, созданный в генераторе плейлистов. Например, пресет под названием "ROCK 2 Hours" (без кавычек), чтобы по расписанию создать плейлист по этому шаблону, используется команда generate Rock 2 hours

Добавьте, пожалуйста, параметр, через который можно передать как вставлять - из этих вариантов

1662642403416.png


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

И еще на запуск батника присобачьте, пожалуйста, скрытие окошка командной строки, а то мелькает постоянно (я знаю так можно, чтоб батник выполнялся невидимкой)
Имеете в виду запуск cmd.exe через команду run? Не думаю, что тут получится, run делает запуск в общем виде - и вообще не разбирается, консольное это приложение или еще какое-то. Возможно, для cmd есть параметры чтобы не показывать окно.
 
Плейлист, созданный таким образом, запускается в соответствие с настройками задания - аналогично обычному заданию, которое запускает файл плейлиста.
Да, сейчас в этой команде нет возможности указать как вставлять сгенерированный плейлист. Логично, чтоб она была, чтоб можно было указать для каждого случая куда вставлять. Добавьте, пожалуйста, такой параметр, чтобы команда была полноценной.

Имеете в виду запуск cmd.exe через команду run?
Имею в виду запуск file.bat и при запуске мелькает на секунду-две окно командной строки черное это. Как-то оно глушится типа в режим silent или hidden и т.п, чтоб его вообще не было видно.
 
Статус
Закрыто для дальнейших ответов.
Назад
Верх