Alright, I was asked to repost the code for ourTunes with some of the fixes, so here it is:
ourTunes1-7g.jar

It fixes the file renaming error, and catches an Exception in the JmDNSImpl.java that prevents ourTunes from seeing networked clients - you still may see minor problems with this issue.

However, there is still a problem with ourTunes under OS X. There is a header field in the passing data specifying an
x-audiocast-port: < port number>,
and when I can get back to work on this project, I want to see what data passes on that port. I do believe it’s UDP, but I’d need to double check.

Otherwise, my apologies for the late repost. This weekend was fantastic on campus with the win over UT.

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.