I've never found a way to really dig into how it is all handled internally
Playing with the COM Automation interface really shows you pretty clearly how it is organized under the hood.
The COM Automation interface is, of course, abstracted somewhat from how it really is implemented under the covers. You're accessing much more limited interfaces for the underlying "objects" in the application, and only a small subset of what they have access to with privileged "internal" code.
That said, an Interface object (like these) in C++ based programming almost always means that the "real" object itself they use internally (or a parent of it) implements all of the same methods and properties. It just may have many, many more items to access (and have better "abilities" within those methods and properties, like things that are read-only may be read-write internally). That's not always true, and they could have reorganized things internally and kept the COM Automation Interface unchanged, of course, but it probably
was like that at least at one point.
Still, though, it gives you the general idea. The "Playlist" object (for regular Playlists, not Smartlists) is basically a list, with some additional methods (actions/commands) and properties hung off of it: Name, Path (in the Tree), Type, etc. One of the Playlist object's properties is the list itself, and if you access that property, it "contains" a set of items. Those items are "File" objects, each of which have their own properties and methods.
When you view a set of tracks anywhere in MC (whether a Playlist, a View, or Playing Now), it is showing you a list of those File Objects, and the columns in the View correspond to the properties of the files.* The File Objects themselves (the entries for your imported files in the database, each with a particular ID number) are what matters. If you move the files around outside of MC, those File Objects still exist. The problem is that their .Filename property no longer points to a real file on disk, and if it tries to open the file, the OS says "not found".
So, you can still use that File Object, and it is retained in any Playlist object that references it, but before it'd be able to do anything that uses it in any way that touches the file itself on disk (playing, tagging, etc), you'd have to fix the .Filename property to point back to the file on disk again.
If you have
Fix Broken Links enabled in Auto-Import, then MC will detect File Objects with broken .Filename links, and it will try to fix them instead of importing them as new files. If you moved them to somewhere new on the file system, but generally kept the folder containing the files themselves the same (it tends to look for whole directories that match), then it'll probably be able to "fix" it automatically and instead of re-importing them, it'll "reconnect" them by updating the File objects with new .Filename properties.
But, if Auto-Import runs but can't "see" the new files because they're outside of the currently added Watched Folders set or they've changed in such a way that MC isn't
sure they're the same files, then Fix Broken Links
removes the broken File Objects from the Library (it moves the File Objects to the Removed Items database, and takes them out of the "Main" database). This deletes them from the Playlist object because they no longer exist. The Playlist object is a list of those "file objects".
But, if you have Fix Broken Links disabled, then it does nothing. If they moved to a folder that is watched, it might
re-import the files as new separate File Objects (with new ID numbers) but it won't delete the original ones. The new File Objects won't be in the Playlists but they'll work. The old ones will be in your Playlists still, they'll just all be broken.
That's simplifying quite a bit, but that's the general idea.
* I don't know for sure, but I'd bet this is literally what is happening: to open a view, you attach a generic list object to the "list" property of a View Controller object (or something of that sort), and then the View Controller object does what it is going to do to show this list of file objects (which it knows how to handle) onscreen. All "views" of files in MC are these list objects, whether they come from a search or Playing Now, or a View, or whatever. Playlists are just a special kind of List that are saved in the database and can be manually managed. Smartlists are a different kind where the GetList() command returns a list of objects that match a search. Views are a fancier version of Smartlists, and they're attached to much fancier View Controllers. But, at the bottom of it all, it is a bunch of different kinds of lists of a huge pile of file objects.
Author
Topic: Prevent Loss Of Playlist Links After File Update (Read 1245 times)