Тоже самое будет если и по одному треку редактировать. Видимо, когда вы вызываете параметры одного трека, вы не меняете сам тег (название, исполнитель и т.п.) - в этом случае пересохранения тега не происходит, а сохраняются только доп. параметры (фейды и прочее). При массовом редактировании тег пересохраняется всегда.1moment сказал(а):
Научите базу вести статистику треков
- Автор темы 1moment
- Дата начала
Я же выше про это и говорил. При редактировании одного трека, Track Tool еще разбирается, сохранять основной тег или нет (будет сохранять только если тег был изменен). При массовом редактировании пересохраняется полностью и основной и дополнительный тег, всегда, даже если вы вообще ничего не изменяли.1moment сказал(а):
1moment
Member
Странная у вас логика:
1) Вам указали на ошибку в программе. Ваш ответ: не будем исправлять ошибку потому что тэг читают все, кроме "какой-то" ОПЕРАЦИОННОЙ СИСТЕМЫ на которой работает наша программа.
2) Вас просят сделать так, чтобы база не трогала тэги, с которыми НЕ УМЕЕТ
толком работать. Ваш ответ: не будем запрещать базе уродовать эти тэги, которые хоть и устарели, но еще используются (не съедим, но понадкусываем). Впротивном случае - редактируйте по одному треку, ведь тут наш косяк не всплывает (видимо вам кажется что так удобней ??? )
3) А с чего вы вообще решили, что ваша база - это лучший софт для редактирования тэгов, что она впереди планеты всей и что она вправе "решать" как все должно быть????
Ну и наконец создается впечатление, что у вас просто нет желания проводить работу над ошибками (А это именно ошибка!!!). Конечно проще отмахнуться от проблемы, чем решить ее раз и навсегда. Но Вас, как разработчика "профессионального" ;D софта, такое отношение не красит.
Или я не прав?
1) Вам указали на ошибку в программе. Ваш ответ: не будем исправлять ошибку потому что тэг читают все, кроме "какой-то" ОПЕРАЦИОННОЙ СИСТЕМЫ на которой работает наша программа.
2) Вас просят сделать так, чтобы база не трогала тэги, с которыми НЕ УМЕЕТ
толком работать. Ваш ответ: не будем запрещать базе уродовать эти тэги, которые хоть и устарели, но еще используются (не съедим, но понадкусываем). Впротивном случае - редактируйте по одному треку, ведь тут наш косяк не всплывает (видимо вам кажется что так удобней ??? )3) А с чего вы вообще решили, что ваша база - это лучший софт для редактирования тэгов, что она впереди планеты всей и что она вправе "решать" как все должно быть????
Ну и наконец создается впечатление, что у вас просто нет желания проводить работу над ошибками (А это именно ошибка!!!). Конечно проще отмахнуться от проблемы, чем решить ее раз и навсегда. Но Вас, как разработчика "профессионального" ;D софта, такое отношение не красит.
Или я не прав?
1. Писать тег id2v2.4 это не ошибка.
2. При редактировании даже по одному треку версия тега будет изменена (если вы внесли изменения в сам тег).
3. База работает по стандартам. Теги пишутся корректно и читаются (и редактируются) другими программами.
Проблема здесь именно в проводнике, который не может читать общепринятый стандарт тега. Странно, что у вас нет претензий к Windows (который не читает тег потому что не полностью поддерживает стандарт), но есть претензии к RadioBOSS, который стандарт как раз поддерживает. И исправление, если его будем делать мы - получается, мы исправляем чужую ошибку.
Вообще, все, что касается тегов, требует очень тщательного тестирования - пользователей много, треков вообще несчетное количество, любое изменение в этой системе может у кого-то что-то поломать
Так как просмотр тегов через проводник задача весьма редкая, решение этой проблемы не является приоритетным. Тем более, что проводник в этом случае читает id3v1, т.е. показывает хоть что-то.
Добавление
Думаю, сделаем так, что версия тега id3v2 не будет меняться, изменение будет в версии RadioBOSS 5.6.
2. При редактировании даже по одному треку версия тега будет изменена (если вы внесли изменения в сам тег).
3. База работает по стандартам. Теги пишутся корректно и читаются (и редактируются) другими программами.
Проблема здесь именно в проводнике, который не может читать общепринятый стандарт тега. Странно, что у вас нет претензий к Windows (который не читает тег потому что не полностью поддерживает стандарт), но есть претензии к RadioBOSS, который стандарт как раз поддерживает. И исправление, если его будем делать мы - получается, мы исправляем чужую ошибку.
Вообще, все, что касается тегов, требует очень тщательного тестирования - пользователей много, треков вообще несчетное количество, любое изменение в этой системе может у кого-то что-то поломать
Так как просмотр тегов через проводник задача весьма редкая, решение этой проблемы не является приоритетным. Тем более, что проводник в этом случае читает id3v1, т.е. показывает хоть что-то.Добавление
Думаю, сделаем так, что версия тега id3v2 не будет меняться, изменение будет в версии RadioBOSS 5.6.
Дмитрий, извините за оффтоп.
Скажите пожалуйста, когда примерно будет обновление RadioBOSS 5.6 и будет ли в обновлении внешняя база для доп. информации о треках ?
+ планируеться ли в версии 5.6 обновить команду makelibrary, чтобы команда смогла обновлять данные о доп. информации из файлов.
Скажите пожалуйста, когда примерно будет обновление RadioBOSS 5.6 и будет ли в обновлении внешняя база для доп. информации о треках ?
+ планируеться ли в версии 5.6 обновить команду makelibrary, чтобы команда смогла обновлять данные о доп. информации из файлов.
Да, база должна быть (если внутреннее тестирование пройдет успешно) - но она будет не то, чтобы внешняя, начнем с локальной, вроде SQLite. Далее, вероятно, добавим и другие возможные драйверы БД. Но уже локальная база даст несколько преимуществ: не будут писаться теги в файлы, и генератор плейлистов сможет быстрее загружать все эти данные.avg сказал(а):
Имеется в виду Playcount и прочие поля тегов?avg сказал(а):
djsoft сказал(а):
Извините, не совсем корректно написал по поводу "makelibrary", имел в виду расширение функционала данной команды (перечитать теги, сканировать треки на тишину и т.п.).
О данном функционале мы с Вами беседовали здесь http://www.radioboss.ru/smf_ru/index.php/topic,3680.0.html
Перечитывание тегов произойдет при пересоздании базы, т.е. это уже и так есть. По поводу отрезания тишины, это очень интенсивная задача с точки зрения процессора и диска, и когда это выполняется через базу, процесс можно прервать, но если процесс запущен через планировщик, то это уже не остановить, только закрывать сам RadioBOSS что далеко не всегда приемлемо.avg сказал(а):
1moment
Member
Здравствуйте. Пытаюсь разобраться с SQLite. В настройках в пункте Additional track information storage location выбрал Database (SQLite). Скажите это всё? То есть теперь такая информация как Last played и Playcount должна сохраняться где-то??? Просто складывается впечатление что это не так! Я это вижу по джинглам у которых "Количество запусков" = 0 или 1 (это за 2 суток эфира). Хотя вчера переустанавливал RB. Могла ли переустановка повлиять на статистику? Если ДА, то какой смысл такой базы, которая обнуляется при переустановке программы? Помогите пожалуйста разобраться
Файл при удалении программы не удаляется, если не указывать "Удалять настройки". Но даже с удалением настроек он будет удален только если в этой папке нет других настроек (от других установок RadioBOSS, RadioCaster и т.п.)avg сказал(а):
Это будет в обновлении 5.6.0.2.avg сказал(а):
