PDA

View Full Version : iTunes patching



kdf
2004-05-03, 14:09
I'm testing the new iTunes patches, and making sure we merge all of the recent
changes, including the most recent to clear some warnings.

I'm finding that findMusicLibrary is being called more than necessary, so I'm
trying to optimise that out so we only call if we haven't found a library yet.
however, what I've noticed now is that there is a findMusicLibrary and
findMusicLibraryFile.

Lars, was this your intent? What is the requirement for having both?

-kdf

Lars Kellogg-Stedman
2004-05-04, 05:24
In article <1083618568.4096b508e37e6 (AT) callisto (DOT) deane-freeman.com>,
kdf <slim-mail (AT) deane-freeman (DOT) com>
wrote:

> I'm testing the new iTunes patches, and making sure we merge all of the
> recent
> changes, including the most recent to clear some warnings.
>
> I'm finding that findMusicLibrary is being called more than necessary, so I'm
> trying to optimise that out so we only call if we haven't found a library
> yet.
> however, what I've noticed now is that there is a findMusicLibrary and
> findMusicLibraryFile.
>
> Lars, was this your intent? What is the requirement for having both?

If itunes_autolocate is on, then findMusicLibrary() will look for an
'iTunes Music' directory in the same directory containing the 'iTunes
Music Library.xml' file and use this when correcting the file: URL's
from the xml file to local file: URLs. Prior to this change, Slimserver
would simply replace the iTunes library path with audiodir, which would
generally be incorrect for people who had simply pointed Slimserver at
their 'iTunes' directory.

findMusicLibraryFile() was already in 5.1.5, and uses some simple
heuristics to find the actual XML file.

Note that if itunes_library_xml_path and itunes_library_music_path are
both set and itunes_autolocate is set, both functions are essentially
no-ops.

I agree with you that findMusicLibraryFile() is being called too often;
I didn't try to correct this problem because I wasn't sure why it had
been designed this way to begin with (and I used it as a model for
writing the findMusicLibrary() routine).

Ideally, the find...() functions would only be called (a) at Slimserver
startup and (b) when the user makes a change to the configuration
effecting iTunes support.

-- Lars

kdf
2004-05-04, 09:19
Quoting Lars Kellogg-Stedman <lars (AT) oddbit (DOT) com>:

> In article <1083618568.4096b508e37e6 (AT) callisto (DOT) deane-freeman.com>,
> kdf <slim-mail (AT) deane-freeman (DOT) com>
> wrote:
>
> > I'm testing the new iTunes patches, and making sure we merge all of the
> > recent
> > changes, including the most recent to clear some warnings.
> >
> > I'm finding that findMusicLibrary is being called more than necessary, so
> I'm
> > trying to optimise that out so we only call if we haven't found a library
> > yet.
> > however, what I've noticed now is that there is a findMusicLibrary and
> > findMusicLibraryFile.
> >
> > Lars, was this your intent? What is the requirement for having both?
>
> If itunes_autolocate is on, then findMusicLibrary() will look for an
> 'iTunes Music' directory in the same directory containing the 'iTunes
> Music Library.xml' file and use this when correcting the file: URL's
> from the xml file to local file: URLs. Prior to this change, Slimserver
> would simply replace the iTunes library path with audiodir, which would
> generally be incorrect for people who had simply pointed Slimserver at
> their 'iTunes' directory.
>
Thanks. It took me a while to sort all that out as it is a large patch when
combined with what I'm working on.

> I agree with you that findMusicLibraryFile() is being called too often;
> I didn't try to correct this problem because I wasn't sure why it had
> been designed this way to begin with (and I used it as a model for
> writing the findMusicLibrary() routine).
>
> Ideally, the find...() functions would only be called (a) at Slimserver
> startup and (b) when the user makes a change to the configuration
> effecting iTunes support.

Right now, I have them store the result of the find, and only call again if the
path/file are once again undef. I have to add some code to undef on change
which I plan to do tonight.

I'm holding off on this patch because there are STILL issues with iTunes
playlists. They have nothing to do with the itunes module, but I dont want to
confuse things. an itunesplaylist: url currently seems to crash the server (at
least it does for me on windows AND linux). Sadly, I've not be able to make
much sense of all the URL code, so I'm stuck waiting for someone else to notice ;)

-kdf