INTERACT FORUM
More => Old Versions => Media Center 15 (Development Ended) => Topic started by: skylarplane on November 03, 2010, 10:42:19 am
-
Why did this happen. ?
-
My guess is that you're going to need to be WAY more specific about what happened. What were you doing at the time? What have you tried to get them back? You know... details.
-
one way it happens is when you unimport and reimport files, for example because you moved files outside of MC and want to fix links.
If I remember correct, try to avoid it now, MC removes files from playlists when they are not in the database anymore. I don't like this behavior because this makes playlists vulnerable especially since they don't have copies in external files like the mp3s and other physical records. As I emphasized in the past, sometimes (i.e. for a DJ), playlists are more important then the files themselves.
-
As I emphasized in the past, sometimes (i.e. for a DJ), playlists are more important then the files themselves.
+1 for this
-
A library backup could be used to recover playlists.
-
A library backup could be used to recover playlists.
Yes, but as usual backup doesn't work with data You are working on. Undo playlist operation would be great feature for DJs
-
Or, in DJ mode (any mode really), the ability to lock (no write/no delete) a playlist with an option to also lock (within the library) the media files it links to.
Having a very clear visual indication of these locks (and very clear 'that has been locked by a deliberate user action' error messages) would go a long ways toward getting around the user problems caused by the 'I forgot that I locked that stuff' memory lapses that are sure to come.
-
Or, in DJ mode (any mode really), the ability to lock (no write/no delete) a playlist with an option to also lock (within the library) the media files it links to.
Having a very clear visual indication of these locks (and very clear 'that has been locked by a deliberate user action' error messages) would go a long ways toward getting around the user problems caused by the 'I forgot that I locked that stuff' memory lapses that are sure to come.
I agree, but also, I don't see any valid reason for MC to delete files from playlists automatically. We could just get a visual indication like in the case when the physical files are missing.
-
A library backup could be used to recover playlists.
Jim,
backup is certainly helpful but not sufficient really. You may delete a file from library, for example because you have a duplicate, forget to check that it was in some of the playlists (I always check that before deleting anything), and realize (or not) 6 months later that some of your playlists is missing salt. Part of the problem is that this all happen silently.
I export playlists, put them on SVN and compare but how many people would do all of that? I must also say that this is the main reason why my wife gave up on MC, because she was pissed for loosing playlist (she was moving files outside of MC, difficulty doing that in MC is a separate discussion).
-
I agree, but also, I don't see any valid reason for MC to delete files from playlists automatically. We could just get a visual indication like in the case when the physical files are missing.
I think the root of the problem from a programming perspective is that the playlists do not reference the media files themselves, but instead reference the File Objects in the database. This concept provides all sorts of benefits, obviously. MC is a database driven application founded on the concept of abstracting the media files away from their disk files and into a system of "objects" that can be manipulated in a variety of ways separately from the file system.
The problem is that if you "delete" a file in MC (remove it from the Library), it actually deletes that file's object in the database. So all references to it are removed, including those in the playlists.
Now, for many users, this isn't a serious problem. One of the major reasons I USE MC is that I NEVER want to actually manage my files manually on disk by hand. If I need to move files, I move them within MC. The metadata stored in MC's library is way too important to break by moving them elsewhere or manipulating them externally. If I do need to manipulate them externally, there are plenty of ways to do this without deleting the file object in MC. For example, if you replace some MP3 files on disk with FLAC versions, it is a simple matter to update the existing file objects in MC to match without deleting and re-importing the files (simply change the filename tag to point to the proper files and then do a Update Library from Tags). I wouldn't ever want to lose the play counts and date imported and all that relevant metadata that would be lost by simply re-importing them. So, doing it that way isn't something I'd ever even consider as an option, except in extreme circumstances.
However... If you are coming from a "WinAmp" perspective, where playlists are actual text files with a list of paths to files on disk, then I can see how you might not expect it to work this way! The problem is that for MC to work around this, it would have to never really delete anything from the database, because those file object references might exist in a playlist somewhere. At the very least it would need to check each file removal operation against all of the Playlists in the Library and then selectively remove some of them and keep others (and there could be hundreds or thousands of playlists to check and thousands of files to delete). And then there is the problem of display... If those objects were deleted from the "library" but still kept in the "database" because they were in some playlists, then MC would have to have some way to filter them out of all the "normal" file list views, but not the Playlists.
This would quickly become ungainly and unworkable. The database would be ballooning in size because of these "phantom" file objects, many of which you might not actually want anymore because they are sitting in an obscure playlist filed in a playlist group that you haven't considered or looked at in months or years. You'd be left with a situation where the database might need to track hundreds or thousands of these phantom file objects for no good reason.
I'm not suggesting that it isn't an issue for some use-cases, but it is a tough problem, not a simple "why can't it just keep listing them" type of solution. I've certainly run into similar problems in the past, and I've lost some very valuable playlists because of it (including one I really wish I still had). I have, however, developed some strategies to prevent it from ever happening again:
1. I never manage file locations for files on my "media drive" outside of MC. Period. Exclamation point. It just isn't an option. Like I mentioned above, there are tons of ways to manage things from within MC that won't break your file object links in the database, and frankly, MC's tools for file system management are much more powerful than anything Windows Explorer provides.
2. Every single file in my main media drive storage system is in the MC library and managed by the MC library. This includes PDFs, text Files, JPGs... Everything. Nothing is in those folders that MC doesn't know about and manage.
3. If I have a particularly valuable playlist, such as the manually-built list I used for my wedding music, I export that playlist to disk any time a change is made. I have a simple M:\Playlists\ folder on disk where I store these. I don't actually use them for anything real, except as a backstop. Exporting playlists to simple M3U files can be a lifesaver if you need to ever manually rebuild an essential and finely-crafted playlist by hand if something catastrophic happens that breaks rules 1 & 2.
-
I think the root of the problem from a programming perspective is that the playlists do not reference the media files themselves, but instead reference the File Objects in the database. This concept provides all sorts of benefits, obviously. MC is a database driven application founded on the concept of abstracting the media files away from their disk files and into a system of "objects" that can be manipulated in a variety of ways separately from the file system.
The problem is that if you "delete" a file in MC (remove it from the Library), it actually deletes that file's object in the database. So all references to it are removed, including those in the playlists.
One implementation solution could be to keep the removed files in a separate database (MC already seem to have multiple of those), until they are cleared from all playlists. (this can be done when changing the playlist or at regular cleanup intervals).