The reason was simply that it just took too long to calculate the md5 over
the entire file. So instead of doing MD5 over the entire file, it takes just
a few thousand Bytes from the beginning plus the length of the file.
If you feel a libgtkpod is needed, I would probably accept it -- just send
the patches. The lib should probably include
- md5 calculation on file
- all the definitions for ExtraTrackData, ExtraPlaylistData and
- reading and writing of offline file
- some other functions, I didn't think about carefully yet
As for the GTK dependency: libgpod will become dependent (optionally) on GDK
because of the pixbuf operations. It will be optional as long as you aren't
interested in thumbnails.
P.S.: I'll copy this to gtkpod-devel.
On Tue, Sep 27, 2005 at 08:35:43PM +0100, Nicholas Piper wrote:
> I decided to trick gtkpod into thinking the ext file was OK, as I
> didn't change any orders or IDs, just the genre fields.
> My first surprise is that the 'md5' is really sha1, and secondly that
> it isn't over the entire file; just the first PATH_MAX_MD5 *
> NR_PATH_MAX_BLOCKS bytes. That will make it hard for other tools to
> update the ext database. Maybe a libgtkpod is needed, so that other
> tools can share that algorithm? I may have to wrap some parts of
> gtkpod directly into a python module to do my tools if not; but then I
> might end up with a GTK dependancy.
> Nick Piper, Developer, LogicaCMG http://www.nickpiper.co.uk/
> GPG Encrypted mail welcome! 1024D/3ED8B27F
> Choose life. Be Vegan :-) Please reduce needless cruelty + suffering !
Get latest updates about Open Source Projects, Conferences and News.