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

  • Автор темы Автор темы scorp
  • Дата начала Дата начала
Я не могу никак понять что за фигня такая..
Есть 2 трека с одинаковым именем файла, один из которых отличается в конце наличием цифры 2
Есть 2 базы, одна обновляется из папки, другая из плейлиста, в плейлист попадает трек с цифрой 2 в имени файла (хотя не должен по исключению по тегу Short при генерации плейлиста)

В базе из плейлиста он отображается с одним тегом ALL

1788910607408.png


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

1788910793358.png


Вот как так? что за магия такая? Один и тот же трек в разных базах отображается по разному с разными параметрами.
1788911729015.png


Когда я в базе где он один с одним тегом и двойкой в имени попытался добавить доп.теги то не добавляет, то есть как бы видит что они там уже есть, но их не отображает в той базе почему-то..
 
Последнее редактирование:
Нужно это поправить - или пусть обновляет или пусть добавляет отдельной записью.
Не думаю, что тут стоит что-то исправлять, вы закачиваете треки, они попадают в базу, что кто-то будет менять представление символов Unicode и туда-сюда перезакачивать файлы - это не тот сценарий, который кому-то нужен на практике.
В вашем случае проще всего удалить треки и загрузить их заново, наверное.
 
Не думаю, что тут стоит что-то исправлять, вы закачиваете треки, они попадают в базу, что кто-то будет менять представление символов Unicode и туда-сюда перезакачивать файлы - это не тот сценарий, который кому-то нужен на практике.
В вашем случае проще всего удалить треки и загрузить их заново, наверное.
Ну там же по сути разные символы и путь соответственно должен считаться другим и оно должно добавлять как новую запись.. а оно видит что якобы трек уже есть и все.. тупик.. Сейчас там конкретный баг, я вам описал исследования свои, а вы считаете это нормальным что оно пропускает треки при обновлении базы.. Там видимо у вас проверка их при сканировании когда сравнивает путь нормализует его, отсюда и не видит разницы. Это ненормально.. абсолютно..
 
Когда я в базе где он один с одним тегом и двойкой в имени попытался добавить доп.теги то не добавляет, то есть как бы видит что они там уже есть, но их не отображает в той базе почему-то..
Информация читается всегда из одного места (таблица tracks2) т.е. разный результат не может быть из-за того, на основе чего создана база - неважно, какой источник был изначально плейлист или другая база или просто через интерфейс добавили.
Может, есть еще другие копии этого трека, и поэтому вот так.
 
Там видимо у вас проверка их при сканировании когда сравнивает путь нормализует его, отсюда и не видит разницы. Это ненормально.. абсолютно..
Путь, который отличается только разным представлением Unicode - это один путь. Я не знаю, что вы хотите сделать, но уже видно, что это приносит много проблем при отсутствии видимой пользы. Поэтому проще, видимо, удалить треки, можно после этого переиндексировать базу, и загрузить все заново.
 
Информация читается всегда из одного места (таблица tracks2) т.е. разный результат не может быть из-за того, на основе чего создана база - неважно, какой источник был изначально плейлист или другая база или просто через интерфейс добавили.
Может, есть еще другие копии этого трека, и поэтому вот так.
Так и я понимаю что оно должно отображать в этих базах один и тот же трек одинаково, но вот я увидел разницу такую.. других копий нету, я проверял!
 
Я не знаю, что вы хотите сделать, но уже видно, что это приносит много проблем при отсутствии видимой пользы
Я хочу чтоб путь к файлу в базе был идентичен полностью тому который у файла в системе, а так то да это приносит много проблем. Уже столько всяких обходных путей приходиться городить при работая с РБ что еще не хватало отслеживать отдельнеые треки с тразным представлением юникода и их как-то бегать удалять и потом опять загружать.. бред какой-то.. Есть очевидный баг, который вы не желаете поправить, вот что я вижу. Раз вы завязали программу на уникальность пути то сравнение должно учитывать различия эти тоже. А так ожидаешь и ориентируешься уже на этот путь, а оно бац и вдруг разные имена видит как одно.. здрасти приехали..
 
Так и я понимаю что оно должно отображать в этих базах один и тот же трек одинаково, но вот я увидел разницу такую.. других копий нету, я проверял!
Технически разницы быть не может, почему у вас так - непонятно, как вариант, база была открыта, изменеия были сделаны позже и данные в открытой базе не обновились.

Уже столько всяких обходных путей приходиться городить при работая с РБ что еще не хватало отслеживать отдельнеые треки с тразным представлением юникода
Откуда такие треки вообще берутся? Думаю, это не будет новостью, но про эту "проблему" больше никто не пишет. Вы делаете что-то странное, получаете не менее странный результат, я предлагаю просто не заниматься таким.
 
Технически разницы быть не может, почему у вас так - непонятно, как вариант, база была открыта, изменеия были сделаны позже и данные в открытой базе не обновились.
Вот почему у вас так не понятно, а я говорю что вижу и как есть. База уже переоткрывалась не раз и напрямую запросом в мускуле делал.. Что это за баги и глюки такие я не знаю. Вам похоже тоже не интересно.

Откуда такие треки вообще берутся? Думаю, это не будет новостью, но про эту "проблему" больше никто не пишет. Вы делаете что-то странное, получаете не менее странный результат, я предлагаю просто не заниматься таким.
А я откуда знаю откуда они такие беруться, но это вызвало проблему при копирвоании по фтп на клауд (туда поступает без закарючек), поэтому я и решаю ее, привожу к цельному виду (NFC) эти говняные буковки с закарючками раздельные (NFD) и в итоге все ок. А теперь проблема еще и в том что нельзя это нормально обновить в базе РБ ибо оно видишь ли видит это как одно и тоже.. ну да.. визуально то оно одинаково но по сути и по факту разные вещи. Проблемы не было бы если бы оно видело это как 2 разных пути уникальных и просто обновило чтоб было как на диске или добавило бы как новую запись где цельная отдельно, а старые бы потом можно было просто почистить через удаление несуществующих и все было бы красиво и прекрасно.
Сейчас вот пытаюсь соорудить какой-то скрипт, чтоб это все править.. не вручную же этим заниматься.. то что в там предлагали удалять потом добавлять.. нафига не понятно, когда РБ при обнволении базы мог бы просто увидеть что оно одинаково но в разном этом представлении и просто обновить чтоб было так как на диске и все..
 
Сейчас вот пытаюсь соорудить какой-то скрипт, чтоб это все править..
Короче сделал скрипт который исправляет, а вы себе собирайте дальше эти баги в коллекцию... там проблема еще и с поиском в итоге по базе когда на не идентично, если в базе раздельно, а ввести в поиск с цельным то находит фигу... ну да ладно.. Хорошо хоть с тегами не пришлось возиться, их хоть обновляет как положено в соответствии с тегами в файле при сбросе кеша, и на том спасибо..
 
Назад
Верх