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.

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.

Brian

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

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.

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.


Brian

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.

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.

Brian

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!

Brian