Archive for February, 2010

Just Playlists 1.6.6—Bug Fix: Rotation While Loading a Playlist Sometimes Reset Last Playlist

Friday, February 26th, 2010

I found and fixed a fairly nasty bug in Just Playlists, so I’m releasing a new version, even though the last one hasn’t been out long.

If you were on the playlist chooser screen, clicked on a playlist, and then happened to rotate your phone during the load, the save data for the last playlist you were using could have been corrupted, so that the next time you loaded it, it would have forgotten where you were and would ask if you wanted to shuffle it.  Also, if you exited and re-ran the program, it may have started without a playlist loaded, just like the first time you ran the program after installing it.  I’ve corrected both problems.

While I was at it, I also added a clickable link to this blog in the “About…” dialog box.

Just Playlists 1.6.5—Faster Track Information Display Transitions, Text Crawls, Bug Fixes

Tuesday, February 23rd, 2010

I’ve managed to shorten the time it takes to load the artwork and tag information as tracks change during continuous playback.  Most of the time, the track starts to play at almost the same time as the information loads on the screen and the seekbar resets to 0.  If you’re running other things on your phone or memory is short, it could affect the time things take to happen.  But, overall, it should work a lot better.

I also found a good way to enable long text lines to crawl across the screen, rather than just using ellipses to indicate some of the text has run off the screen.  I’ve implemented this wherever I could that made sense to me.

Beyond this, I found a few more bugs that could cause crashes or strange program behavior.  My favorite one was when my phone crashed and, after it restarted, Just Playlists thought that my playlist files had changed and started offering me the option to shuffle them.  As it turns out, sometimes the version of Android I have running on my phone seems to get confused about the time zone and sets file modification dates improperly.  Thus, Just Playlists sees the file as changed because of the new timestamp and offers to reload them from scratch.  To avoid this, I now store the playlist files’ MD5 checksums and only consider a file to have been changed if this changes.  Thus, the actual content of the file must change and not just its last modified timestamp.

As I stated in a previous post, the next enhancement to the program will be a playlist creator/editor.  This will probably be a bit of work, so the next update might not be for a while, unless I find or hear about a major bug in the current version.  I hope I can also roll out the playlist editor in increments, adding features over time.

Just Playlists 1.5.2—Show Database, Notification Preference Setting

Sunday, February 14th, 2010

Time for a new version of Just Playlists.  In this version, the “Show Database” option menu item is active.  It shows the contents of the program’s database, which is where information is saved about each playlist you’ve used.  There is one entry per playlist, with a variety of data saved that allows the program to start playing a playlist from where you left off the last time you used it.  You can delete an entry by long-clicking on it.  The only entry you can’t delete is the top one—which is the currently-loaded playlist.  Entries are sorted in descending order by the date they were last loaded.  The currently-loaded playlist’s entry is the first and the playlist you haven’t loaded in the longest time is at the bottom.  Deleting a playlist entry doesn’t delete the playlist file from your microSD card.  Thus, deleting any entry for a playlist is pretty much the same as setting it up to reload from scratch—after deleting the entry, the next time you load the playlist, you’ll be asked if you want to shuffle it or not and a new database entry will be created.

The only time may want to delete a playlist entry is if you have deleted the playlist M3U file from your microSD card.  Once you’ve done this, you’ll see that the database entry for that playlist will say “File not found” in yellow text for the “File mod time” database field of the entry.  There is no modification time because the file no longer exists.  Leaving the database entry in the database doesn’t hurt anything, but it’s nice not to have unused stuff cluttering up the database.  If you have a huge number of unused entries, it could slow down the program a bit, so this is another reason you may want to delete “orphaned” entries.

The new preference I’ve added allows you to tell the program not to display its icon in the notification bar when it isn’t actively playing a song.  This is how the default Android music player works.  I prefer having the notification icon showing whenever the program is running—just so I can get back to it from any screen.  If it bugs you to have it showing, unchecking the option in the “Preferences” screen will take care of it.

For the next version of the program, I’m going to see if I can speed up the load time of the album artwork and track information when the next track starts playing during a regular playback session.  Right now, it can take a second or more for the info to load after the new track starts playing.  After that, I’ll take a look at creating a built-in playlist creator/editor for the program.  I haven’t considered this a high priority, since it seems to me creating complex playlists is going to be cumbersome on the phone compared to doing it on a computer and then uploading.  But for quick, small playlists, it could be handy.

Just Playlists 1.4.2—Minor Improvements and Bug Fixes

Sunday, February 7th, 2010

Though I don’t have the “Show Database” feature ready yet, I improved a couple things and fixed some bugs that make a release worth it.  The bugs may have caused crashes when you rapidly changed between playlists or used the “Show Playlist” menu item.  As to the improvements, first, if you use the “Show Playlist” menu item to see the contents of the current playlist, the current track will be highlighted in green text.  In 1.4.1, the track won’t be updated if you have the playlist screen open when the next song begins to play.  In 1.4.2, it will.  If you leave the playlist screen open, the currently-playing track will always be in green and at the top of the screen.

The other improvement is sort of a bug fix.  It’s actually more of a workaround for a problem with Android’s Java implementation.  When using Just Playlists, you may have had the track’s artwork not show up even though you have artwork embedded in the file.  This shouldn’t happen any longer—unless the artwork really isn’t there.

For the curious, here are the gory details.  I use Java’s getCanonicalPath() method to turn the track name read in from an M3U playlist file into a fully-qualified file path with all relative references resolved.  This is used as a lookup key for ID3 tag information in Android’s database of scanned media information.  But, there seems to be a bug in Android’s Java implementation such that every so often, the method will throw a NoSuchElementException.  This isn’t supposed to happen.  According to Google’s issue tracker, this is a known problem in Android 2.0 and will be fixed in a future release.  So, it may not be happening any longer in Android 2.0.1 and 2.1.  I’ve also seen it in version 1.6.  I’ve added a try/catch block that handles this exception and uses the un-resolved track name from the M3U file if need be.  The key derived from this isn’t guaranteed to be unique in the media database, but it most likely will be and so will retrieve the proper ID3 tag info—including the artwork for the track.