No! Don't renumber my BookIDs!

[admin]

Originally Posted by admin

I'm looking for feedback on our renumbering the BookID.

Hummm.... some of you failed to read the above part of my post! Let's leave out the "knee-jerk" reactions and think positive. OK?

Digital Party... THANK YOU for your suggestion. That is what I am looking for; working together with us. If we simply start numbering the "new BookID" from the last one in your Songs Database, that looks like it IS the answer! I have just spent 5 hours coming to that conclusion.

However, we don't have a buy-off from MTU Programmers yet. It does look very promising though.

Some MP3+G and ZIP files already don't have Brand-DiscID-Track# identification. Currently, it is impossible to import these into Hoster 3.108. Hoster 3.109+ MUST allow batch importing INDIVIDUAL Files as KMA files indexed in the Songs Database.

While you have been posting, I have been thinking... because I was ALREADY AWARE reprinting Song Books is expensive.

When we cut over to "Song based BookID", we would do the following:

1. Remove the Import Screen BookID Root field and Next button. The new "Song based BookID" will be automatically assigned to prevent duplicates. Any older duplicate BookIDs that found will be renumbered using the next higher number. The BookID will PROBABLY no longer follow the current BookID ROOT+Track#.
   
   Here is a problem. The Import screen Status field shows IMPORTED when a file has already been imported. This CURRENTLY requires the DiscID, which is uniquely tied to the BookID ROOT. I doubt if we can continue to do this check and verify. There is a LOT of code and error checking behind this function. I'd hate to see it disappear.
   
   
2. Add a "Merge Songs into Database" command. Whenever you add existing KMA files (ex: imported on your backup system) into Folders identified in the Build Songs Database command, the Build Songs Database command will add them to the Database IF... they do not have the same BookID as one already there (determined by which was processed first). With Auto-Renumbering, your Song Book would be worthless following a rebuild of the Database. A Merge command would start with the EXISTING SONGS DATABASE (and thus Song Books), and add any new files into it, renumbering ONLY the NEW files that are currently NOT in your Song Book. The Unprinted tracks for next Song Book parameter will be reset to zero when the Merge command runs, and its count updated with each new merged song. The Print New Release Pages option in the Prepare Song Book dialog will then work as it does now. In case you can't see it, the "elegance" is starting to happen here!!!
   
   
3. Allow Edit Songs dialog Select Single tab to edit all fields, except BookID. Editing the BookID is not required with automatic renumbering. If scant song info is present when imported, you will WANT to edit these fields.

If song filenames only have Title and possibly Artist, duplicates will happen. When MP3G and ZIP filenames contain the DiscID and Track# fields within the filenames, Hoster 3.108 searches the Import and Song Databases. If the DiscID is found, it automatically fills in the Title and Artist fields before importing. We will add a new means into Hoster 3.109 (not in 3.108) to batch import MP3G and ZIP files. You can have FAST IMPORT, or CAREFUL IMPORT. The latter takes time and attention. We will try to create the new means to be unattended if desired. There is no other way to get 20,000 MP3G songs into KMA files and indexed in the Songs Database. At 1 second/song (which is the right ballpark for converting MP3 based files), 20,000 will take 5.55 hours. That's with the FAST IMPORT with unattended operation. If you are involved, it will take MUCH longer, but the songs will then be CAREFULLY IMPORTED. Our goal will be to provide the "tool" to allow both.

Now it's your turn... please evaluate and post your comments on these proposed changes.