Patch for CDDB lookup problems (EasyTAG 2.1.6)

Hi to all,

Here is attached a patch to fix the problem with the manual cddb lookup, 
before the next version.
The server gnudb.org doesn't to use anymore the cddb service, but only a 
http service... This was the cause of the problem.

I'm working on a 2.1.7 version to include patches of severals people 

Regards,
Jérôme

--

-- 
EasyTAG - Tag editor for MP3 and Ogg Vorbis files
http://easytag.sourceforge.net
--
Jerome COUDERC <easytag <at> gmail.com>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Easytag-mailing mailing list
Easytag-mailing <at> lists.sourceforge.net

Patch for CDDB lookup problems (EasyTAG 2.1.6)

Hi to all,

Here is attached a patch to fix the problem with the manual cddb lookup,
before the next version.
The server gnudb.org doesn't to use anymore the cddb service, but only a
http service... This was the cause of the problem.

I'm working on a 2.1.7 version to include patches of severals people 

Regards,
Jérôme

--

-- 
EasyTAG - Tag editor for MP3 and Ogg Vorbis files
http://easytag.sourceforge.net
--
Jerome COUDERC <easytag <at> gmail.com>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Easytag-mailing mailing list
Easytag-mailing <at> lists.sourceforge.net

Re: Easytag Major Performance Fix

On Sat, Jun 13, 2009 at 01:29:06AM -0700, Kip Warner wrote:

> Greetings,

Hi Kip,

> I've patched src/base64.c. There was a major problem when it was being
> called to decode very large buffers in orders of magnitude of a megabyte
> or more (e.g. cover art in a FLAC / Vorbis / etc. tag is frequently this
> size for some people). The base64_decode() routine had a cubic running
> time, since every time the decode pointer shifted forward in the stream,
> token_decode() would recompute the buffer length every time. e.g. If the
> buffer length was n originally...
>...

Instead of patching it, what about nuking src/base64.c completely in 
favor of the g_base64_{de,en}code() that were added in glib 2.12?

Would you test the performance if I'd send you a patch?

cu
Adrian

--

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Easytag Major Performance Fix

On Wed, 2009-08-26 at 08:37 +0300, Adrian Bunk wrote:
> 
> Instead of patching it, what about nuking src/base64.c completely in 
> favor of the g_base64_{de,en}code() that were added in glib 2.12?
> 
> Would you test the performance if I'd send you a patch?
> 
> cu
> Adrian

Hey Adrian,

It sounds like a good idea, but it might not be the best thing right
now. Glib 2.12 was when those routines were added and right now
libglib-dev virtual package has libglib1.2-dev still as it's dependency
(at least for GNU users running Jaunty as far as I know). So I'm
thinking 2.x branch may not be considered stable yet. I'm also not sure
how available it will be on non-free platforms. It's probably there,
just one more thing to add complications to at build time. My patch
doesn't require us to change or add dependencies fortunately.

--

-- 
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 

Re: Easytag Major Performance Fix

On Wed, Aug 26, 2009 at 11:38:36AM -0700, Kip Warner wrote:
> On Wed, 2009-08-26 at 08:37 +0300, Adrian Bunk wrote:
> > 
> > Instead of patching it, what about nuking src/base64.c completely in 
> > favor of the g_base64_{de,en}code() that were added in glib 2.12?
> > 
> > Would you test the performance if I'd send you a patch?
> > 
> > cu
> > Adrian
> 
> Hey Adrian,

Hi Kip,

> It sounds like a good idea, but it might not be the best thing right
> now. Glib 2.12 was when those routines were added and right now
> libglib-dev virtual package has libglib1.2-dev still as it's dependency

libglib2.0-dev is what you are looking for.

> (at least for GNU users running Jaunty as far as I know). So I'm
> thinking 2.x branch may not be considered stable yet.

2.x is stable since 2002.

> I'm also not sure
> how available it will be on non-free platforms. It's probably there,
> just one more thing to add complications to at build time. My patch
> doesn't require us to change or add dependencies fortunately.

