Ipod slowness

[Daniel Winter]

On Mon, Jan 19, 2009 at 1:25 AM, Alejandro Wainzinger
<aikawarazuni at gmail.com> wrote:
> 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.

Well, take a look there:

Meta::TrackPtr
CollectionManager::trackForUrl( const KUrl &url )
{
    //TODO method stub
    //check all collections
    //might be a podcast, in that case we'll have additional meta information
    //might be a lastfm track, another stream
    //or a file which is not in any collection
    if( !url.isValid() )
    {
        return Meta::TrackPtr( 0 );
    }

    foreach( Amarok::TrackProvider *provider, d->trackProviders )
    {
        if( provider->possiblyContainsTrack( url ) )
        {
            Meta::TrackPtr track = provider->trackForUrl( url );
            if( track )
                return track;
        }
    }

    if( url.protocol() == "http" || url.protocol() == "mms" )
        return Meta::TrackPtr( new MetaStream::Track( url ) );

    if( url.protocol() == "file" && EngineController::canDecode( url ) )
        return Meta::TrackPtr( new MetaFile::Track( url ) );

    return Meta::TrackPtr( 0 );
}


If none of the trackproviders (collection and so)  returns a valid
TrackPtr  it uses MetaStream for http and mms

and MetaFile::Track for protocol file.

And the ipod-collection tracks have the file protocol in the
current.xspf for example:

file:///media/DANIELS%20IPO/iPod_Control/Music/F19/gtkpod281169.mp3

I suggest working around this by using a own protocol for the ipod
tracks (like amarokipodcollectiontrack://)   that way your trackForUrl
in your collection can easily catch them without asking the other
collections and most important without using Meta::File.

Those urls will not be playable so you need to return a different
playableUrl (see Meta::Track header for details).

With a little luck I didn't write anything stupid here (only writing
from my fading memory).

Oh, and take a look if the current.xspf uses the uidUrl (or what is is
called now) and not playableUrl for storing the Url.  That was a
little controversial a few months ago, so I am not sure which one is
getting saved now. In my point of view uidUrl is the correct choice.
That makes current.xspf useless for other players, but well it is
somewhere deep in .kde4/share/apps/bla..  anyway.

DanielW