randomnicode
commented
2 years ago Hi @Dikakus this issue is the effect of a deliberate design decision we made for relative paths. You can read some of the commentary and discussion in the PR (#659).
Let's first try examining what the system is doing, then expanding on why this restriction exists, and eliciting feedback for what ought to be done.
- The fundamental guiding principle is that we do not want a scenario where a particular file on disk is referred to in multiple ways in the DB.
- Media files are identified by their [folder, relative path] combo. This is unique. Two media files cannot have the same folder id and path combination. That would imply they both point to the same file.
- As such all these combinations are wrong:
- two media files that are [F1, P1] and [F1, P1] cannot both exist (same file)
- two media files that are [F1, P1] and [F2, P1] cannot both exist if F1 and F2 are the same (two folders cannot have the same path)
- two media files that are [F1, P1] and [F2, P2] cannot both exist if F1/P1 = F2/P2 (example: F1=/Music, P1=Podcast/Pod, F2=/Music/Podcast, P2=Pod)
To mitigate the above scenarios, the following restrictions are placed:
- You cannot add a folder that has the exact same path as any other existing folder
- this would create a scenario where [folder 1, path 1] and [folder 2, path 1] point to the same file because folder1 and folder 2 have the same path.
- You may ADD a NEW Folder
- When you add a new folder that has no existing ancestor or descendants, it just creates a new folder. Any files under it won't exist in the system.
- When you add a new folder that is a child of an existing folder, all the paths in the parent that now fall under the new folder are modified to point to the new child folder.
- When you add a new folder that is a parent of an existing folder, it just creates a new folder. The existing child and the files under it stay as part of the existing hierarchy. New files outside the child but still part of the new parent will be added at next scan.
- When you REMOVE a folder
- If the folder has ancestors, the deleted folder tree first reassigns all its children to the surviving parent. Then deletes itself
- If the folder has descendants, nothing happens, it just deletes itself.
- When you update a folder, you just update the file path
- This inherently poses a problem if the file path is within the hierarchy of an existing folder. We don't know how to handle clashes (how to merge) between the paths in the two folders that may point to the same thing. We'll see how it is a problem in the example below. Thus for now it's restricted and not allowed.
As an example, let's take a scenario where the following hierarchy exists: /Music /Music/1.mp3 /Music/vi /Music/vi/Pod /Music/vi/Pod/P1 /Music/vi/Pod/P2 /Music/vi2 /Music/vi2/Pod2 /Music/vi2/Pod2/P3
And 2 folders exist in the system F1: /Music F2: /Music/vi/Pod
After a scan, these media files will exist: [F1, ''] <-- F1 root [F1, 1.mp3] [F1, vi] [F1, vi2] [F1, vi2/Pod2] [F1, vi2/Pod2/P3] [F2, ''] <--F2 root [F2, P1] [F2, P2]
Lets say we want to move /Music/vi/Pod to /Music/Pod We move over the folder on disk, after the scan the following media files exist in the DB [F1, ''] <-- F1 root [F1, 1.mp3] [F1, Pod] <-- New add [F1, Pod/P1] <-- New add [F1, Pod/P2] <--New add [F1, vi] [F1, vi2] [F1, vi2/Pod2] [F1, vi2/Pod2/P3] [F2, ''] <--F2 root [F2, P1] <-- X (doesn't exist) [F2, P2] <-- X (doesn't exist)
Now we edit F2 to point to /Music/Pod.
If we just edit and change the folder path, the issue is that multiple media files now point to the same file on disc: [F2, P1] points to /Music/Pod/P1 [F1, Pod/P1] also points to /Music/Pod/P1 Same for P2
This is bad, the same file can be referenced in the DB in multiple ways which is something we're trying to avoid.
So let's try and merge two, like we would if we added a new folder. Let's assign all the stuff that is under the F1 that might now belong to F2 to F2. [F1, Pod/P1] -> [F2, P1] This is an issue because [F2, P1] already exists. There is a uniqueness constraint.
The reason this works with adding new folder is because a new folder does not have existing files in the DB and therefore can be assigned files from the parent without any conflicts.
The fundamental difference between removing and adding a new folder, and just modifying an existing folder is that the former creates new files/new entries, whereas the latter carries over the existing entries and thus has potential for conflicts when merging files from the parent. Therefore we need to restrict the latter in terms of what you can edit it to.
None of this solves your problem. The point is feedback. What do you should we should do? A solution is to allow adding new PODCAST folders, but only have one active. When you add a new PODCAST folder, you would lose the statistics for the files under the old PODCAST folder
Dikakus
Problem description
I want to change podcast folder from configuration menu, but I can't and log throws an exeception.
Steps to reproduce
NOTE: Podcast folder exits in the path:
System information