Re: Easytag Major Performance Fix

On Wed, 2009-08-26 at 23:46 +0300, Adrian Bunk wrote:
> On Wed, Aug 26, 2009 at 11:38:36AM -0700, Kip Warner wrote:
> > On Wed, 2009-08-26 at 08:37 +0300, Adrian Bunk wrote:
> > > 
> > > Instead of patching it, what about nuking src/base64.c completely in 
> > > favor of the g_base64_{de,en}code() that were added in glib 2.12?
> > > 
> > > Would you test the performance if I'd send you a patch?
> > > 
> > > cu
> > > Adrian
> > 
> > Hey Adrian,
> 
> Hi Kip,
> 
> > It sounds like a good idea, but it might not be the best thing right
> > now. Glib 2.12 was when those routines were added and right now
> > libglib-dev virtual package has libglib1.2-dev still as it's dependency
> 
> libglib2.0-dev is what you are looking for.
> 
> > (at least for GNU users running Jaunty as far as I know). So I'm
> > thinking 2.x branch may not be considered stable yet.
> 
> 2.x is stable since 2002.
> 
> > I'm also not sure
> > how available it will be on non-free platforms. It's probably there,
> > just one more thing to add complications to at build time. My patch

[EasyTAG patch] use g_base64_{de,en}code()

On Wed, Aug 26, 2009 at 02:01:38PM -0700, Kip Warner wrote:
> 
> Hey Adrian,

Hi Kip,

> In that case, it sounds like a good idea if the performance is good.
> Although since it works extremely fast now, I'm not sure if there will
> be any benefit to swapping the code with another routine. Maybe
> experiment.

the main benefit is using well-tested code of a standard library instead 
of shipping own implementations.

Can you try the patch below instead?

cu
Adrian

BTW: This patch also fixes the bugs that memory allocated
     in g_base64_encode() with malloc() was freed with g_free().

 configure.in       |    4
 src/Makefile.am    |    2
 src/Makefile.mingw |    1
 src/base64.c       |  206 ---------------------------------------------
 src/base64.h       |   42 ---------
 src/cddb.c         |   59 ------------
 src/ogg_tag.c      |   14 +--
 7 files changed, 9 insertions(+), 319 deletions(-)

Re: [EasyTAG patch] use g_base64_{de,en}code()

On Fri, Aug 28, 2009 at 12:12:45AM +0300, Adrian Bunk wrote:
>...
> BTW: This patch also fixes the bugs that memory allocated
>      in g_base64_encode() with malloc() was freed with g_free().
>...      ^^^^^^^^^^^^^^^^^
            base64_encode()

cu
Adrian

--

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: [EasyTAG patch] use g_base64_{de,en}code()

On Fri, 2009-08-28 at 00:12 +0300, Adrian Bunk wrote:
> the main benefit is using well-tested code of a standard library
> instead 
> of shipping own implementations.

So far the code works fine and isn't complex enough in my mind to need
replacement. Moreover, it isn't really our own implementation but just
an improved version from Kerberos krb4-1.2.2.

> Can you try the patch below instead?
> 
> cu
> Adrian

I don't really have time right now since I don't have the music that
caused the problems anymore. If I get some more, and if I have time, I
can give your patch a try. You sent it inline though. I have asked the
project maintainer several times now with no response where the
repository is located, since an actual svn diff against head would be
the best way to do this.

--

-- 
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 

Re: Easytag Major Performance Fix

On Fri, 2009-08-28 at 13:06 +0200, Johnny Rosenberg wrote:
> Just curious: Since you use unicode characters in this email anyway (ϵ
> and Θ), why not use them unicode all the way?
> n(n(n + 1) / 2) = (n² (n + 1) / 2) = (n³ + n²) / 2 ϵ Θ(n³)
> 
> A lot easier to read…
> 
> Yes, OT, I know, sorry… just couldn't help myself…
> 
> 
> J.R.

Fair enough and good point ;)

--

-- 
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Easytag-mailing mailing list
Easytag-mailing <at> lists.sourceforge.net