I hope this hasn't been requested before It's about the "jump to letter in albumlist function" which lacks a few functions I really would love to see implemented in this great jukebox software!

Is it possible to set a time variable or something so when I for instance write "cu" with a short time interval it will actually jump to the best fit, in my case cure, The. This is how it functions in explorer for instance. In my eyes it's more logical, than jumping first to "C" and then to "u".

Any reactions on this? Other ideas? Points of view? =)

-Fishy-

Agreed! Would be quite a helpful function... it does take some time anyway, before eJukebox reacts... a second or so... would be cool if it listened to the other keypresses while it was about to position itself.

It would also solve another problem! If a new user should either by mistake or by intention write for instance "cure" in the album list, eJukebox would take ages and use a lot of CPU power first jumping to c, then u, then r, etc...

With this proposal, this situation would not occur. And it's a great function! A very quick way of accessing your favourite artists. I know we allready have the search box, but this it a bit smoother.

Heh yep I use it all the time. It's sort of pain in the ass scrolling through the albumlist when you actually know what you're looking for. It does with ejukebox what hyperspace gates does to cosmos

...

Fishy

Heh... as i didn't know it was possible to perform this trick in more or less the rest of Windows, i am now using it all the time in file requesters and ordinary file listers. Thanks for the tip, and i hope we can see this function in eJukebox some time soon.

For some reason, it seems to take forever to jump to the position, the further down the alphabet the artist is. Going to "A" doesn't take that long, but skipping to "Z" takes close to forever... and it seems to be a very CPU-hungry process as well... does it have to be this way?

I think that is due to the album list which weigh down the navigation.
If i close the album list, i don't see any difference jumping to near or far letters.

Hm? Where are you jumping? I've never jumped outside the album list...

From your reply, i guess it's in the Artist List... perhaps you can do it in the song list as well. Anyhow, that's good ... but it's in the Album List i'd like to use the function the most. And preferrably the way Fishy suggests at the top of this thread. Yummy.

Yes, that was in the artist list...

And yes indeed, the Fishy suggestion is yummy!
I hope Audiosoft like the idea too, eh Audiosoft?

By Jove, i tried it in the artist list now... it's quite apparant, that if the Album List is open, it takes about 6 seconds for eJ to jump to an artist character, and it freezes during this whole period. If i close the album list, everything goes fast and smooth...

Unfortunately, i think that's the price to pay in order to see images in our worshipped album showcase...
...Unless Audiosoft could save us, in case Jove(?) couldn't...

Nah, that cannot be it... i can't imagine that it has to be that hard. There has to be another way. Yet i fear you might be right. Hmm...

But you have to admit that it's strange that if you enter the word "love" in the search field, for you get a complete songlist with albums covers and all, from your entire database... and yet this process takes half the time and CPU power than merely positioning the Album List to the right spot using the "jump to letter" function.

Well, i think eJukebox have 2 DIFFERENTS way working: using the songlist and using the album list (even if now things are mixed).
The songlist is simply the result of a search in the database. And as the database is devoted for this propose, that is very fast.
The album list is a sole long, so long... list that is heavy to handle and slow. In reality that is a very long web page - so, big in the memory because of all the images at the same time in the memory - in which you move, slowly...

That is my explanation of this strangeness!

I don't know if it's a plausible explination that the albumlist got a lot of images etc. Just have a look at different imageviewers out there which got these functions. The inbuilt viewer in directory opus or explorer for instance. It's lightening fast when the images are done loading. hmm.. of course there are differences in the way the albumlist and a imageviewer works. But I don't see any reason for this having to be a slow process when the albumlist is done loading.

Maybe audiosoft can give us some insight on this issue?

Yes, once it's done in memory, that should be fast! I don't know what eJukebox exactly do when it focus the album list in a different part?
Audiosoft?

Well, Pirk is on to a vital issue when i mentions the Album list is in reality a huge web page. Not only does it consist of all the image, but a lot of javascript code, making it a several megabytes large html file. And that is NOT counting the images.

I guess if they use a normal "find" function for a webpage, a <HREF> function or whatever it is called, it very natural that it should both take up to 6-7 second to find this position; as well as munch up your CPU in the process.

But i still hold on to my claim; there has to be another way. I freely admit, though; i don't know how.

