merging kma files

[admin]

Originally Posted by rmryanjr

The other point is that if I'm merging kam's how do I know which file it is. All the kma's are designated by disc Id (win xp file name) so there is no indication that the title or artist name embedded in the kma is too long. If you know what the char limit for title and artist name please let me know..I then can rebuild my DB and adjust those long names. I'll try using MS to open the files and check for any extremly long title/artist naming.

Merge KMA Files is totally automated. You specify the folders containing your KMA files and away it goes. Merge ONLY renumbers BookIDs that already exist in the Songs database. If a merging file's BookID is unique, if I am right, it is still renumbered to the next lowest available BookID in the Songs DB. It does not let you specify any numbers to omit, start at, etc... fully auto only.

Artist and Title fields are up to 63 chars each. To my knowledge, we auto-truncate longer ones. As Dale pointed out above, I don't think a too-long filename (at least in later Hoster versions) can cause any problems. There was a bug in the past.

Originally Posted by rmryanjr

I have been experimenting and have been succesfull in merging 12046 kma files I then created a songbook and looked at the bookid numbers assn'd the those kma's. I was surprised to see that the number scheme used a root id of "1" (101 bookid) then the next number used was "2" (201 bookid) for the second kma file resulting in the last number used 9999901. Based on the way it numbered the kmas Im at the limit of 1 million files. The boobkid numbering should have use "1" as the root for the first one. example, 101,102,103,104,105, ect then 2001,202,203,204,205,206, and so on. It's dropping all the availible numbers between 101 and 199 before using 201.

You are going against the tide. The way we number is totally based on 7 years of user feedback. Everyone wanted us to retain "DiscID" grouping of tracks. Thus, a DiscID has a 1:1 mapping with a unique BookID.

In Hoster 4.00x, we're about to break that, allowing an SCDG DiscID imported tracks (1,000+) on the hard drive (not from a SCDG disc) to map to many BookIDs, each going up to 99 tracks per BookID.

Originally Posted by rmryanjr

This all being said I have updated every hardware driver and firmware for all my hardware and software on my lptp. along with all win xphome updates and drivers ..even found an update to the "ntdll.dll" error i'm getting b4 Hoster shuts down. I don't experience any other problems with any other MTU product or any other process in hoster. Just this one thing.

If your windows ntdll.dll was not updated, WINDOWS, not Hoster, crashed Hoster. Sorry, but we are at Microsoft's mercy on this one.

[rmryanjr]

Originally Posted by admin

Merge KMA Files is totally automated. You specify the folders containing your KMA files and away it goes. Merge ONLY renumbers BookIDs that already exist in the Songs database. If a merging file's BookID is unique, if I am right, it is still renumbered to the next lowest available BookID in the Songs DB. It does not let you specify any numbers to omit, start at, etc... fully auto only.

Artist and Title fields are up to 63 chars each. To my knowledge, we auto-truncate longer ones. As Dale pointed out above, I don't think a too-long filename (at least in later Hoster versions) can cause any problems. There was a bug in the past.


You are going against the tide. The way we number is totally based on 7 years of user feedback. Everyone wanted us to retain "DiscID" grouping of tracks. Thus, a DiscID has a 1:1 mapping with a unique BookID.

In Hoster 4.00x, we're about to break that, allowing an SCDG DiscID imported tracks (1,000+) on the hard drive (not from a SCDG disc) to map to many BookIDs, each going up to 99 tracks per BookID.


If your windows ntdll.dll was not updated, WINDOWS, not Hoster, crashed Hoster. Sorry, but we are at Microsoft's mercy on this one.

First about the last ....the ntdll.dll has bee updated (replaced ) before my last post. As far as the numbering systemI havn't used any custome numbering at all. As far as my assumtiom for the bookids is based on what I found after clearing the song db file and starting at "0" . My goal was to renumber my bookids. I wanted this due to the fact that if I rebuild my song db I get a file telling me there are 7k duplicate bookids. This is why i wanted to use the merge and renumber. Again the merge has worked randomly and if there were errors it would create an error file, great i can live with that. The problem is that it won't complete a merge. I checkd all file names and there were no long file names. Besides the kma has only a disc id+track as a file name.

Is there a work around for the lack of reliability in the merge process? I'm sure that during the testing process someone either had no problems or had a problem and figured a way to fix it.

Im just looking for some help here.

I take it that I'll have to wait for the next gen 4.00 upgrade. My question is will it work then? It's availible in 3.319 it should also work in 3.319.

I've done all I can do. I don't experience any problems with any other programs.

Bob