I’m still very much a mAirList user and have recently started experimenting with mAirListDB. Something I can’t quite get my head around, though, is this - once you have loaded your tracks into the database, is there a way to manually ‘force’ mAirListDB to locate & read the MMD files for songs, and then save the data from those onto the database? I say this as I have item colours etc in MMD files and would like to carry them over without having to manually color each & every one again.
When there are MMD files present, the mAirListDB will read and use them while importing the files into the database. Internally, the exact same file import routines are used when importing files into mAirListDB and importing files into the main playlist, respectively. To check if mAirList locates and reads your MMD files correctly, try to load some files into the playlist first. If everything is ok, you can start the database import.
Once a file is imported into mAirListDB, you can safely delete the MMD file. It will never be used again, because all metadata is now managed through the database. In particular, if you make any changes to the MMD file later, these changes will never be visible. The only way to reload the MMD data for an existing item in the database is deleting the item from the database, and re-importing it.
Everything Torben says is correct, BUT as I am Very Paranoid, I do keep all my MMD files as a backup. That way, if I ever need to recreate my database, any customisation is retained when I Synchronise the audio files next time.
If you want to do this, then you do need to remember that if you change (for example) an item’s icon or colour in the Database, you also need to manually Save Metadata (MMD file) as well, to keep the corresponding MMD file up to date.
If you prefer, you can move the MMD files to a safe backup after initially importing the files, and likewise move any ‘new’ MMD files you create as a result of manual Save Metadata actions to that same safe backup location, overwriting the previous (original) MMD files.
It’s not a bad idea to keep the original MMD files as a backup somewhere - I just wanted to point out that they become irrelevant once the files have been imported into the database.
True. And removing the MMDs will immediately halve the size of the folder directories, and thus will improve performance.
… except, as I said above, if you make any subsequent changes to a database item, it’s worth writing a new corresponding MMD, then moving that new MMD to your ‘backup’ MMD storage to replace the previous version (for the reasons stated above: as an accurate backup!).
So, my workflow (which I recommend) is:
Correct/edit the MP3 tag contents to reflect your station’s standards.
Use mAirListTag to add cue points, Type, etc. and save as an MMD file.
Import (Synchronise Storage) each top-level folder into mAirListDB.
Move the MMDs to an archive location and take a backup copy of them.
If any changes are made later to a database item, save it as an MMD again,
and move the resulting MMD(s) to your archive location.
–
BFN
CAD
I may be wrong, but you don’t seem to have grasped what’s going on with mAirListDB and MMDs.
Let’s assume you have ONLY the MMDs and no database. When you create a database and then Synchronise the Storage (folders containing the MMDs), the database copies ALL information in the MMDs, including any colours etc.that you added to the MMDs.
After that time, if you change anything in the MMDs, those changes will NEVER be copied into the database: UNLESS you completely delete all the files affected from the database, then Synchronise the Storage again. This will naturally import the updated versions of the MMDs. It’s a pain, but I’ve done this myself from time to time during testing.
The transfer from MMD to database is kind of ‘one-way.’ It’s not expected that, after adding files to the database, you would then want to create/update MMDs, but: it IS possible. You need to have a ‘Save Metadata’ button in your PFL Player, then as you manually make changes in the database, you ALSO click the Save Metadata button in the PFL Player on the Properties page of the database item. I confess that I do this myself!
I had not at any point planned to write a script to create/replace MMDs from the database info.: sorry! Right now, my main concern is completing the English manual. I would think that finding someone who’s good with PostGRE SQL would be a better bet: they can write queries to extract the data direct from the DB and then write a program to take the results and write them to MMD files.
Like you, I think it is worth keeping the MMD files after they have been read into the database but realise that any changes made in the database would not be reflected in the source MMD file hence I thought (wrongly) that you were suggesting refreshing the MMDs by bulk ‘exporting’ the contents of the database to the MMD files - I now realise that you mean updating both the database and MMD file individually when a change is made.
Sorry for the confusion – I have obviously got the wrong end of the stick.
HI all,
Thanks for your replies and sorry I haven’t been able to reply before now.
I’m in a situation where my MMD files are actually more up-to-date than the data in the database so I wanted to know if there was a way to ‘re scan’ the MMD files for all the tracks in the database and read the data from these, import them into the database and then use the database from there on in.
Failing this can somebody suggest the scripting alternative for SaveMMD to save to the database and I will adjust my script accordingly?
The easiest way would be to remove the files from the database, and re-import them through the Synchronize dialog. Given that you can easily identify the items in the database, of course.
Generally, it makes no sense to change the MMD files after importing the files into the database, because mAirList will never look at the MMD files again for files listed in the database. I mean, that’s what the database is meant for - storing all metadata in a central location, not needing to look at any particular MMD files or file tags anymore.
