On 4 sep 2010, at 17:59, [email protected] wrote:
> On 2010-09-04 07:28 , LuKreme wrote:
>>
>> On 3-Sep-2010, at 19:15, Scot Hacker wrote:
>>
>>> Guessing here - Do you mean you share the iTunes folder on the host Mac
>>> over the LAN, mount it on the remote machine, and tell the remote machine's
>>> iTunes to use that as the iTunes folder?
>>
>> Yes.
>
> sounds like John meant he has the local iTunes using the remote iTunes
> database ("library") as well, which means not just pointing the local iTunes
> to the remote folder for tracks, but also tricking the local iTunes into
> using the remote database; otherwise data which is not stored in the track
> files won't be shared, and new tracks won't automatically be added;
Correct.
> i would much rather have separate databases with iTunes able to write to the
> remote database
It would be great if iTunes could handle several separate databases in
parallell, with the choise of presenting them as sperarate as they are or by
merging them in the gui for convinience. Two different views simply.
>
> to answer Scott's question "Is there a reason this is not possible?", it is
> possible but it presents some development challenges because writing to the
> "host" database implies much more detailed messaging between the machines and
> also handling of concurrent, possibly conflicting, changes -- e.g. several
> users could compete to rate the same song
>
That is why I need to avoid running two iTunes application instances at the
same time when they both use the same library.
For different users there might also be copyright issues that complicate
things. For a shared library for one and the same user the copyright isn't an
issue. In practice for me the concurense problem is not hard to live with.
There is a self explained reason why not being able to run two media apps in
parallell isn't much of a limitation. Copy back and forth is of course not
needed so what is left is an inabillity to listen to music/watching movies from
two or more sources at once basicly.
A per user solution together with more clear limitations on running the same
files in parallell (compared to the more invisible concurent file access
aproach in a file system for example) might turn out to be a bit more doable
than it perhaps seems to be at first glance. A concurent rate setting could be
somehow stacked and executed first in first done. The major file changes could
be made unavailable for the user when in parallell mode. It would only affect a
few users in a few scenarios. Those who want to import the same tracks from
different machines or delete tracks from one machine that is listened to from
another. Much of the other library changes could be made visible with a slight
delay on the machine that is unaware of what changes is done for the moment.
Some tasks could be delegated to a master of the apps which could be a setting
the user must set the first time. Like podcast auto downloads for example. I
most certaintly have missed some problems that makes this more difficult but my
main point is the concurence problems is perhaps not as delicate as with a file
system for example. The nature of how the iTunes application is used makes it a
bit more easier if the more or less sharp limitations on a few things is
acceptable.
// John Stalberg
_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk
