Support for track migration inside library #1173
Comments
|
In theory, you could use some hashing algorithm to track the same song, even if you don't hash the metadata (so that can be updated separately) |
|
There is actually an oversight on my behalf when I implemented the file move/rename handling some seven years ago: In case a file is moved or renamed within the user's cloud using the intended mechanisms like the web UI or the PC sync, the host cloud fires It shouldn't be too difficult to change this so that we wouldn't recreate the library object on this case but just update the existing one. We then just need to handle separately the case where the song is moved off the configured music library path, because in that case, we actually need to handle the moving the same way as if the file was deleted. |
Our previous FileHooks implementation was such that moving a scanned audio file from on folder within the library to another folder within the library caused the track object matching the said file to be deleted and the recreated. Hence, the track got a new ID and it got removed from any playlists where it belonged to. Now we handle file moving separately and differently than a file deletion followed by file recreation, and the track gets updated "in place", without changing the ID or removing it from existing playlists. If, on the other hand, an entire folder full of scanned audio files gets moved, then we do one of two things: 1) In case there's 30 or less audio files contained, we handle each file separately the same way as if those 30 files were moved individually 2) In case there are more than 30 audio files contained, we remove them all from the library and the user needs to rescan the files. The second case is suboptimal but we can't handle any number of files one-by-one during the moving because that could slow down the moving operation too much. In the best case this would annoy the user and in the worst case it would cause a time-out and break the entire operation. This is a partial fix for #1173.
- If the user's library contains any files potentially needing rescanning, this is now prompted to the user upon app loading, similarly as any new files to scan - The rescanning of modified files, both with the new prompt and using `occ music:scan --rescan-modified`, can now also remove files from the library if the modified file turns out to be within an excluded folder - When moving folder within the music library, and that folder contains more than 15 audio files, those files are now marked as "dirty" to trigger the mechanism described above. Previously, up to 30 files were rescanned immediately and over 30 files were removed from the library, which was sub-optimal. - This completes the fix for #1173 which was started with the commit 9c43c9c. This also provides a partial fix for the old issue #706.
Let's say, I moved track1.mp3 from /Music to /Music/Favourites. Currently, if I do that, I would need to re-add this track to all playlists it was placed in. But maybe it's possible to implement feature: if after regular scan system found that track1.mp3 is no longer in its' place but there's file with same name in different subfolder, it edits path to this track in playlists. Probably there could be UI for user to allow/deny such migrations to prevent situations when track was actually replaced with same-named file.
The text was updated successfully, but these errors were encountered: