TuneConnect for Mac/PC

Devan,

You're unfortunately absolutely right-- Jaguar is the problem. TuneConnect Server requires Tiger. I've been able to get it working on Panther with a bit of hard work/recompilation, but I can't distribute a stable binary for it, only source and instructions.

As for Jaguar, here we have a horse of a different color. ;) Is it doable? Most likely. Am I eager to attempt it? I can't say that I am. :P Basically, I would need a system running Jaguar to do my development on in order to reliably setup a build chain to produce the files you need.

My advice to you: see if you can upgrade your server to Tiger (Leopard isn't necessary for the server, and only "enhances the experience" for the client). If it can handle Tiger (and my G4 has no problem with it), you'll be good to go. If you can't do that, let me know. I hate to see a disappointed user, and maybe we can work together to get your music server up and running again. :)

Did you change the port that TuneConnect uses? The errors are all pointing to 3032, which doesn't make any sense to me unless you purposely set it that way.

If you didn't manually set that port, then when you start TuneConnect (client), try clicking "Other...", then enter 192.168.1.4, with port 4242 (the default), and see if it can connect then. If that fixes things, first take a moment to rejoice. Next, we'll figure out why the server is telling the client (or why the client thinks the server is telling it) that the port is 3032.

Hmmm... try running the server without a password and tell me what happens then. Could make no difference, but let's see first.

There should be no limits, and your iTunes library should be accessible on a strange drive-- though it doesn't always work. First of all, go to the server, and visit this URL:

localhost:4242/serverInfo.txt

And paste the response to me. Then, as a test, visit:

192.168.1.4:4242/serverInfo.txt

From the client, and make sure it says the same thing. If it does, that means the server is operational, but it's a problem with the iTunes communication.

Beyond that, I'd love if you'd be willing to find this file on the server:

~/Library/Preferences/com.apple.iApps.plist

Open it up (hope you have Plist Editor installed, you do if you have the dev tools), and then make sure the first item in the array "iTunesRecentDatabasePaths" is accurate for your iTunes Library.

Let's start there and see what surfaces. :)

Hm hmm hmmmmmm. Well as long as that is what shows up in iTunes (on the server) as the location of your music library, then that's a touch unusual.

OK, next thing to try: disable library file caching (and restart the server). What happens when you do that?

It was actually fine, it came through correctly in the email. :P Try the caching tip a few posts up, and let me know what happens.

Well this is royally screwed up. :P I can say with 98% certainty that the problem is communication between the server and iTunes, which is not a problem I've ever run into before. Congrats on being the first to report (if not first to experience). :)

Restart the server, then restart iTunes. Then, from the server, run the following commands in succession:

localhost:4242/serverInfo.txt (just to make sure it's running)
localhost:4242/getSources
localhost:4242/getPlaylists?ofSource=insert-the-id-of-the-library-source-from-previous-command-here

(pick a playlist)
localhost:4242/getTracks?ofPlaylist=playlist-id:source-id
(ex. localhost:4242/getTracks?ofPlaylist=5424:40)

Let me know what happens with these.

It's not waiting long enough, that's definitely the problem. Unfortunately, it shouldn't have to wait that long. Approximately how many tracks are in your library?

Incidentally, quick! :P Without shutting down the server, go try the client. I predict that it should work pretty well right about now.

Ahh, well let's do this then. Just to confirm my theory.

Turn caching on, if you turned it back off (assuming you did? If you didn't, and it was already on, ignore the rest of this :P). Repeat the commands above up through the getPlaylists one. Then go back to the client, and try that.

Theoretically, as long as you left the default cache time of 1 day, your library should stay cached in the server, and it should be a touch quicker.

I can only assume these problems are because your library is so large -- this is never something I've had to deal with.

Basically, if your library doesn't change that often, you can set your cache to not expire, restart the server, recache one more time, and then you'll be good to go, hopefully forever. As long as iTunes doesn't restart, nothing in your library file will change until you add music.

Of course, this is not a satisfactory solution for me either. :P So I'm going to start doing a bit of research. I can't promise we'll fix this anytime soon, but there must be a solution, somehow.

Thank you very much, I appreciate the donation. :)

Incidentally, if you're just changing tracks and now browsing the library, you may have some success by pointing your web browser to the server: 192.168.1.4:4242

There's a lightweight web-client that doesn't touch the track browsing: turn off library caching, and use that to change tracks. If it's enough for now, that might help a bit. :)

Incidentally, in case the web client isn't sexy enough for you. :P How much would you miss the ability to browse tracks?

As an intermediate fix for TuneConnect 2.2 (just released 2.1 a few days ago, so this won't be out for a good month or two), I could give TuneConnect a "hidden override" to turn off all track-browsing features. That would at least allow TuneConnect to work for you as a basic controller. What do you think?

Quite frankly, I'm curious to understand why 1.x worked and 2.x doesn't as well. :P

Here's what changed: TuneConnect 1.x communicated directly with the remote copy of iTunes via Remote Apple Events. It worked, but it was slow and very unstable, and also required that the user enable a setting in System Preferences, which could be a bit of a pain. Most disappointingly, Remote Apple Events only work on OS X.

TuneConnect 2.x now has both a client and server-- the client and server communicate in their own HTTP-based language called Tunage (tunage.tuneconnect.net) that I wrote specially for this purpose. TuneConnect (the client) sends commands to TuneConnect Server, which then relays the commands to iTunes in a platform-specific way. Since the language that the client and the server speak is neutral, that means that TuneConnect can very easily become (and indeed, will become) cross-platform.

One of the things that makes TuneConnect faster (beyond the elimination of AppleScript, which is a very slow language) is that it has the capability to load your iTunes Library XML file, and cache that. Theoretically, the server can then return the results based on what's loaded into memory. Each time the library is loaded from disk, it should probably take awhile if you have a large library, but for each command sent between loads, everything should behave much faster. Why it's not, I don't quite understand.

Disabling library caching gets you as close to the way the old TuneConnect worked as possible, because it draws all of its track and playlist information directly from iTunes (just by way of TuneConnect Server). Perhaps if I add an option to increase the timeout, you might be able to make it work.

If you'd like to give it a try, I could add an option to increase the timeout, call it 2.2 alpha, and send you a private build. :P I might be able to get it going later today if you're interested.

Good luck!

I can just post it to my next comment. Expect it probably within the
next two hours or so. :)

OK, changed my mind a little to make my life easier. ;) Rather than start implementing a complex preference system for this in 2.2 alpha, I just compiled you our own very special version of Tunage.framework. This version times out after 5 minutes rather than 1 minute.

All you need to do is unzip this file (you'll have a folder called Tunage.framework), and drag that into the TuneConnect application bundle: right-click on TuneConnect, choose Show Package Contents.... Go into the "Contents" folder, then the "Frameworks" folder. Drag the new Tunage.framework there.

Should help. Good luck, let me know if it doesn't work. :)

Attachments:

• tunage-5minutetimeout.zip (30.6 KB)

Indeed I will, a user with a large library will be great to have around. :) Glad it works for you, albeit a bit slowly.