Ipod slowness

[Alejandro Wainzinger]

I'm checking the CollectionManager definition, but in all places where
possiblyCotainsTrack and trackForUrl are called, the default
implementations inherited from Meta::Collection should make it so that
tracks just aren't added to a list.  I don't see where it checks using
Meta::File.

On Sat, Jan 17, 2009 at 2:14 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Fri, Jan 16, 2009 at 7:30 PM, Alejandro Wainzinger
> <aikawarazuni at gmail.com> wrote:
>> So are these issues related then?  I'm not sure the Collection has
>> control over what the playlist does here, since no part of the
>> IpodCollection code is reading metadata directly from the file.
>
> I don't think it's related to the ampache problem. If I recall
> correctly services implement trackForUrl. The IpodCollection does not,
> however. It provides neither possiblyContainsTrack nor trackForUrl.
> Therefore CollectionManager falls back to simply reading the files
> from the Ipod using Meta::File
>
>> On Mon, Jan 12, 2009 at 11:28 PM,  <unnamedrambler at gmail.com> wrote:
>>> On 1/12/09, Mark Kretschmann <kretschmann at kde.org> wrote:
>>>> On Tue, Jan 13, 2009 at 4:08 AM, Seb Ruiz <ruiz at kde.org> wrote:
>>>>> Hey xevix,
>>>>> It seems that on Amarok startup, if there are any playlist tracks that
>>>>> are from the ipod, instead of reading the ipod db, the actual file
>>>>> metadata is read and is waaay slow. This is especially the case if you
>>>>> have a few thousand ipod tracks in the playlist. Could you please take
>>>>> a look at this?
>>>>
>>>> We have a similar issue with service tracks, e.g. from Ampache. For
>>>> each item in the playlist trackForUrl() is called, which can easily
>>>> make Amarok take several minutes to start with a big playlist.
>>>>
>>>> I don't know if these two issues are directly related. For the issue I
>>>> mentioned, someone (Casey I think) was working on a solution. A status
>>>> update on that would be nice.
>>>>
>>>
>>> Indeed. I did some work on making trackForUrl async, however it
>>> doesn't seem to work as intended. I will attempt to resolve this once
>>> and for all at campkde.
>>>
>>> Casey
>>> _______________________________________________
>>> Amarok-devel mailing list
>>> Amarok-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>