Ipod slowness

[Maximilian Kossick]

On Mon, Jan 19, 2009 at 4:10 AM, Daniel Winter <dw at danielwinter.de> wrote:
> 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).

That would solve the problem. possiblyContainsTrack and trackForUrl of
the IpodCollection should ideally work with the File:// urls too. That
way Amarok does the right thing if a user adds a file on the ipod into
the playlist for some reason. Comparing the file url with the ipod's
mountpoint in trackForUrl should be enough.

> 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