![]() Possibility is that there are two identical songs in the libraryīefore the ID is created. ThisĬould be addressed by having QL flag duplicate IDs. Then there would be two files with the same ID in the library. Moreover a file copy could be made of a song after it got its ID and Some people may not like that in order to use QL playlists all The advantages of IDs over inodes is that they would still work with IDs - though the browser would also display file names. The chances of collision even with a collection ofġ00K songs would be extremely low. Library? The ID could be a random 12 digits hexadecimal number (not What about having a song ID stored as an ID3 tag in each song of the That proposed solution does not scale well. That seems a good solution if a small number of files has beenĬhanged, but I have for example renamed folders whose trees contain Issue 708 suggests a dialogue box to manually fix the path to a file. > The "Move Library" quick fix suggested in one of the recent Issues mightĪs you said, there is a number of issues related to lists and such. > use cases (whilst you have QL open, though). > - but I do think getting the file-watching sorted deals with a lot of the > I don't think inodes would help us much here for reasons you've pointed out > Note there are a fair few existing issues around this: > Weirdly I was just looking at this very problem On 13 December 2015 at 23:27, Nick B wrote: However to know how other list members deal with the issue of changes Software portable to different OSes (Linux, BSD, OSX, Windows) wouldĪnyway, I am not suggesting a new feature. But this would complicate implementation. Stay as backup for the inode and would require manual intervention toīe used. The inode reference and the file path and name, and the latter would One solution then would be for the playlist to store both But what if I backup my musicĬollection to a tar file and restore it? The inodes are lost, so the The file or folder or move the song to another folder and it wouldĬontinue to be in the playlist. This would seem like a solution – on Linux, at least. What if the playlist could store inode references instead of file names? One cannot – as far as I know – establish a tree of tags. There are ID3 tags, but I don't see them as flexible as file names andįile paths, because it is more difficult to change tags, and because One solution is to keep forever the songs in the same location and notĬhange file or folder names. Moving files around the folder tree, and renaming files and folders, ![]() The problem is that if either changes the QL playlists, as well as m3u and other types of playlists, store pathsĪnd file names of songs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |