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

Так на всяких андроидах нельзя просто взять и слушать изменения в фоне. Да и не на андроидах не очень надёжно, когда приложение не открыто.

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

Ну так прикинь хэшировать несколько гигов при запуске?)

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

Ну я так понял, ситуация такая:
Добавили песню в какой-то плейлист, потом файл переименован или перемещён, и надо не проебать его из этого плейлиста. То есть плеер должен знать, что та же самая песня теперь лежит в другом месте.

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

Верно. Путь сломается, id его для галочки и пользы не несёт.

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

Заведомо закладываются ломающие и неподконтрольные кейсы.

че то такое себе, а если у меня песни на флешке лежат, которая то есть то ее нету

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

Кстати тоже интересный кейс

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

@frostbit @centralhardware @Vorky Спасибо большое за помощь)

Почему бы не взять подход других плееров и не хранить у себя ничего лишнего, а лишь отображать пользователю актуальную информацию?

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

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

Имхо, всё ещё куда проще и для тебя, и для пользователей, завязаться на актуальные данные.

Был плейлист с песнями X, Y и Z.
Пользователь удалил/переместил/переименовал песню Y.

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

А то из-за изменения одной композиции бегать и обыскивать всё, так ещё и на хэшах, дюж жирно.

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

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

Довольно редкий кейс.
Куда чаще приложения реагируют на какие-то события и уже тогда действуют.

Вставил флешку?
Дай ка я проверю, а есть ли у тебя там фотки.

Либо мы пользуемся сильно разным софтом.