For Double Albums, Bliss will sometimes fail to find a matching cover for Disc 2. You may have chosen a particular cover for Disc 1 and then find that the only covers available for Disc 2 do not match. This could be fixed if one of your options for choosing Cover Art was from your existing collection of covers - especially if it was shown in "Most Recently Added" order - you could choose the same cover as you chose for Disc 1 with a couple of clicks. At the moment, my only option is to separately upload cover.jog from the Disc 1 directory - which is fine but not as easy as it could be.

I believe this idea will fundamentally improve the usability of bliss. I purchased bliss in hope it would save me huge amount of time w/ managing a music collection of (5000+ albums and growing...) However, I found bliss saved me some time, but not that much!

What I realize is while bliss' idea and its features are great, the productivity issue is in the UI workflow design.

Bliss automatically scans library in the background, but most fix actions are designed to be done interactive(in real time). I found I choose the non-compliant album and click on fix, and then *WAIT* for bliss to complete the action....before I can move on to the next album.

My time is mostly wasted waiting for bliss to complete an action. (frankly, bliss is not that fast in performing a lot of actions)... Often this fix action is also happen simultaneously with bliss scanning the library in the background, which making it even slower.

Also for an attempt to automate some of the feature to avoid excessive repetitive steps. Automatic option features are introduce for some of the fixes. The problems with automatic fix is not sure if every fix to be performed is done correctly. I always afraid bliss making a wrong decision on a special case, or the online database information is incorrect. that happens! Some people asked to have a log of what action bliss has taken, i think that to some extend is reflecting the same problem.

The idea is allow Bliss to support the concept of fix queue. Basically an asynchronous queue detach users action and actual job. Allow user extremely fast to browse and making decisions. Then bliss can take its time to execute (sequentially or in parallel depends on action type) completes and logs action. If further result is needed (ie. pick a albrum art). It can remember the result, and have user come back to make a quick selection, requeue the album updating task as another task to be performed in the background.)

So,

Scan library for fixes -> present fixes -> user selection -> actual fix --> [loop to present fixes .....]

are much better work flow then current real time fix.

I hope to save all bliss user a significant amount of time and making bliss a much more useful tools for the world :)

i like to name my files with as little info as possible, but as much info as necessary in order to be able to clearly allocate the correct artist, album and track:

<artist> - <album> - <discnumber:nn if greater than 1><tracknumber:nn> - <songtitle>

example for a single disc album song:

Jim Morrison - An American Prayer - 02 - Ghost Song.mp3

example for a multi-disc album song:

Booker T. & The MG's - Time Is Tight - 0208 - Johnny, I Love You.mp3

i suggest to be able to conditionally use tags in the filename such as "IF discnumber > 1 USE <discnumber:nn>"

This is a feature that I did not think would be needed, but with the latest version being released I was not able to see the update from the web UI until bliss was restarted. Since I run bliss on CentOS, there is no provided init scripts and the one I have created only starts bliss so the easiest and quickest way for me to reboot bliss is to bounce my server (which also serves media via SubSonic).

The update process restarts bliss at the end so I assume the code for a restart is already written and could easily be incorporated into the UI.