Вопрос по обновленной МУЗ БАЗЕ

[Максим.Осадчи]

Самый главный вопрос остается: зачем переименовывать файлы после того, как их начали ставить в эфир?

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

Ну, ок, один пример:
В базу был добавлен файл, в названии которого содержится ошибка. Ну, например:
In-Grid названа как InGrid;
Guns N' Roses - названы как Guns N` Roses (разница - в апострофе);
группа СКАЙ записана как CКАЙ (разница в заглавной букве - кириллическая "С" и латинская "С")...
Ну и т.д., можно продолжать...

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

Я вам со всей ответственностью авторитетно заявляю: переименование файла - не должно нести за собой потерю разметки файла и прочей дополнительной информации о нём в базе.
Нет, я могу конечно найти программу для редактирования содержания *.db файлов, но зачем мне этот менингит? Если программа ведёт базу - она должна иметь штатное средство для редактирования оной.

 

[scorp]

Если программа ведёт базу - она должна иметь штатное средство для редактирования оной.

Да все это не сложно сделать средствами РБ, было бы желание.

вести реестр плейлистов, заданий и т.п.

А сейчас программа что не в курсе какие задания стоят в планирвоащике. Ну ладно уже сгенерированные и сохраненные плейлисты то да, это уже не к делу, но то чем управляет сам РБ там он все видит и может поменять.

 

[Максим.Осадчи]

Ещё вот такой вопрос назрел:

Файл базы лежит здесь %userprofile%\AppData\Roaming\djsoft.net\
называется tracks.db

- Если на компьютере работают сразу две копии RadioBOSS - этот файл базы будет один общий для обеих инстанций программы получается?

 

[djsoft]

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

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

Название/исполнитель берется из имени файла только в случае отсутствия тега.

Если программа ведёт базу - она должна иметь штатное средство для редактирования оной.

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

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

Да все это не сложно сделать средствами РБ, было бы желание.

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

А сейчас программа что не в курсе какие задания стоят в планирвоащике. Ну ладно уже сгенерированные и сохраненные плейлисты то да, это уже не к делу, но то чем управляет сам РБ там он все видит и может поменять.

Проще не переименовывать файлы. И проблемы нет. Зачем нужны эти переименования так никто не сказал, кстати

Если на компьютере работают сразу две копии RadioBOSS - этот файл базы будет один общий для обеих инстанций программы получается?

Да, все копии работают с одной базой.

 

[Drakkar]

Да, все копии работают с одной базой.

C чего бы это вдруг? Каждая копия программы работает со своей базой. Для этого создаётся отдельная папка по адресу C:\Users\Radio\AppData\Roaming\djsoft.net\RadioBOSS_1093489440, где 1093489440 это одна копия РБ ... Цифры могут у вас отличаться.

 

[avg]

Да, все копии работают с одной базой.

C чего бы это вдруг? Каждая копия программы работает со своей базой. Для этого создаётся отдельная папка по адресу C:\Users\Radio\AppData\Roaming\djsoft.net\RadioBOSS_1093489440, где 1093489440 это одна копия РБ ... Цифры могут у вас отличаться.

Уважаемый, Вы наверно перепутали, здесь идет речь о базе SQLite, а база SQLite хранится в %userprofile%\AppData\Roaming\djsoft.net\
файл называется tracks.db

 

[djsoft]

C чего бы это вдруг? Каждая копия программы работает со своей базой.

Файл базы для дополнительной информации (Tracks.db) хранится не в этой папке, а выше уровнем.

 

[Drakkar]

Понял, но я никогда не обращался к этому файлу. Даже и не знаю, что за ситуация бы меня заставила обратиться к Tracks.db. У меня 3 копии РБ комфортно отрабатывают каждая своё музыкальное направление.

 

[djsoft]

Понял, но я никогда не обращался к этому файлу. Даже и не знаю, что за ситуация бы меня заставила обратиться к Tracks.db. У меня 3 копии РБ комфортно отрабатывают каждая своё музыкальное направление.

С этим файлом вручную ничего делать и не нужно.

 

[Pavel-93RUS]

Проще не переименовывать файлы. И проблемы нет. Зачем нужны эти переименования так никто не сказал, кстати

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

 

[djsoft]

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

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

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

 

[Максим.Осадчи]

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

Как работать с мп3 тегами и какими программами их удобно править - это как раз не проблема (для меня, например). И то, что всегда можно подправить имя файла в теге - это тоже прекрасно.
Но я писал выше, Вы как-то пропустили этот момент почему-то: для работы, например, в моей схеме используются два эфирных компьютера. Основная часть эфира идёт с одной машины, а какая-то часть эфира - с другой машины. Всю фонотеку (музыку и программы) нужно держать синхронизированными на обеих компьютерах.
При этом - плейлист не набирается посредством генератора плейлистов РадиоБосс-а. Используется внешний шедулер. Однако, генератор РадиоБосс-а используется для ротации программ по расписанию.
Короче, это всё долго и некогда объяснять и приводить всю эту кучу аргументов.

Суть вот в чем: Есть (!!!) необходимость иметь возможность переименовать файл, сохранив при этом все данные о нём в базе! Вот и всё.

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

