Sunday, January 31, 2010

Strange occurrences in the "O Nine Five"

Lame title probably, but whatever.  I was running across a bug that if background monitoring was running and I changed an option, then background monitoring would stop but every action occurred twice.  So stopping twice, JOptionPane twice, and then re-enabling of the option I just turned off or vice versa.  Well, after much deliberation it was the JOption Pane warning of background monitoring being turned off because of a change in the Options object.  Basically, it was just the ordering of the code.  Well, rather than mess with it forever, iTunesDSM now warns of a change in the options and background monitoring in the System Tray.

Crisis averted.


Friday, January 29, 2010

Today's Update

A little more technical but the Options class used to output to an xml file that was generated by the Properties class in the java.util package but the rest of the class was the same as it always was.  Well not anymore!! haha, the Options class has been fully converted to a Properties object (it extends Properties).  It cleans up the code and makes more sense.  Also, the Options class now makes sure the options file is compatible with the current release of iTunesDSM.  This is accomplipshed by checking a Version key in the Options/Properties object.  If the version key is there and it's the same version as the release of iTunesDSM then the file is good.  If the key is not present or it does not equal the release then the test fails and a new Options object is created.  Still a few other kinks to work out before 0.9.5 is released, but multiple directories is still on target.  Hope everyone has a good friday night.


Thursday, January 28, 2010


Amazing!!  167 downloads in one day!

Other news...I'm testing the next version now which allows for monitoring multiple directories.  Look for a release soon.


Wednesday, January 27, 2010


You can see by the title...a new record today 91 downloads in one day!!!!  Keep it up!


Monitoring multiple directories

You read right!  For the past couple of days, I've been implementing my last idea.  I've had it in my mind to be able to add tracks from an unlimited number of directories.  This makes sense for so many reasons, that's it's not worth mentioning them, but it will improve the usefulness of iTunesDSM greatly.  Of course allowing multiple directories does institute a greater risk of creating duplicates, good thing iTunesDSM can take care of that too.  It should be pretty rare, especially if iTunes copies tracks and keeps the folder organized.  Another added benefit is removing duplicates from multiple folders in one fell swoop. 

To add the multiple folders I've had to do quite a bit of modifying, but the screenshot below should do some justice.

I've arbitrarily given this version the number 0.9.5, but who knows it may change.  Hopefully this has whetted your appetite!  Toodles


Tuesday, January 26, 2010

Version 0.9.1 released!

Version highlights...
-View added tracks in an iTunes playlist - Windows only
-Icon resolutions fixed
-See when the next background scan will occur by hovering over the tray icon

Check the changelog for more detailed release notes.

Monday, January 25, 2010

What would you like to see in iTunesDSM?

I'm approaching the end of my ideas I have for iTunesDSM and I would like to know what features you would like to see.  If you feel inclined, add a comment below this blog post with your feature ideas and maybe I can implement them.  Thank you!


Sunday, January 24, 2010

Fixed fuzzy (low resolution) icons!

So I finally figured out how to get better resolution icons in Java.  You just need the setIconImages method and a List object of all the icons.  So make some higher resolution square png files and add them to an array list that you then set the JFrame icons too.  Neat!  Heres a screenshot...

Also I added a line to the tooltip that tells when the next background scan is schedule to run, roughly.  Remember it uses the sleep method in threads, so it's a pretty close, but yet still rough estimate.  View the screenie with pleasure...

Hope everyone had a good weekend.


Some cleanup and JUnit testing today

Some quick notes, every now and then I go back and create JUnit test cases for classes.  I don't do it often because I change the code so frequently that it's not really worth it at the time.  But I've added a couple of test cases for the AddTracksTask class.  Specifically testing the method that finds new files.  That's not to say I don't test the code myself, I just make it automated after a while.

Also, I've removed the FolderWatcher, AllFiles, and related classes.  They simply weren't needed anymore, and while they did work, it's just not effecient to use those methods here.

Of note, yesterday I noticed 77 downloads on sourceforge.  That's a new record for daily downloads woohoo!


Friday, January 22, 2010

