Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MusicHawk]

>> Also, will a library backup screw up my tags, files etc?  If it's like a XP "system restore," I might lose files etc.

I'd like to know this too. I also worry about all-or-nothing restore, so in recent years I have not restored an MC backup (even though I make them, just in case). I'm sure MC backup/restore is helpful in some situations, but I just don't seem to get into those situations. By the time I determine I need *something* from a MC backup, I've also done lots of later work that would (I believe) be lost. It doesn't appear to be granular-enough, unless I misunderstand what really happens.

MC is an amazing creation as-is, but I'm hoping it might move more toward a "classic" database application architecture. Here's a general 3-layer structure that could provide more granular control and backup/restore:

Application -- MC -- overall configuration, applicable to ALL databases and data (libraries) that might be used. Probably includes forms, view designs, record/play/display and other structural entities. Works with any/all MC databases without the application config altering them or vice versa.

Database -- MC library -- structure and configuration, separate for each library. Probably includes database customization, smartlists, etc. Maybe not views, which might be better considered part of app-level. Works with any/all MC data, though of course data might be altered by database structure.

Database content/records -- MC music/video/image/etc -- can be saved/restored separate from database and application config. Nothing in the database content controls the database design or MC's config.

There can be other application architectural layers and sublayers, such as display, networking, etc. But from a user perspective, these three main layers can provide lots of flexibility in configuration and control, including restoring views or playlists without messing with data, and vice versa. It could also allow easy use of design elements across libraries or across instances of MC.

I also hope configuration information can itself be stored in "open" format that can be easily backed-up, moved and manipulated -- classic text-type .ini or .xml files would be wonderful, with nothing important in Windows Registry.

For inspiration I like to explore how IBM Lotus Notes does everything I just said. After almost 20 years it's still a superior architecture because it doesn't rely on an OS (supports Windows, Mac, Linux, mainframe), or (much) specific file folder structure. It even runs directly from a USB stick without needing installation. And it has services and APIs for just about everything. (While more sophisticated than MC needs, Lotus Notes database replication is an astounding achievement.) In fact, almost 10 years ago a media library/jukebox application was written in Lotus Notes "just for fun", to prove it could be done. It's worth noting that Lotus Notes was invented and built by Ray Ozzie, who is now the #1 tech architect at Microsoft, replacing Bill Gates.

[StFeder]

3-Layer structure sounds great!! Here we go:

[...]Application -- MC -- overall configuration, applicable to ALL databases and data (libraries) that might be used. Probably includes forms, view designs, record/play/display and other structural entities. Works with any/all MC databases without the application config altering them or vice versa.[...]

This are especially most of the options set via "Tools -> Options". I think most (all?) of the options set up here are for all librarys.

[...]Database -- MC library -- structure and configuration, separate for each library. Probably includes database customization, smartlists, etc. Maybe not views, which might be better considered part of app-level. Works with any/all MC data, though of course data might be altered by database structure. [...]

This is what is backup and restored with library backups. You can setup a library using "File -> Library -> Library Manager". You will see: every library has its own play-/smartlists and customizations. All views are stored per library but you are able to access your saved views from every library, so that it is very easy to make different librarys with equal views as well as with different views.

[...]Database content/records -- MC music/video/image/etc -- can be saved/restored separate from database and application config. Nothing in the database content controls the database design or MC's config. [...]

I don't realy get the point here... The content (the audio/video/picture files) of a library doesn't control neither the database design nor MC config. You can use an external backup tool to backup and restore all the media content without changing settings in MC... Maybe with some clever folderstructures you are allowed to use MC as a "content"-backup tool... I have some of my media files on an external harddisk and it doesn't matter if it's plugged in or not, I can always browse through its content using MC (after I imported the contend of course). For this I changed "Tools -> Options - Library & Folders -> Auto-Import Folders -> Options -> Fix broken links" to "no". First time I used MC without having my external HD plugged, MC deletes all my library entries and I lost hours before I found the reason But now it works.

[...]I also hope configuration information can itself be stored in "open" format that can be easily backed-up, moved and manipulated -- classic text-type .ini or .xml files would be wonderful, with nothing important in Windows Registry. [...]

Some of the "overall options" are stored in registry. But there is a plugin at MCs Plugin download page which can save and restore them (I never tried this plugin). I'm not sure about the library itself. I think I red about an open database format a longer time ago in one of MCs changelogs... Maybe it was MC9 or MC10. Not sure about that. To do an easy backup: take a look at the folder the library is stored in (if you don't know, the library manager does ). There should be the whole library data. This is folder stored in the library backup zip-container created by MC.

[...]MC is an amazing creation as-is, but I'm hoping it might move more toward a "classic" database application architecture.[...]

Hm, maybe they already took this step

[JimH]

Musichawk,
Extensive changes to the architecture of MC are unlikely.  It's evolved to its current state for good reasons.  Large changes mean large bugs and a long period of bug swatting.

We're pretty proud of the way it is.

Jim

[hit_ny]

>> Also, will a library backup screw up my tags, files etc?  If it's like a XP "system restore," I might lose files etc.

I'd like to know this too. I also worry about all-or-nothing restore, so in recent years I have not restored an MC backup (even though I make them, just in case). I'm sure MC backup/restore is helpful in some situations, but I just don't seem to get into those situations. By the time I determine I need *something* from a MC backup, I've also done lots of later work that would (I believe) be lost. It doesn't appear to be granular-enough, unless I misunderstand what really happens.

That's a valid concern but i can't (as yet) see how a 3 layer structure would help with it.

The only way i found is to have a few sanity check smartlists (checking for empty fields that shouldn't be) and a runnning total of how many albums, files etc i expect to see in a few viewschemes. So if these are run at regular intervals then you have some idea that things are ok.

The most common cause of a library corruption is when MC is saving a copy of itself and for some reason crashes. At this point usually any recent tag changes will be missing. Now if all of them happen to be in PN, then its eaiser to spot what did not take. If it happens while on a mass tagging expedition then you will be s.o.l.

The only way to protect against this is to have several waypoints.

That way a restore will take you back in time but not too far. Any major tag updates *MUST* be followed by a File->Library->Back Up Library and preferably to a partition other than the one MC resides in. Keep a few months of those backups if need be.

it must be noted that any library restore will necessarily require a rebuild of thumbnails, whch depending on the size of your collection & CPU power,  may take several hours.

[MusicHawk]

Thanks for the comments.

>> The content (the audio/video/picture files)

I said "records" not "files" (which of course can be backed-up outside of MC), because I'm just hoping for a way to save a backup of the database records -- all that typing and info -- separate from the database design (views, playlists, etc). The reason is because one might need to be restored without affecting the other.

[StFeder]

Thanks for the comments.
>> The content (the audio/video/picture files)

I said "records" not "files" (which of course can be backed-up outside of MC), because I'm just hoping for a way to save a backup of the database records -- all that typing and info -- separate from the database design (views, playlists, etc). The reason is because one might need to be restored without affecting the other.

Oh, now I get what you mean. I'm sorry, sometimes my english knowledge is to bad...