News is rather slow, but so is testing and development.  After looking through a few posts today, I felt that I might be able to post a few code changes and see if it improved certain aspects of the program; however, certain issues are bound to remain in the program.

Note - this updated version is experimental and not really developer tested.  I would greatly appreciate others input…
(1) Often reported by people is the fact that they can’t see the list of shares in ourTunes.

+If you have a firewall enabled, then allow inbound/outbound to the programs java and javaw!  ourTunes is useless without its networking components!
+However, some users were still having problems.  I lengthened the time it takes for an share to report to the GUI; this is to prevent thread interference.

(2) This was a feature request from nearly 3 months ago, but wav and midi files are now supported.  (As a note, ourTunes doesn’t recognize the extension “mid” - it must be “midi”)

(3) ourTunes switched JmDNS libraries to version 2.0 - The behavior changed somewhat from the previous verison of the library causing the word “Tunnel” to appear in iTunes instead of the library name.  This makes it easier to find the mirror, but it’s accidental.

(4) ourTunes no longer shares port 3689 with iTunes; this was done in the hopes that ourTunes and iTunes would play nicer on OS X, but I don’t have access to a mac for quite some time.  I’m hoping OS X users would be able to test this proposition…

—-

Lastly, I’ve read news here and there about Wine on Linux.  With Wine, a linux user is now capable of using iTunes on his machine.  The good news is that ourTunes can run on the Wine platform; the bad news:  A Linux user needs to write an appropriate class that implements ourtunes.os.OS (source code and documentation are inside the file), and then pass me the result of the call System.getProperty(”os.name”).

In future update, I intend to linkify the hyperlinks in the about panel, so please include in the implementation the following method (appropriately, it should launch the web browser and go to the page specified by the URL):

public void launchHyperlink(URL address); //don’t assume firefox is the default web browser on the OS!
Link here:  http://www.webpages.ttu.edu/mroth/tunes/ourTunes1-7f.jar

From Flug -

Download ourTunes1-7e here

Version e of the ourTunes is available. Here are a few of the fixes:
a) ourTunes will now work around Limewire services; however, ourTunes and limewire are incompatible.
b) The GUI now uses re-entrant locks. This means that threads don’t wait on each other to begin execution.
c) inadvertent data was being stored into captured songs; this no longer happens.
d) MP3 files with missing tags don’t throw exceptions. All captured files will be renamed instead of keeping the 4-digit number.

However, there are a few bugs that keep the program from being finalized.
The AAC-OSX bug: essentially, when using ourTunes from OS X (10.4 or later), MP3 files will download fine but M4A files will not.

Upon surfing the internet it was discovered that iTunes was disabling the DTrace utility in OS X (Read more here). This suggests that iTunes on OSX is working the Operating System more so than on Windows, and if I can’t work around the bug, the solution is to disable AAC downloads for OS X users. Any help solving this problem is greatly appreciated!
File Save problems: Mac users have reported on several instances that they cannot save the music to file after they have changed the download directory. I suspect this is due to file permissions, but will include a better explanation about the problem in the next iteration.
Mac .app:, I intend to bundle the ourTunes program into a full fledged application for the Mac Users (Windows users will have a variation to use also). With this, I can place the menu bar in its proper place on OS X instead of inside the JFrame.

Right now, I’m pretty much interested in solving only these problems in order to finish ourTunes. P2P networking will not be added - that is not the intent of ourTunes.

a copy of ourTunes (version c) is available at http://www.webpages.ttu.edu/mroth/tunes/ourTunes1-7c.jar (links directly to the file, not a webpage!)

Notes on version c:
1.  I reworked a few of the networking aspects to increase compatibility among all the Operating Systems.  Unfortunately, I had the most trouble with Mac OSX.
2.  Thanks to abandonedhero for creating the program icon!  It’s a tad blurry for 32×32 resolutions, but I had the icon drawn elsewhere in the container so it could be clearly seen.
3.  Thanks to secret_squirrel for providing MP3 tag-reading support.  I also incorporated the jaudiotagger project for aac metadata and consequently, the format ouput filename pane is now functional (albeit, click enter after changing the text-field!)
4.  Certain people mentioned that the program just crashed without reason.  This was due to the fact that the Operating System could not resolve link-local addressing.  ourTunes resolves the link-local address to IP addresses.
5.  Speed Downloading! Many others could not download a single song because iTunes would break the socket connection.  OurTunes will now continue the download when the socket connection breaks.  Furthermore, ourTunes will speed the download up considerably when this happens.  (iTunes will break a socket connection if the user pauses the song while listening to it).
6.  ourTunes will now say if you’re downloading an mp3 or an m4a file.

Tips to getting ourTunes working better:
a.  Start iTunes before starting ourTunes.
b.  It helps to fully listen to the first song; “speed downloading” often causes iTunes to disconnect from the share which is an inconvenience.
c.  I’m having huge headaches with ourTunes on Mac.  I am to connect and select a song for downloading, but iTunes disconnects the share shortly after selecting a song to download.  This causes the speed downloading (thus I ultimately get the song I want), but on a few occasions, the file was corrupt after download.  I think it has something to do with the Apple VM, but I have no idea why iTunes on Mac is so fickle.

Significant challenges left in the program:
a.  Unicast mDNS queries.  I’m caught in a rut on this issue, because I can’t use apple’s library (it’s OS-dependent last I checked), and without mDNS, iTunes will never see the duplicate share.
b.  Smoothing out the pass-through service, especially for mac osx.  If anyone cares to try, I’d like to know if ourTunes is more successful when registering a ._dacp._tcp.local. service on the network.
c.  Sometimes java doesn’t close out ourTunes correctly which prevents future versions from operating correctly (In windows, one would need to terminate the javaw.exe process).
d.  The list doesn’t always populate with shares.  If this happens just close out of ourTunes and try again in a few seconds).

Please leave comments, ideas, suggestions, etc. in the thread.