The results I got today were not consistent with yesterday (ok iTunesDBs
would now be "not ok"). I learned a lot about the binary format, and
figured out that by messing with the ArtworkDB (for the performance
tests) the dbid_1 numbers were now out of whack. However, restoring the
whole iPod_Co
On Fri, Jun 12, 2009 at 09:51:18PM +0200, Richard van den Berg wrote:
> > To get some numbers on the performance you could do me a favor and add a
> > single file to the rather full ipod while profiling the perl process.
> >
>
> The results are at:
> With 11600 files http://richard.vdberg.org/
On Fri, Jun 12, 2009 at 04:33:43PM +0200, Richard van den Berg wrote:
> On Fri, June 12, 2009 15:21, Heinrich Langos wrote:
> > I'd like to have a chain like this: ok -> ok -> broken
>
> Here is such a chain:
>
> http://richard.vdberg.org/gnupod/ok/11181/iTunesDB
> http://richard.vdberg.org/gnup
3 matches
Mail list logo