[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[circle] what to publish
From: |
Thomas Voegtlin |
Subject: |
[circle] what to publish |
Date: |
Sun, 25 May 2003 09:19:44 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 |
Hi Thomas,
There are two points.
First, I looked at the code and I found that some of the entries
published in the hashtable are not necessary. In file_server.py,
there are two occurences of:
file.names.append(hash.hash_of(information[key]))
This means that the hashtable will publish an entry for the string
information[key]
Here are some example values taken by information[key] for a single mp3
file:
'MP3, 32 kBits, 32 kBits, 44.1 kHz3, 8 kBits, 22.05 kHz, JStereo'
'JStereo'
'8 kBits'
'audio/x-mp3'
'28681/Hz'
I do not see why we should build a hashtable entry for these search terms.
They are not likely to match a search (they are not even lowercase)
In addition, they contain '\x08' characters, so that the actual string
that is hashed is not 'audio/x-mp3' but 'audio/x-mp \x08 \x083'.
I think this puts an unnecessary load on the hashtable.
I think we shall remove these "names.append" instructions.
We should keep the magic information in file.info, so that a
query to the hashtable will still return this information (it will be in
the data)
Now the second point is the discrepancy between the information returned
by magic['circle'] and magic['linux']. (this was my point in the bug
report on
savannah)
As far as I can see, magic['circle'] does not work on my machine.
(see above, the first string is the 'generic' string, the 4 others are the
magic['circle'] strings, note the mismatch between 28681 and 22.05kHz)
I even obtain values like this: Frequency:1751443944/Hz.
which is not realistic. (and is not what is returned by mpg321)
It would be nice to fix that. If we could use the magic[circle]
information,
then we could do filtered searches, for example to display only mp3 files
that aree above a given sample rate. We cannot do that with the "generic"
information because it is not parsed.
(which I guess is the reason why magic['circle'] was introduced in the
first place)
Thomas
Thomas Mangin wrote:
Thomas.
Could you please describe the problem so I can help. I fixed another bug
recently. For the publishing, I understand the basic but my code could be
totally wrong as I just have the basic and no more. Circle should use only
one magic file (magic.circle) the other one was here for testing.
I hope it does make sense. feel free to contact me.
/Thomas