Sure, why not... so my pet project is basically for managing my audio files. There already is navidrome[1] and audiobookshelf[2]. They work great so far, but some minor details are kind of annoying...
The first milestone will be providing a basic API for my files - the main components of this will be the database (postgres), the API (C# + swashbuckle + JsonApiDotNet + Websockets) and the file indexer (C# HostedService). All parts except the file indexer are pretty much done, but it is a critical component, because it has to be as fast and correct as possible.
There are multiple approaches to index files... A best case scenario would be an "import" / "move" of files into a library or repository. That way you would be always up to date and always perfectly sorted. Unfortunately, an import would also be a big amount of work, because analysing the files and getting metadata from online sources is... lets say a huge project. And NOT getting metadata would mean, that I cannot move the files while another app manages the metadata. So I took another path - scanning an existing and well tagged library (that I manage with beets[3] for music and m4b-tool[4] / tone[5] for audio books).
My current Idea is to have a file indexer that:
- can run on multiple sources
- runs one full index scan after starting the app
- registers a filesystem watcher for every file source and reacts to events
- To ensure, no filesource is blocking others, each source is processed by a fixed batch size and then move on the the next file source
- If sources are modified (added, changed, deleted), there is a decision, what to do with already running indexers and registered file watchers (added just go to the queue, changed and deleted cancel already running tasks only for this source)
- All files are hashed (content only) to ensure, a change of metadata or tags will not change the hash, and if a file is moved, it will recognize this and update instead of delete and insert
The database will contain Tag-Values for every possible value. E.g.
File.Location music/album/AC_DC/Back in Black/01 - Hells Bells.mp3
FileTag.Type Artist
Tag.Value AC/DC
That way I can add a fulltext index on the Tags.Value field containing a searchable value while maintaining the FileTag.Type for recommendations.
Let's say I search for `AC/DC`, it will provide an auto-complete for all FileTags.Type values, that show a match + a generic one for searching ALL values:
Artist: AC/DC
FullText: AC/DC
Searching for 2010 will show:
Released: 2010
Title: 2010
FullText: 2010
because it contains matches in Releasedate and title.
There may be a lot to optimize, but I think my current plan goes pretty well. Let me know what you think about this approach :-)
[1]: https://www.navidrome.org/
[2]: https://www.audiobookshelf.org/
[3]: https://beets.io/
[4]: https://github.com/sandreas/m4b-tool/
[5]: https://github.com/sandreas/tone/