Собственно, всё.

 

[Novossyol]

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

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

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

Я конечно и прописываю тэги заново, вычищая их из того говна и хлама которым наполнена сеть, но делаю это исключительно из ИМЕНИ ФАЙЛА (для вещания мне не нужен ни год ни альбом), и считаю, что имя файла первично и нужно отталкиваться от него, а всё остальное вторично. Тэги можно вообще не прописывать. Делаю это пока по привычке.
Муз. трек может прекрасно существовать и без тэга, но вот без имени файла существовать не может. Расставьте приоритеты правильно!

 

[djsoft]

приспособить её под существующие реалии пользователей

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

Муз. трек может прекрасно существовать и без тэга, но вот без имени файла существовать не может. Расставьте приоритеты правильно!

Приоритет - использование тегов, так было и будет. Нет никаких объективных причин отказываться от использования тегов.

 

[Максим.Осадчи]

Вы предлагаете программу приспособить под свои конкретные реалии,

- Это не мои конкретные реалии. Это реалии любого вменяемого вещателя (не мальчика, который играется дома в интернет-радио). И любой более-менее опытный вещатель вам это подтвердит.

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

- То есть, прислушиваться к потребностям и опытному мнению лицензионных пользователей, которые платят за Вашу работу - это тупик? Довольно странны Ваши слова.

В настоящий момент нет планов по добавлению функций переименований файлов и подобного.

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

Использование тегов вместо переименований файлов полностью решает проблему. Предлагаю рассмотреть этот вариант.

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

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

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

 

[djsoft]

Это реалии любого вменяемого вещателя (не мальчика, который играется дома в интернет-радио).

Правильно ли я понял, что те, кто не занимается регулярным переименованием файлов - играющиеся в игрушки мальчики? Я бы сказал, что все наоборот. Если радио занимаются более-менее всерьез, а не поиграться, то там каждый трек проходит хоть какой-никакой минимальный контроль и подготовку, и после этого никаких переменований нет по двум, как минимум, причинам: 1) это просто не нужно, информация о треке читается и пишется из тегов и 2) это вредно и создает проблемы на ровном месте, так как файл уже есть в плейлистах, базах, заданиях и его переименование поломает эти плейлисты, базы и т.п. Плюс, это рвет связь с внешней базой данных, с чем вы и столкнулись. Именно из-за 2) не хотелось бы поощрять такие операции, так как это только нагрузит нашу техподдержку вопросами в стиле "мой файл не выходит в эфир".

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

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

Придётся пользоваться тем, что есть и по прежнему искать методы и способы "выкручиваться".

Один из способов "выкрутиться" я предолжил: не переименовывать файлы
Другой способ (плохой, предупреждаю сразу) - редактировать Tracks.db меняя там старое название файла на новое, используя какой-нибудь "Database browser for SQLite". Можно даже на фрилансерском сайте заказать разработку утилиты, которая будет переименовывать фпйлы и менять базу.

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

 

[Ian]

В общем, какая-то неразбериха с новой БД.
Хоть ты тресни, но при одинаковых установках программы на сервере и программы на моём рабочем компьютере, новая БД не работает.

Теги в файлах, отредактированные в программе, установленной на моём компьютере, не видит программа, установленная на сервере.
Т.е. я у себя тут редактирую пачку файлов, а когда закидываю на сервер -- в плей-листе нет и намёка на расставленные теги. А вот в старой версии, отредактированные на другом компьютере файлы отрабатывали как надо. Что происходит теперь -- вообще никак понять не могу. Догадываюсь только!

Скорее всего, Базы SQLite две -- каждая, на своём компьютере, а поскольку при работе в режиме SQLite, информация в файл не записывается, то "отредактированный" файл на другой копии программы не читает расставленных меток.
В старой версии, когда читались метки из тегов, любая копия RB исправно читала эту информацию.


Так может сделать одну базу и вынести её в облако?
Она же занимает мало места! Давайте дадим возможность, все копии RB подключаться к БД, хранящейся в облаке! Думаю, что это снимет проблему.

 

[Ian]

Ну, ок, один пример:
В базу был добавлен файл, в названии которого содержится ошибка. Ну, например:
In-Grid названа как InGrid;
Guns N' Roses - названы как Guns N` Roses (разница - в апострофе);
группа СКАЙ записана как CКАЙ (разница в заглавной букве - кириллическая "С" и латинская "С")...
Ну и т.д., можно продолжать...

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

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

 

[Ian]

%userprofile%\AppData\Roaming\djsoft.net\

На конец-то я узнал, где лежит база данных!

 

[Novossyol]

Приоритет - использование тегов, так было и будет. Нет никаких объективных причин отказываться от использования тегов.

А можете предоставить развёрнутое обоснование приоритета преимущества тэгов перед именами файлов? Для меня это пока НЕ очевидно...

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

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

Может всё же сменить приоритеты, а Дмитрий, дабы у юзверей головы не болели? 
Вопрос: база данных может работать только с именами файлов или нет?

Меня всё время не покидает подспудное ощущение того, что мы все время углубляемся "куда-то не туда"...  ???