Work has started on a new version of JukeBx and the first Beta is ready. No major changes are planned, we just want to update it with some of the newer features that we have been adding to other programs. The biggest differences at the moment are some improved message boxes, but other changes, such as sorting, have been added as well. We hope to add a HTTP remote, similar to the one in Egg 1.56, but it does depend on time. EDIT: This'll be next version.

There is no planned release date, and you can download the beta from here.

We're back working on JukeBx; it's been too long between versions! Delays have been caused by the need to test some of the advanced new functions. In particular, the Network function has been enhanced so the entire list of songs can be buffered locally. This feature came in handy during our recent move as I was able to build a list of 1000 songs on my netbook and not need our file server! Also, we've added a feature that lets you have up to 10 profiles and playlists stored. At the moment both features work, but are not very user-friendly.

Once these features have been finished more we'll release a new Beta, and then start work on a few small requested features. We hope to have JukeBx 1.4 finally released by mid-to-late December.

This version adds an auto shutdown function. The idea is that if you use JukeBx on a computer set to auto-play, you can just press "P", which will pause, build a new list, and then shutdown the computer.

Please note that if you've been using the Beta this feature will probably be on by default. It can be easily aborted and disabled via the Options window.

It's been a long time, but at last there is a new Beta. For the most part, the delays were caused by the addition of the AutoRate function. (Let this be a lesson of the dangers of last minute feature additions!) In short, adding the simple feature necessitated writing a cached database update function, which needed a file hashing (fingerprinting) function. The first was semi hard to add, the second was a bit easier... but integrating them both into the program in a way that didn't cause problems was tricky. In the end the solution was to re-design the entire internal timing of JukeBx (which needed a revision anyway) and that caused the rest of the delays.

As a result this version is substantially better than planned! If testing goes well this will be released in a week or two. As a reminder, JukeBx Betas are found here.

muzzy wrote:I have tried this beta but can't get it to import the music... It says "Import Complete" but nothing is added to db.

May be this part is not implemented in this version?

Possibly. With Beta's the main functions are dealt with first, then the peripheral. The import function is for the most part stand alone so any problems would be easy to fix. There have been a lot of internal changes with this version so it isn't surprising that a few functions are broken along the way.

At this stage there are four known problems with this Beta;

1. It doesn't like it when the computer sleeps. (Now fixed!)2. The State Change function doesn't work.3. When searching the "details" function shows the wrong song.4. Import doesn't work. (Untested.)

All four should be fixed in under 24 hours... and then it's time to look for more problems! Thanks for the report.

muzzy wrote:For example: When i tried to import my music folder (containing ~6000 songs) it crushed each 600 tracks.

That I have noticed! While testing a fresh install it kept failing during import.

muzzy wrote:Also i didn't noticed any rates changes with AutoRate switched on. Could you please describe what rules are implemented in this version?

