Print

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

[Mr ChriZ]

Is there anyway to export user defined fields?
(With the ability to reimport them)

[rjm]

I'm pretty sure user fields are exported in an MPL playlist along with all the other fields. The MPL can then be reimported.

[Jaguu]

RJM,

here you are wrong. Even if you export via MPL file, you cannot import user defined fields via MPL file. The fields have to be defined beforehand in the library, otherwise user defined fields will not be imported. In an MPL file you only have the information about the field name, but not any other information about other field attributes. The import does not know whether you are going to import a standard field or a list field.

I have found two workarounds. They work but are not very satisfying as a dump of all database fields which every SQL database incorporates.

1. Create a new library from your existing library by cloning the existing library in Library Manager, then clear the whole library content. You will have an empty library with all the existing fields.
Disadvantage: The library is not really empty, As information is only unlinked, but not deleted. The library files still contain all the deleted information. If you want to create a fresh, empty library for somebody else, this might not be a good solution.

2. Create a new library from scratch with all the needed user defined fields and view schemes and name it ie. "MyDefault Lib" and keep it empty. Whenever you need to create a new library of the same type, proceed as above, but clone the new library from the empty, personal default library. Then you really have a fresh new empty library.
Disadvantage: Whenever you make field or view scheme (and probably also playlists) changes in your main library, you have to make the same changes in your personal default library, Can become  very annoying as times goes on, as you always have to keep track of changes.

MC12 fundamentally lacks a tool to dump the data base design (including field definitions*, view schemes, playlists etc.) to a file (could be an xml file), so that this file can be used to create a new database with another name. Such a tool is included in all mayor SQL databases.
This this is a long standing feature request for the future.

*) this includes also the standard fields and standard view schemes as some attributes like the display name can also be modified.


 

[Mr ChriZ]

Cheers for the replys.
Unfortunately I can't clone my existing database, as I believe it is corrupt,
as I have major duplicate problems 

[rjm]

RJM,

here you are wrong. Even if you export via MPL file, you cannot import user defined fields via MPL file. The fields have to be defined beforehand in the library, otherwise user defined fields will not be imported. In an MPL file you only have the information about the field name, but not any other information about other field attributes. The import does not know whether you are going to import a standard field or a list field.

I have found two workarounds. They work but are not very satisfying as a dump of all database fields which every SQL database incorporates.

1. Create a new library from your existing library by cloning the existing library in Library Manager, then clear the whole library content. You will have an empty library with all the existing fields.
Disadvantage: The library is not really empty, As information is only unlinked, but not deleted. The library files still contain all the deleted information. If you want to create a fresh, empty library for somebody else, this might not be a good solution.

2. Create a new library from scratch with all the needed user defined fields and view schemes and name it ie. "MyDefault Lib" and keep it empty. Whenever you need to create a new library of the same type, proceed as above, but clone the new library from the empty, personal default library. Then you really have a fresh new empty library.
Disadvantage: Whenever you make field or view scheme (and probably also playlists) changes in your main library, you have to make the same changes in your personal default library, Can become  very annoying as times goes on, as you always have to keep track of changes.

MC12 fundamentally lacks a tool to dump the data base design (including field definitions*, view schemes, playlists etc.) to a file (could be an xml file), so that this file can be used to create a new database with another name. Such a tool is included in all mayor SQL databases.
This this is a long standing feature request for the future.

*) this includes also the standard fields and standard view schemes as some attributes like the display name can also be modified.

Thank you for correcting me and for providing more illumination.

On a related topic...  Last night I tried the "File\Library\Export to XML" feature for the first time to see if my library data might be made available for manipulation by another app. It pegged one of my cores at 100% and I let it run for a couple hours before giving up and forceably terminating MC.

I have a big library. Should I have let it run longer or is there a possible problem with this feature?

[Matt]

Thank you for correcting me and for providing more illumination.

On a related topic...  Last night I tried the "File\Library\Export to XML" feature for the first time to see if my library data might be made available for manipulation by another app. It pegged one of my cores at 100% and I let it run for a couple hours before giving up and forceably terminating MC.

I have a big library. Should I have let it run longer or is there a possible problem with this feature?

How big is your library?  The XML is created in memory, which will only scale to a certain point after which it'll page like crazy.

Ideally we should switch to writing a record at a time, and also add a progress wait message.

[rjm]

How big is your library?  The XML is created in memory, which will only scale to a certain point after which it'll page like crazy.

Ideally we should switch to writing a record at a time, and also add a progress wait message.

130,000 items and size of my JMD files is about 83MB.

While it was grinding I observed MC's memory usage to hover stabily around 400MB. I have 2GB in my system.

[Alex B]

How big is your library?  The XML is created in memory, which will only scale to a certain point after which it'll page like crazy.

Ideally we should switch to writing a record at a time, and also add a progress wait message.

Please do something. It really doesn't work properly as it is now.

MC11.1
- a playlist of 56859 files, MPL export: 59 seconds, file size 68 MB

MC12 (using a restored copy of the same MC11.1 library)
- a playlist of the same 56859 files, MPL export: N/A (I killed MC after 45 minutes)
- a playlist of 4102 files, MPL export: 28 seconds, file size 5.3 MB


MPL import using the file menu tool seems to work without problems. Importing the big MPL file I created with MC11.1 to an empty MC12 library took about 10 minutes. This is a lot faster than importing 56859 disk files. (MC didn't need to read the disk files.)

EDIT

I also tried this:

MC11.1
- a playlist of 4102 files (the same as above), MPL export: about 4 seconds, file size 5.3 MB

[hit_ny]

Interesting observations there Alex

Importing defnitely got a speed boost with v12.

The bulk XML or rather MPL exporting in v12 might need some tightening up if as you say it worked fine in v11.1.

[Matt]

The XML writer is (re)allocating memory more than it needs to, causing big slowdowns.  We'll tighten this up next build.

Thanks for letting us know.

[eba]

Is there anyway to export user defined fields?
(With the ability to reimport them)

Have you tried File->Library->Clear Library?
Think it completely clears your library (including previously deleted files) so should get rid of any corruption, but gives you the option to keep database fields.