extragear/multimedia/amarok/src/collection/sqlcollection

Myriam Schweingruber schweingruber at pharma-traduction.ch
Tue Jun 23 15:43:06 CEST 2009


Hi Seb and Jeff,

On Tue, Jun 23, 2009 at 02:23, Seb Ruiz<ruiz at kde.org> wrote:
> 2009/6/23 Jeff Mitchell <mitchell at kde.org>:
>> Seb Ruiz wrote:
>>> 2009/6/22 Jeff Mitchell <mitchell at kde.org>:
...
>> When you set images, either through downloading via Amazon or when you
>> set custom covers, the image is cached in the amarok user dir.  It's
>> done via a hash of the file/album/something; as a result, even if you
>> delete all items from the db and rescan, the covers are just fine.  (The
>> database in this sense ends up acting as a cache; if the database
>> doesn't have an entry, it could still be found via the hash if you
>> persisted in looking for it, which you probably won't if it's not in the
>> DB.)
>
> Okay, technically this is true as I added this functionality as a
> workaround to the problem which I mentioned. However, viewing the full
> size cover of an album which is set via "set custom cover" will fail
> as the full image path location doesn't exist in the database.
>
>> Interestingly, Amazon covers don't get inserted in the Amazon table but
>> are instead treated the same way.  I wonder what this means in terms of
>> the TOS/TOU.
>>
>> One thing that doesn't behave well (and this is not a result of the
>> change I made, which I actually ended up reverting later) is that when
>> you scan, the collection browser ends up losing the covers until you
>> next start Amarok or until ${foo} happens.  This might be helped by an
>> upcoming commit of mine, but as I don't know much about the collection
>> browser, I kind of doubt it.

Just a few remarks: there is a strange bug in the Amazone locale
settings, if I choose Germany I actually get stuff from Japan...this
was mentioned in a bug report some time ago which has disappeared from
the bugs list, but I still experience that, so my lists is an
alphabetical one, but it is obvious that the actual Amazon database
used is a different sorting. Could we get that fixed?

bug 197242 is the worst I experience till now, as I experience
repeating plasma crashes and end up in Kwin crashes after some time

Would it make sens to run a Valgrind check on that to locate an
eventual memory leak?


Regards, Myriam
-- 
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)


More information about the Amarok-devel mailing list