Presenting jAlbum 20

18 years have passed since we first released jAlbum 1.0. We've now reached v20. Not that many software titles stay around for so many years so we're proud that jAlbum is still relevant, and now it's better than ever. There are about a dozen changes in this release, but here I'll focus on the top 3.

1. The details view

jAlbum's Explore mode now offers a new configurable "Details" view alongside the "File name", "Title", "Comment" and "Keywords" views.

This mode will be very helpful when dealing with a lot of metadata: You can now view and edit the aspects that matters to you at the same time while maintaining the overview that jAlbum's Explorer brings. A quick double click on the "Details" button will bring up the configurator in Preferences. Here you just drag and drop metadata aspects to your liking.

The offered aspects are Added date, Camera date, Comment, Creator, Copyright, Copyright URL, Dimensions, File name, Keywords, Modified date, Title and Size (some are read+write and some are read-only). This configurator along with jAlbum's zoom slider allows you to pick the best balance between overview and details that suits your needs.

2. Group by Creator 

Album has a powerful file organizer, somewhat shadowed by its main role - to produce web galleries. The organizer has previously been capable of grouping files in folders based on camera date, GPS location, file name and keywords. It can also delete duplicates in the process. jAlbum 20 now adds the ability to group files by creator too, perfect for photo clubs and schools managing work from several authors.

3. New upload engine

If you've been facing upload difficulties, this change will probably be the most welcome. jAlbum 20 is fitted with a completely rewritten ftp upload engine that's designed to handle shaky network conditions better than before, and be faster too. Without getting technical about it, that's all you need to know, but for those of you who'd like to know what's been changed, here's the story:

Sidenote: This all relates to ftp, ftps and ftpes uploads, it does not affect uploads to jalbum.net where we use a special single connection transfer technique called "zipstreaming".

jAlbum's uploader, like any ftp transfer software utilize multiple simultaneous connections. This speeds up transfers significantly as a large portion of the per-connection time goes to negotiating information about each file transfer with the ftp server. jAlbum's existing upload engine has a pool of "worker threads" each grabbing files for processing from a common work queue. Each worker maintains a dedicated ftp connection for the file transfer operation:

One folder is completely processed before proceeding with the next folder. On stable networks, the only downside with this approach is that some threads are idling by the end of each processed folder, waiting for the last transfers to finish. In the real world however, many networks aren't fully stable. There are timeouts, packet losses and a host of issues with various ftp servers. Here's where troubles arise: When IO errors occur, the affected upload worker thread will try to reestablish a new ftp connection and retry the transfer. This does however not always work due to per-user connection limitations usually set up by those who administer the ftp server, so that file is put on a special error queue for processing by some other worker thread by the end of the upload instead. Finally jAlbum tries to write a manifest over all files processed. This is done to speed up future updates to an existing album, but sometimes fails when the dedicated connection used had troubles.

With jAlbum 20's new upload engine, the ftp connections have been decoupled from the upload worker threads, meaning that any worker thread can utilize any free connection from an active connection pool:

This gives us several advantages: On error, reattempted uploads can be performed by any free connection, and the connection pool can reestablish new connections while serving existing connections to the workers. More robust, and less time waiting for negotiation. The manifest file and folder creation is also handled over any free connection instead of on a dedicated connection. Again, more robust. Finally, the new uploader doesn't wait for one folder to be completely processed before continuing with the next folder, so we make max use of all available connections at all time.