iTunes Playlist back in

It's something that seems to come and go, but iTunesDSM will now add new tracks to a playlist in iTunes again.  You can see in the screenshot an automatically generated playlist.

Wednesday, January 20, 2010

Javadoc now online

You could always download it, but it's convenient to go to it online as well.  The link is on the right or you can click here.

Version 0.9.0 released!

Check the change log for new features.  You can download the new version from the usual links on the right.

Tuesday, January 19, 2010

Few updates today

A couple quick things.  The ProgressMonitorDialog box class that I was using to display progress updates had an issue when it was the first active gui element.  I've switched from ProgressMonitorDialog instance to just updating the main gui.  It's probably best described by the screenshot.  This version is in its final stages of testing, so without speaking to soon, expect a release soon.

Don't forget this version makes numerous improvements to background monitoring.  It will be a much recommended update.


Sunday, January 17, 2010

Still moving along

Some of the new features if you're keeping up...
  1. iTunes does not have to be running to check for new tracks.
  2. iTunes will close smoothly (user script warning does not pop up)
  3. Cleaner progress notifications
  4. More options in the system tray menu.
  5. Major bug fixes
  6. Better memory usage
It's still in testing as I keep making modifications, but it is nearing release, version 0.9.0 that is.

Thursday, January 14, 2010

Now that all the code upgrades are complete

I've done some more major code modifications.  For one the status panel at the bottom is gone.  I'm favoring regular old progress monitor objects. 

Also, and this is a biggey!! iTunes no longer complains about closing when user scripts are active.  In other words, if iTunes is open and you try to shut down your computer or just close iTunes itself, the warning box won't come up anymore talking about user scripts when you've used iTunesDSM.

I'm stopping all major code modifications and just working on bugs I find so that I can release the next version in a couple of days.


Once and for all memory issues

I tell you there is nothing more frustrating than seeing the memory usage go up and up until you decide that the code cannot be simpler and the references fewer.  After testing every component, I have come to the conclusion that the garbage collector is less judicious than I OCD but that the garbage collector does remove unused items.  You can see when you limit the vm to a certain amount of memory.  So, moral of the the vm and the garbage collection.

Wednesday, January 13, 2010

Finally figured out how to cast IITFileOrCDTrack in Java with Jacob

I'm moving away from the iTunesController package as everytime it's used the Com object stays active and iTunes complains when you want to close it.  Also it seems to be a source of memory leaks.  Speaking of which all are fixed now.  Anyway, it was difficult to get rid of the iTunesController package because it allowed me to cast to an ITFileOrCDTrack which was needed to get rid of orphaned files.  But now...I've got it working with more pure Jacob code.

Its inspired by the Limewire program source.  The code is open source and written in Java and therefore much of the iTunes code is now based on that code.  Here's the code I'm using to remove orphaned tracks.  First you need the iTunes Jar file from limewire.  You can download the source and it's included in the folder:  limewire/lib/jars/windows

Then use this code..

ActiveXComponent iTunesCom = new ActiveXComponent(ItunesMediator.ITUNES_ACTIVEX_NAME);
Dispatch iTunesController = iTunesCom.getObject();
IiTunes it = new IiTunes(iTunesController);
IITLibraryPlaylist pl = it.getLibraryPlaylist();
IITTrackCollection coll = pl.getTracks();
ArrayList orphanedFiles = new ArrayList();
int count = coll.getCount();
for(int i=1; i<=count; i++){ if(mon.isCanceled()){ break; } IITTrack track = coll.getItem(i); if(track.getKind() == ITTrackKind.ITTrackKindFile){ IITFileOrCDTrack file = new IITFileOrCDTrack(track); if(file != null && file.getLocation().equals("")){ orphanedFiles.add(file); } } mon.setProgress( (int)(((double)i / (double)count) * 50) ); }

No messy QueryInterface method stuff.  Since there was no JavaDoc on the iTunes jar and the jar itself is a Jar, it took forever before I just tried this.  But it works.  Hope this helps anyone else looking for info on this.


Tuesday, January 12, 2010

