Замеченные ошибки/баги и всякие неудобства

scorp сказал(а):

потом я обработал в цельную, заодно скрипт почистил и эти невидимки как и положено

Нажмите, чтобы раскрыть...

Зачем это было сделано? Очень похоже, что кроме создания проблем, другого результата от этого нет.

scorp сказал(а):

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

Нажмите, чтобы раскрыть...

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

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

scorp сказал(а):

Странность.. на всех этих задано по 4 тега, их видно через свойства и треткул но в базе не вижу тупо путсо и подсказки нет тоже при наведении, колонку специально расширил, толку ноль

Нажмите, чтобы раскрыть...

Вероятно, это тоже следствие "работы" c Unicode, см. выше. Расширять колонки нет необходимости, если теги есть но не помещаются, это все равно будет видно.

scorp сказал(а):

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

Нажмите, чтобы раскрыть...

Исправим.

scorp сказал(а):

И добавьте там плиз там менюшку расширенную как в тректуле

Нажмите, чтобы раскрыть...

Это окно, в первую очередь, предназначено для массового редактирования тегов - и в этом случае, там не будет имени файла вообще. Если вы редактируете один трек, лучше сразу вызвать Track Tool.

scorp сказал(а):

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

Нажмите, чтобы раскрыть...

Это можно отключить в настройках Music Library.

djsoft сказал(а):

Зачем это было сделано? Очень похоже, что кроме создания проблем, другого результата от этого нет.

Нажмите, чтобы раскрыть...

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

djsoft сказал(а):

Тут не все так просто, например, нормализовать все пути в RadioBOSS нельзя, файл может вообще перестать находиться (если на диске оригинальное имя, а в базе нормализованное).

Нажмите, чтобы раскрыть...

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

djsoft сказал(а):

Вероятно, это тоже следствие "работы" c Unicode, см. выше.

Нажмите, чтобы раскрыть...

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

djsoft сказал(а):

Это окно, в первую очередь, предназначено для массового редактирования тегов - и в этом случае, там не будет имени файла вообще

Нажмите, чтобы раскрыть...

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


Еще эта постоянная запись тега первого уже задолбала..

scorp сказал(а):

Вы я так понимаю вообще не желаете вникать и исправлять эти баги.

Нажмите, чтобы раскрыть...

Как я говорил выше, тут нет именно "исправления" для того, что вы делаете - другое представление Unicode это другой файл для системы (смотря что именно меняется, конечно). SQLite сравнивает utf8_bin т.е. побайтово, MySQL сравнивает _ci т.е. игнорируются акценты и некоторые модификаторы Unicode. В 7.3 что сделаем по этой части MySQL/MariaDB будет работать также, как и SQLite, т.е. сравнивать побайтово. Таким образом, "Beyoncé" и "Beyonce" это будут разные треки (т.к. в системе оба файла могут быть в одной папке) - сейчас в MySQL они будут иметь одну общую запись.

scorp сказал(а):

Ок, я не говорю нормализовывать все подряд, будет достаточно если программа будет следовать логике уникальности и если я на диске нормализовал у себя в нфс а в базе осталось нфд, пусть просто добавит как новый трек ведь это 2 разных по сути

Нажмите, чтобы раскрыть...

После изменения так и будет.

scorp сказал(а):

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

Нажмите, чтобы раскрыть...

Может, невидимые символы, или в пути есть Unicode.

scorp сказал(а):

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

Нажмите, чтобы раскрыть...

Не думаю, что это имеет смысл именно в том окне, из-за того, что оно для массового редактирования.

scorp сказал(а):

Еще эта постоянная запись тега первого уже задолбала..

Нажмите, чтобы раскрыть...

Что имеется в виду?

djsoft сказал(а):

SQLite сравнивает utf8_bin т.е. побайтово, MySQL сравнивает _ci т.е. игнорируются акценты и некоторые модификаторы Unicode

Нажмите, чтобы раскрыть...

Я не очень силен в этих кодировках конечно не вникал, но сейчас у меня в мускуле на базе и таблицах так стоит utf8mb4_unicode_ci - то есть если сменить на utf8mb4_bin или utf8mb4_0900_bin то оно начнет различать или нужны еще каике-то правки в самой программе?
А вообще вроде как самая крутая новая это вида utf8mb4_0900_ai_ci

djsoft сказал(а):

из-за того, что оно для массового редактирования.

Нажмите, чтобы раскрыть...

Оно для любого редактирования.. хоть по одному хоть масово хоть стрелочками передвигаться вперед/назад, поэтому смысл есть.

djsoft сказал(а):

Что имеется в виду?

Нажмите, чтобы раскрыть...

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