Keith Folsom's Blog

I’ve found that JP has been unexpectedly stopping media playback and exiting for quite a while.  This would consistently occur after around a half-hour of run time.  It seemed to have started after an Android OS update in the past.  Examining the phone system log showed that the operating system was stopping the program, as if it didn’t know it was active and should be left to run.  The log message was flagged as  a “WIN DEATH” even.  I had thought I’d protected against this when I first created Just Playlists.  It turns out that–somewhere around Android version 2.1–programmers were being instructed to explicitly alert the OS that a running service shouldn’t be shut down as part of Android process management.  This is done via a  call to the startForeground() method.  When the service is in a state where shutdown is acceptable (such as not actively playing music), the stopForeground() method is to be called.  By adding these calls where appropriate within the code of Just Playlists, I have fixed the problem and JP no longer exits in this way.

I’ve also received reports from users that the program has been exiting when the screen is turned off on some devices.  The Archos Android tablet is one such device.  I am hoping that the change described above will also fix this problem.

As part of trying to work around this problem, I also added code to save track position every few seconds, such that if the program does crash or the OS shuts it down, the next time JP is run, the track that was playing should be ready to play again at the same position it was at before the shutdown.

A user has been waiting since January of this year for a promised update to JP that would use a double-click of the play/pause headset button to cause a next track action.  Thanks, Nicholas, for your patience.  I have implemented this.  I’ve also added a triple-click for doing a previous track action.  It sounds like this is a standard feature of other apps–including the stock Android music player.  It’s not something I was aware of, but it is a useful feature.

I haven’t had time to add any new features to Just Playlists once again, but I have improved a few more things under the hood.  First, I was alerted by a couple users that I wasn’t allowing for non-MP3 streams, even when the codecs are supported on the phone.  I added stream types that I know of, chief amongst these being Ogg streams.  Even with this, Ogg streams don’t all play back reliably, though this may be an underlying Android problem.  Ogg streams also show a starting play time greater than 0:00.  I haven’t figured that one out yet, but it doesn’t really impact use.

Android versions 2.2 and greater offer native SHOUTcast streaming support.  Thus, I no longer massage the headers sent and received by the Android media service.  I don’t know if this will improve performance, but it should make it more likely not to be broken by future Android updates.  I also am no longer hard-coding my proxy server to port 8080–I let the device choose an unused port when the proxy is started.  And the media service no longer fails to start when a “Content-length” header isn’t received–it just issues a warning.  This means I don’t have to fake it out with a huge number.

Finally, I fixed some bugs, including a null pointer reference that was reported a few times via the Market.

The next new thing I want to add to JP is re-starting playback of a stream when it disconnects unexpectedly rather than just going on to the next stream listed in a playlist.  And, of course, I still have a huge number of new features to work on, as time allows.

Google made a change in the way the Android OS handles media streaming in version 2.3.3.  In past versions, the HTML “Transfer-Encoding: Chunked” header was accepted but chunked transfer coding was not actually implemented.  That allowed me to get around not having an explicit content length for streaming media, though I couldn’t chunk the data stream.  In 2.3.3, Android is handling the chunked coding.  I’ve thus adjusted JP/JPP accordingly.

A new user named Grant found a problem with JP relative to how other programs interpret relative file paths.  In Unix, if you specify a file path like “/here/there/everywhere,” it means this is an absolute file path that starts from the root of the partition.  But it turns out that most/all music programs Grant and I have tried also see at is a valid way to refer to a relative file path starting in the current working directory.  It’s equivalent to “./here/there/everywhere” and “here/there/everywhere.”  I’ve updated JP/JPP to work the same way.

I haven’t had time to implement any new features–including a few suggestions from those using the program.  I’ve moved and started a new job over the last couple months, which hasn’t left me much time for Android programming.  I’m getting settled in and will try to get some new features out in not-too-distant future.

I had a chance to try JP on a Samsung Galaxy Tab and found that the progress bar wasn’t extending properly across the larger screen.  I fixed this, such that any screen size should work properly.  I’ve also built the program using the Android 2.3 (Gingerbread) SDK and run it within a 2.3 emulator without any problems.  I haven’t had a chance to try it on the new Nexus S with 2.3, but it should work just fine.

The only new feature in 4.1.0 is for JPP.  You can now select tracks from the “Create playlists” function of the app and then, when you use the “Edit playlists” function, you will be asked if you wish to insert these tracks into the playlist(s) being edited.  Thus, you can add tracks to existing playlists, rather than just being restricted to editing and combining playlists.

I’ve added playlist editing to Just Playlists Plus 4.0.0.  You can edit single playlists or select a number of playlists and edit them as a whole, to create new, aggregate playlists.  Once a playlist is in the editor, tracks can be selected, deleted, copied, and pasted in a number of ways.  I hope it’s fairly intuitive and can be learned quickly with a bit of experimentation.

One nice thing is that it’s pretty hard to lose your edits.  Once you’ve begun to make changes to a playlist, you can exit the editor and even close the program and, when you choose to edit playlists from the menu once more, you will be taken right back into your last editing session.  Until you explicitly save an edited playlist or exit the editor without saving, you’ll always be presented with the playlist that is currently being edited.

The one thing that can’t be done right now from the editor is adding new tracks.  I’ll see if I can come up with a good way to do it.  But by creating new playlists and editing them into existing playlists with the editor, it’s possible to accomplish the same thing.

For both Just Playlists Plus and Just Playlists, I’ve made the default background color a shade of charcoal.  I received quite a bit feedback saying that the old gray color wasn’t ideal.  You can still choose the gray background or several others from Preferences.

