Hardlinks might be a solution to this problmem as well. If we create a collection of storage directories that link to the specific harddisks then we should be able to harlink each of the repository files into the sore. It will not work with nfs systems of course.So this is not a good solution
This was an interesting problem. If we choose a specific byte as a unique song identification, then we can at least have them grouped according to the unique byte (255 groups). If we then need another byte, we might need to go through that groups collection to find a new nonmatching byte. This basically means that we will be sorting the songs according to some numerical value. A sort however is not good enough to have a unique identification.
There seems to be a solution emerging: the inode of a song ??? Or could we in some way attach extra information to the mp3 ???
I've been thinking about this and it seems like we need to have a full index handy. Whenever a song blockcheck is performed we need to get this extra information from other songs as well. E.g: assume we use position 50 as a number which specifies a unique key. As soon as a new song is inserted we need to extend that key with one more piece of data... and obtain that data for all songs !
This is a major problem, because the fixed positioning of songs is quite annoying. Simply moving them around outside pmdj should be possible. We still uyse the index, but when we rescan for songs we can better do the entire harddisk from within a certain directory. Recognizing songs can then be done based on their md5sum, or any other descent metric.