I notice the time necessary to display a album in the album list just increase according to the letters:
A -> 1s
M -> 4s
Z -> 10s
It is like if eJukebox started to search from the beginning each time...

And yes you are right, there must be another way to obtain a better result.

Yes, indeed i do believe that is the case... since most search functions either lets you search upwards of downwards, and when you are about to enter any artist at all, it would make the most sense to start from the top (or from bottom up, for that matter).

But i am out of my league here, i do not know what kind of search function Audiosoft uses to get the results, and i might be wrong in comparing with a standard search in a huge web page. But, on the other hand... things sure seem to be pointing in that general direction.

I trust Audiosoft to improve things.

Z -> 10s ????
Really?

We have 550 albums in our test setup (p4 2.1, 512MB) and it takes 1 sec to jump to Z in the album list.

The function we use for jumping is pretty fast provided the system has enough RAM to support the album list. Otherwise the hard drive will need to be used for virtual memory...which slows things down.

hmm according to my system monitors I have about 80-90 mb of free physical ram available when running ejukebox (of 384 total). Don't know if this is enought ram for this process to be fast, but I have the same experiences as junk. The time for the "jump to letter" function to complete correlates positivly with the span from a-z

Hmm...I guess it does have more to do with CPU.

How many albums do you have in your list and how long does it take to jump to Z?

Also what is your CPU speed? Thanks.

I am running on a fairly slow system. 1ghz athlon thunderbird is my cpu. Geforce 4 ti gfx adapter. 1075 albums in my albumlist at the moment. About 20 seconds jumping to Z. I choose not to use this function because of this. Sad thing though, since I like navigating that way.

Do you think it's possible to speed up the process in any way?

if ram is the issue, then the priority should be cutting down the amount of ram that eJukebox is using normally (with the album list open) - i know it is much bigger for those who have images already in their files - but quite simply 160MB of ram usage is just a bit much.

not trying to complain - just saying that the big issues such as this (and the not altering of file tags) should be the first to be tackled.

CPU is the foremost cause of the slow jump speed not RAM....

Hiding the album text from the album list options panel, may increase the speed of the letter jump and reduce memory.

You are right, the Album consumes allot of RAM because all the images remain loaded for smooth scrolling. Thus, the only way to substantially reduce the RAM usage would be to make the album list only display a couple albums at a time and use < > page buttons...the problem with this is you would no longer be able to scroll the album list.

v3.6, Updated the Artist List to make it more functional. If you have more than 300 albums with a slow CPU or less than 128MB RAM, you may want to close the Album List and use the Artist List in EDV [ ]> mode for a faster browsing experience.

Glad you're improving the artist list! So there's no way around this problem? For me; it isn't the slowness of the CPU, both my CPU and RAM is quite fast and up-to-date. I believe it is more the amount of albums, i had close to 1500 albums in my album list the last time i checked. And i do not want it any other way; i would hate to be inhibited by having to flip to the next album page (allthough it would be a good function for touchscreen users, i've realised).

But i could live with the slowness a lot more if we got the fishy suggestion (if eJukebox listened a bit longer to see if we typed in more than just one letter, and perhaps the whole bandname, or a part of it.)

thanks for clearing the details up audiosoft - while a page to page feature for the albumlist would be cool for those with slower computers, i'm still a fan of the one big list - so if it came down to it, i'd rather sacrifice the RAM cause it just looks so darn cool in one big list Not that a toggle for the page to page feature would hurt...

hmm... An alternative sollution could be if the albumlist didn't move when I enter a letter in the artistlist. Then one could have the albumlist up and running, while navigating for artists in the artistlist by keyboard strokes.

I think it takes a great poll on CPU when bought jumping down the artistlist and in paralell to the appropiate destination in the albumlist. An "not jump to destination in the albumlist" option could make this a lot faster.

But the better sollution would be making the albumlist search overall faster, if possible of course.

You can already speed up your search in 3.6 if you close the albumlist. Then, as now in fact it always remain loaded in memory, when you re-open it there won't be any delay. It's the lesser of two evils waiting for a real solution...

The "real" solution seems to be closing in;
http://www.audiosoft.net/forums/viewthread.php?tid=544&page=#pid2555