Parsing the iTunes XML file yet again...

I've discovered that the major cause of the memory leak was using ITunesController.  Something I'd always suspected but I didn't really have any ideas for how to get around it.  Until I finally figured out how to get the track locations from the iTunes XML file.  It mainly has to do with the URLDecoder class.  But once you use the decoder class there are still some characters that the XML file has thrown in there that don't seem to be UTF-8.  So replace those characters and bam you've got track locations.  The other benefit is that the file is parsed by line, both good and bad.

The that it's much faster just reading the xml file line by line.

The bad...if Apple changes the itunes xml file format or simply rearranges the lines.  I've got to go back and fix the parser.  But I don't think they will ever change it so I'm good there.

More updates to follow later.

Now that I can reliably parse locations from the iTunes XML file.  I now remove another component that requires the ITunesController and hence objects that can't be garbage collected.

Lastly, every time the add tracks operation was run a new playlist was added to iTunes....another memory leak generator.  So I've switched a simple text file that contains new tracks that have been added to iTunes.  The user can right click on the tray icon and select an option to open the text file and a button has also been added to the Add Tracks Panel.

Back on track

iTunesDSM 0.9.0 seems to be back to normal.

Monday, January 11, 2010

Memory leak updates

Turns out the chart in Netbeans was misleading.  I ran my program again as an independent jar file rather than through Netbeans, and the RAM usage was much more accurate.  I'm still working on it, but it mayyy be that the memory issue is fixed.

As part of my thinking on this, I also believe that part of the issue is the way I'm dealing with SwingWorker threads.  With everything, you learn ways of doing things as you work with something new.  I realized that the SwingWorker constructors in all my classes typically have some object that either stores or displays information.  For example, the DuplicatesTask class takes an ArrayList of file objects.  I use that object to store the duplicate files that are found, so that if the user cancels, the object is still updated with at least some duplicates.  I now see that is not the correct way to do things, I've learned more about SwingWorker listeners and I plan to switch over to a listener that publishes new duplicate files that are found.

I've also simplified the BackgroundMonitor idea.  Rather than search for new files and then fire an event with changed folders, why not just scan the music directory every time.  It doesn't really add much overhead and simplifies code.  On top of that, the actual AddTracksTask class is in the process of being reworked as well.  I came across an idea that should speed things up a little bit.  The new process is a variation of the old but faster.  Here it goes...

1.  Get all locations of files in iTunes (either through XML or iTunesController).
2.  Get all files in the music directory that agree with the MediaFileFilter.
3.  Read the exclusions list.
4.  Iterate over the iTunes track locations and remove those file paths from the music directory file paths.
5.  Iterate over the exclusions and remove those files from the music directory.
6.  Whatever is left are new add those to iTunes.

It should make the RAM usage a little less, as I'm using HashMaps, and if I decide to switch to the XML file, iTunes does not need to be open to check for new files.  I'm still debating on that one.

Anyway, dinner time.

Sunday, January 10, 2010

Still working on the memory leak

It turns out that a big portion of the memory use was due to ineffecient coding, which I have greatly improved.  But the memory leak is still occuring, it's just starting off and using lesser memory.  I have found the cause to be the AddTracksTask class which when run, it doesn't seem to release the JACOB objects.  For those of you reading, I'm using the iTunes Controller package and after looking at the code, it doesn't release the ComThreads, maybe that has something to do with it.  Anywho, I'm in the process of rewriting the AddTracksTask class so it may be a while before 0.9.0 is released.

Friday, January 8, 2010

Working on a memory leak

It's interesting that this should come up since Java handles garbage collection(memory is automatically returned to the VM) but I have a few suspicions as to why the leak is occuring.  I'm using Launch4J to create an EXE file for my program.  It's convienent because it makes it easy for Windows users who recognize an Exe file.  Surprisingly, Memory usage shoots up.  Sometimes the VM would require 100MB of memory, even though that wasn't the real usage (VM sets aside memory it thinks it will need).  In fact when I profiled iTunesDSM within Netbeans most of the time the memory required was only around 14-35mb(depending on whether the gui was visible-not disposed).  Well after running iTunesDSM.exe in the background for most of the morning, the memory required had ballooned to 245MB.  Totally unacceptable.  So experiments abound.