I think there were some issues with this version that affected AutoRate. (That is AutoRate wasn't the problem.) But the way it is supposed to work is up rate on complete play, down rate on skip. The amount that changes depends on the AR Speed setting;

Slow 1/8 Rating valueNormal 1/4 Rating valueFast 1/2 Rating value

(I use normal.) Remember that the changed value is the hidden value, not the Visible Rating. Thus when set to normal using the default rating values songs will go down after two backs, and up after 4 plays.

That is, if the song has a Visible Rating of 6 its Rating Value would be 64. 1/4 of 64 is 16, so when skipped it goes down to 48, which equates to a Visible Rating of 5. Next time it's skipped it looses 12 making it 36, leaving the Visible Rating as 5. But on the next skip it looses 9, becomes 25 and thus has a Visible Rating of 4.

Going the other way and starting again with a Visible Rating of 6, adding 16 to 64 makes the Rating Value become 80, which still equates to a Visible Rating of 6. Next time it plays it gains 20 making it 100, leaving the Visible Rating still at 6. Then on the next play it gains 25, becomes 125 and thus still has a rating of 6. However on the next pass it goes to 156 giving it a Visible Rating of 7.

How this works long term is hard to be sure about, but remember that if it's too slow or too fast it can be changed.

I'm fairly sure the Beta I'm testing has a working AutoRate so I'll upload that in a few hours.

It's important to realise why I'm calling the two numbers Visible Rating and Rating Value.

Visible Rating: This is the rating that is shown in most windows, and is the number that is worked back from when setting ratings.Rating Value: The real rating. This is the number that's used when picking songs, and that's the whole point of it all.

As important as the Rating Value: is, it is still overwritten whenever the Visible Rating is changed, which will reduce its value if it isn't exactly at one of the divisions. Thus if you edit a songs data it can affect the performance of the AutoRate function. In most cases this isn't an issue, but it's still important to know.

muzzy wrote:I think that incorrect ratings(number of boxes) are shown in the top of window

Yes, you're right; good spotting. I noticed that soon after it was uploaded and that change has been well tested now. What was happening was the rating data was being processed wrong (it was being double converted down and thus the Visible Rating was lower than it was supposed to be) and this was causing the AutoRate to not work. Why?

Well as I said earlier, to avoid DB hogging (not a problem in your case, but a big issue when the DB is shared among several computers) a new DB Caching function was written. This allows (at the moment) up to 100 DB changes to be stored and then processed in one go. Writing this was important to the long term plans of JukeBx so this was a good excuse to do it now. When an DB change is cached four things are stored; the DB record, the previous data, the new data, and as a piece of extra safety an "unique" ID mark. In this case it's the new piece of data that's labelled as "ID". This is a hash made via a custom derivative of the Fletcher's checksum that is based on the music file itself. (There are more plans for this ID in latter versions.) These 4 pieces are stored and when it's time to write the cached data they need to match. If they don't the change is abandoned to avoid changing the wrong record (if the DB was re-ordered) or overwriting another edit.

Now in this case the previous data was stored wrong so it didn't match. This has now been fixed and the AutoRate has been working for me. It'll take a few months until I can say if I like it or not!

I've just uploaded a new beta. It's not as tested as I would like, but JukeBx is a complicated program that's hard to completely test. Known problems are the import routine and some video viewing issues.

(Video viewing, being a secondary role, might not be fixed to perfection prior to release. We're planning on re-writing the whole playing routine in a few months so it would be a lot of work for little reason...)

muzzy wrote:But after i restarted JukeBx produces heavy cpu load and it is not building the playlist...

Is it normal?

No. Substantial tests have been done to avoid that very issue. It's possible that the DB is corrupted.

Do you use any features such as "Minimum Play Rating" or the Offensive filter?Does JukeBx say that it's "Hashing" in the Status Bar?If you can replicate this go to Database->Advanced->JukeBx Internals and see what Waiting says. That should tell me what section is causing the problem.

Siegfried wrote:No. Substantial tests have been done to avoid that very issue. It's possible that the DB is corrupted.

Do you use any features such as "Minimum Play Rating" or the Offensive filter?Does JukeBx say that it's "Hashing" in the Status Bar?If you can replicate this go to Database->Advanced->JukeBx Internals and see what Waiting says. That should tell me what section is causing the problem.

I think that this problem is caused by DB corrupted during import crashes. After some testing i have 8 DBs and some of them works fine while others caused various problems including heavy cpu load and no-building-playlist condition.

Siegfried wrote:Do you use any features such as "Minimum Play Rating" or the Offensive filter?Does JukeBx say that it's "Hashing" in the Status Bar?If you can replicate this go to Database->Advanced->JukeBx Internals and see what Waiting says. That should tell me what section is causing the problem.

Minimum play rating is set to 0I did not find "Offensive filter" setting so i think it is set to default value.The Status Bar says(pls see screenshot): JukeBx Building - 1 songs prepared - 5479 entries - User MuzzyWaiting says: 0, 0, 34 Doing34As you can see JukeBx loads 38% of CPU (i.e. 76% of 1 of 2 cores)

muzzy wrote:As you are working on new release of JukeBx I think it is a good time to add one more feature: support of lossless audio formats APE and FLAC.

With increased storage sizes many people prefer to listen to the music in lossless formats.

The next version will have a re-designed player that might support those types. As part of the re-designs of v1.4 the player has been isolated from the interface to prevent playing related lockups and that also makes it easier to make more changes.

But no major features will be added to this version. The priority at this stage is releasing it...