В
Я делаю аудиоплеер и задался вопросом, как узнать, что файлы остались теми же, ибо ни название, ни путь смысла в этом плане не несут. Решил создать в модели песни поле хэша и хранить его там и по нему опознавать их.
Size: a a a
2021 May 09
ch
тогда не майтесь фигней, а берите готовые либы
VP
А дата изменения? Считать хэш всего - это немного долго.
В
А есть такие?) Просто везде в примерах MessageDigest.
ch
наврятли песни будут больше десятка мегабайт
VP
Отличный повод запихивать их целиком в RAM, да?
В
Так если поменять теги, то и дата больше неактуальна) Про длительность вычисления хэша в курсе, поэтому сделаю этот процесс в фоновом режиме.
VP
Так она обновится же 🤷♂️
И сразу будет понятно, что файл поменялся
И сразу будет понятно, что файл поменялся
VP
Это может работать через жопу с системами контроля версий, поэтому например Gradle считает хэши, но в фонотеке немного другой расклад
В
Черт, кажется я что-то упустил. Хэш ведь тоже поменяется, если залезть в теги песни и что-то поменять?
VP
Ну ясен пень, в этом вся его суть
ch
а где вы теги храните?
В
Блин, придется другой велосипед придумать (
VP
Можно считать хэш от аудиопотока, пропуская теги.
Но смысл всего этого пока не очень понятен
Но смысл всего этого пока не очень понятен
В
Вы про названия, исполнителя и т.д.? Тоже в бд
В
Хочу реализовать все так, чтобы перемещения треков вручную пользователями ничего не ломали в иерархии.
ch
а как что то должно сломаться?
В
Переименует пользователь файл и полетит к чертям вся фонотека с его путями и айдишниками автогенерированными)
ch
слушаешь фс на момент изменения папки, и если это произшло обновляешь индексы
ch
очень маловероятно что кто то будет двигать байты в обход ФС чтобы ваш плеер сломать