Another feature is that, from the playlist chooser, you can now use the menu to specify the current directory as where newly-created playlists should be stored.  In the past, new playlists were saved in the directory where a playlist had last been loaded from or in the root of the SD card, if none had ever been loaded.  This is only applicable to the “Create playlists” function.  When editing playlists, they will be saved in the directory from which the edit is started.

Another new feature is that a default playlist directory is now created when the program is first run.  It’s called “justplaylists/playlists.”  Along with this, a couple sample SHOUTcast streaming playlists are included.

I’ve integrated Last.fm scrobbling support.  That means, if you install a program from the Android Market like Simple Last.fm Scrobbler (SLS), it will detect when Just Playlists starts and finishes songs that are on your phone and send this information to Last.fm to update your listening stats.  If you don’t have SLS installed, scrobbling won’t happen.   Also, streamed music isn’t scrobbled, at least for now.  Information about song titles and artists isn’t sent to JP in a consistent format with SHOUTcast streams, so it would be a bit problematic to scrobble the info.

Thanks to Eric and others, I’ve been able to improve streaming a bit–particularly for MP3′s hosted on a server and played by clicking on an M3U playlist file in a browser.  There were problems getting JP to work reliably while doing this.  I was able to make some changes to the program that made it work, at least in most cases.  I also learned about a really neat program called GNUmp3d.  It is a streaming server that can be installed under Linux or Windows and which indexes your music collection and lets you browse and play it via a web browser.  If you are using an Android phone with JP installed, you can click on a “Play” link and a hosted M3U file will be sent to the phone which JP can play.  The only problem I’ve found is that Android doesn’t always seem to stream VBR (variable bit rate) files all that well, so if your music collection is VBR, you might have to set GNUmp3d to dynamically transcode your files to CBR (constant bit rate) for reliable playback.  Other than that, it’s a great way to avoid copying files to your phone if you have a large music collection.

I made a few other small fixes and improvements behind the scenes.  The one that is most visible is making Windows Media files (.wma) visible during playlist creation.  If you have a phone or app with support for WMA playback, you can use JP to play WMA’s or a least create playlists for play by apps that support WMA.

I was able to reproduce the crash people were getting with version 3.5.0.  The fix in 3.5.2 kept the program from crashing but still gave an erroneous error message.  This was only happening on the initial run of JP or JPP by someone who had not installed it before.  It was caused by the Java getCanonicalPath() method resolving a “” into a “/”, for the programmers out there.  That doesn’t seem quite right to me, but, either way, it will no longer cause problems.

I’ve received quite a few reports of force closes that seem to be caused when users are opening playlist files without an .m3u or .pls suffix.  I haven’t been able to duplicate the crash but have added code to the program that will prevent a crash and instead produce an error message.

I’ve also received several queries about playlist editing in Just Playlists.  This is my next major goal for the program.  I hope to have it done within the next month or so.  It will be a feature only available in the Plus version.  I’m also going to see if I can integrate scrobbling soon, as requested by a user a while back.

This release doesn’t have any major new features and all changes are in both JP and JPP.  The most visible change is that, if you are a fan of the awesome streaming station called Radio Paradise, you will now see album artwork displayed when you play their 128Kbps MP3 SHOUTcast stream.  Though it might sound like I’m favoring RP with a special feature, it’s really their ingenuity that allows for the artwork.  They attach a URL pointing to the album artwork hosted on their website for the current song within the “StreamUrl” metadata tag for their 128Kbps stream.  Most SHOUTcast streams either don’t use the StreamURL tag or just have a URL for their main website.  So, though Radio Paradise is the only stream I know of that uses the tag in this fashion, any stream doing something similar will end up with the image showing up in Just Playlists as album art.  I wish many more streamers did this.

If you want to listen to Radio Paradise and see/hear for yourself, a direct link to their 128Kbps MP3 SHOUTcast stream is http://www.radioparadise.com/musiclinks/rp_128.m3u.  You can tap this URL on your Android phone and choose to open it with Just Playlists.  That’s all there is to it.  To save this as a permanent playlist on your phone, choose the “Create playlist” item from the main display menu after you’ve loaded up the stream as described above and, once there, choose “Save hosted playlist” from the menu and give the playlist a name and save it.

The main website for Radio Paradise is http://www.radioparadise.com, if you’re interested in finding out what’s playing, looking up information on the songs they’re playing, or giving them a donation—their broadcast is listener-supported.  If you access their website from your phone, you’ll be directed to a mobile website.  Choose the “Listen” link to access their stream links.  Make sure you scroll down to their MP3 links if you want to use Just Playlists to listen to the stream.

The other useful change I’ve made to JP/JPP is that you no longer need to have an SD card installed in your phone to use the program.  Since I first wrote Just Playlists, many phones have started to come with an “internal SD card”—that is, there is storage built into the phone that acts like an SD card and on which you can store music and playlists.  How this is implemented seems to differ between phones, and I’ve never worked with a phone that has such a storage space.   But if you do store music in this space, you can also create playlists there and play them via Just Playlists.

One other thing you may notice if you are running Android 2.2/Froyo on your phone.  I’m no longer hard-coding the SD card’s top-level directory in as “/sdcard.”  I’m letting Android tell the program what this directory is called.  Under 2.2, it’s called “/mnt/sdcard.”  There is still a “/sdcard” directory, but I believe it’s actually what is called a symbolic link in Unix parlance.  You can navigate to either location to access the SD card but, by default, you’ll be placed in the “/mnt/sdcard” location, since that is the mount point for the SD card file system, from what I can tell (more Unix talk there).