Do you think you will add some of these features in a future version of eJukebox? That's planned i think, but i am not sure?

1) The image for the next song in the playlist when in 1024x768.

2) The second column (or more) for the genre list when there are more than 20 genres.

3) WHEN the Album list is MAXIMIZED, i expected it remain maximized and focused on artist names as long as you click names in the artist list. Then mixed with the song list when you click directly a link inside the album list.
What is the problem with that one? I think that could be really cool!

Thanks.

1 and 2 are in the works....

Not sure about 3 because it seems that jumping to an artist in the albumlist takes a long time on some peoples computers.

Hm.... i see that #3 is closely related to the "jump to artist" thread:
http://www.audiosoft.net/forums/viewthread.php?tid=476

Unless another way of jumping to artists is developed, i am sure that none of us wants to experience 5-10 seconds of eJukebox freezing until it's found the right artist position.

Audiosoft,
Thank you for your reply.

Concerning the album list:
Yes, i'm also in that case, jumping too slow...
However i'm glad that not be the case one YOUR system! Because at least the day i'll buy a new computer i know that will works better than actually.

Unfortunately, it seems there are also some people having a RECENT computer with a fast CPU for which it's even so too slow. Strange...

Don't you think these people could have something different than you in their database? The only thing i can guess would be maybe a lot of - if not all - their images initially coming from mp3 tags, since i am in that case too.
I think mp3 images are still less compressed for the display than these looked up. So that can seriousely deteriorate performances, no?
Tell me if i'm wrong.

I really hope it will be possible to improve jumping to artists in the album list.


Junk,
Yes, these topics are close since both concern jumping in the Albumlist...
So i think any improvement here could be very beneficial to the eJukebox smoothness.

Thanks.

Fishy,
Thanks for your support.

Personnaly i don't use anymore Tag&rename so systematically, since quite a long time now.
Often when i get some albums in mp3 on the web. I first fix file names and tags directly into Windows (XP) or helped by a shell extension, and i add all the ID3 images using the build-in editor after i have imported my songs in eJukebox.
I don't know if the way can change something. Normally that shouldn't influence, but i don't know... if ever a bug slip somewhere.

On the other hand i know there are still some differences concerning the compression by eJukebox - in the database and for the display - between looked up and id3 images.
Like you say, that can disadvantage users like us...

Or else maybe it's an HTML issue?

hmm well, I hope audiosoft has a plan =)

I think you're mistaking if you think that it's the images that are causing the delay. Allthough i admit that i am no expert on this issue, i believe the reason for the CPU taking ages to jump to the artist must be because the html file it searches in is so huge. The images are all referred to as "xxxxx.bmp" from the eJ database, no matter if they are encoded in the id3 tags or not.

The reason the html file is so huge, i guess is mainly because of the amount of javascript code that is needed to make the album list operate the way it should.

The only thing that i could imagine that would help the situation (but keep in mind that i am no programmer), would be if for instance eJ made a small file with the absolute positions of each artist when it generated the album list. Then when you enter a letter (or artist name), or even click on an artist, eJ would look up in this file for the position, and not give a rat's ass about searching through the album list code (which would normally be somewhere between 1 and 2 megabytes in size).

junk, Good idea...
While it can't be done exactly like you suggest...you gave us a good idea.

We may be able to cache the positions (album #) of the first album by each artist letter, when the list is created. This way eJukebox won't need to start from the top of the list and test each album until it finds the one with a matching first artist letter....instead it will know which album that is right away. If it is an artist name jump, instead of a letter jump, it will test each album for the first matching artist starting from the cached position of the album with matching artist first letter - rather that testing for this match starting from the top of the list. This should make the album list jump faster and be less processor intensive.

Hehe, great to hear! Good to hear my tehnical ramblings can be inspiring, no matter how off-track they are. I'm looking forward to this!

Oh yes! Today the posts are very promising... thanks to your perspicacity Junk!
At least our rambling discussions in the forums are not vain... That's great to contribute to the eJukebox life!

I remember that one day you wanted to give a "small organ" for eJukebox...
Today, it's like if you haved do it! I just hope the transplant take good...

This sounds great! Nice rambling junk

Quote:

Originally posted by Fishy Are there anyone in the forum that use external tools (like tag&rename) to grab cover images? And actually get the "jump to artist" function to work "at the speed of light"?

This is a old thread. Which discussed a problem, which is of the past now Earlier the albumlist was terrible slow when jumping in large collections, but now it's very fast indeed..

hm, how many albums do you have? you ought to have at least 50 000 mp3's to justify an .asn file over 120 mb, if i remember correctly.

Also, the .asn file will always be larger on Win98 because only Win2K and WinXP are able to compact the database when you shutdown eJukebox.