When running the iTunesDSM.jar file that the Exe file references, memory usage(before gui) was hovering around 15mb.  Not bad, espicially since background monitoring was starting.  Start the gui and it jumps to 45mb not bad.  So is it Launch4J or background monitoring.  I'm taking out the Launch4J first and experimenting.  I'll report back later.


UPDATE:  It's not Launch4J.  It seems to be in the FolderWatcher class.

Thursday, January 7, 2010

Background Monitoring and Network Folders

Had to fix an interesting issue this morning.  When background monitoring was set to start on boot, sometimes the network folder wasn't ready and an immediate IllegalArgumentException would be thrown.  SwingWorker to the rescue.  I suppose you could use threads just as easily, but the SwingWorker is convienent because it already includes events for when it's done.  So basically, the directory to monitor now has a timeout of about 15 seconds.  If the file is a directory all is well, if not a warning comes up.

Tuesday, January 5, 2010

Version 0.8.3 bumped to 0.9.0

There are so many fixes it deserves its own minor version number, again here's a quick run down of the new features on the way...

-iTunesDSM now adds new files directly to the library then creates a playlist
-iTunesDSM playlist now keeps a running list of all songs added to iTunes
-Numerous Background Monitoring fixes
-Background monitoring can now be dis/enabled in the System Tray
-Cleaner system tray notifications
-Cleaner Options panel
-User can cancel the iTunes XML file search

It's still being tested but I'd say this week the next version will be released.  The big thing here is much improved background monitoring.


Monday, January 4, 2010

0.8.3 updates

So today brings plenty of updates.  First up, is the system tray icon, now includes an option to start and stop background monitoring.  It's convenient obviously, and the options panel now reflects the status of the background monitor when ever it is opened.  Here's a screenshot...

Next is the cleaner options panel.  It was getting cluttered.  Here's a screenshot...

You can also see the status bar at the bottom has been simplified.  There is no longer a box on the left showing background monitor information.  It simply isn't needed, and if you are using Background Monitoring in a previous version, you may have noticed a lot of information that is displayed in the status bar that's not of much use to the average person.  So it got the axe.

Lastly, you can see the new option to set the music directory to the iTunes music directory.  It's a convenient feature, since the network can talk a while to load on a JFileChooser.

I'm looking to make a release here soon.

Sunday, January 3, 2010

iTunesDSM playlist now keeps a running list of new songs

I have finally figured out, at least today and I'm pretty sure it works, how to keep a running iTunesDSM iTunes playlist for all tracks that are added over time.  Basically, everytime the AddTracksTask is run, the previous playlists, if they are there, are read for their tracks.  Then the tracks added from the current task along with previously added tracks are added to a new playlist.  Finally, old iTunesDSM Added Songs playlists are deleted.  This way, songs that are added from the background and manually are all added, or appended, to one playlist.  It will make it much easier for the user.


Background Monitoring for this week again

0.8.2 is an improvement in Background Monitoring but it's still not quite there.  As we know, when we first start background monitoring the directory is checked for new tracks to add to iTunes to be sure that any previously added folders are added, iTunes is synched up basically.  Well, sometimes it doesn't happen.  The new idea is to  just expand the AddTracksTask SwingWorker class to check multiple folders rather than scan one folder.  This way all changed folders can be sent to the AddTracksTask class and one SwingWorker thread can run for all folders rather than trying to force multiple AddTracksTasks to run one at a time.  In preliminary tests it seems to be more consistent.

Because of the multiple folders that AddTracksTask will support.  I'm thinking I can move to multiple folder support for everything.  In this case, multiple folders could be watched, multiple folders could be searched for duplicates, etc.  It would make sense for folder watching especially.

Lastly, I'm thinking of making the music directory the directory that is parsed from the iTunes XML file.  It will make things a little quicker for the user.  I'm also still looking for a job, should anything come up let me know!