Audiosoft, not sure what's up, looking into it more, I'm in the process of moving my files. When I'm in the middle of updating the library EJ crashes all the way out to no longer running.

If it crashes again: open up Crogram FileseJukeboxdb.m3u in notepad and check the last 2 files listed. Make sure they are not corrupt or incomplete file downloads.

Quote:

Originally posted by Audiosoft If it crashes again: open up Crogram FileseJukeboxdb.m3u in notepad and check the last 2 files listed. Make sure they are not corrupt or incomplete file downloads.

i doubt it is a bug because I just rebuilt a database with 9000 songs using v4.61 and had no problems.

what happens? does ejukebox just disappear? do you get an error message? if it is a problem with a particular files it would be the file that comes after the last line in db.m3u.

Well.. for my part, I've tried to rebuild 2 folders with eJ 4.61 after I removed some unwanted "asn" tags using an external editor (Godfather).
The first folder (547 albums in it) reloaded good, very slowly but good! The second one is a big one: more than 25000 files in it: It started to reload slowly until +/- 6500 files.. but I was obliged to close the eJukebox rebuild box, because my PC was almost 100% paralysed by this process (only the mouse is not paralysed). I think the problem is the RAM memory of my PC (1024 Mo) becomes completely saturated during the loading of song datas (some songs, the first song of each album in particular, are very long to load - all my "old" albums include id3 images.. It seems the image loading process is very slow), while the processor is not used a lot! So during the database rebuild my PC is totally unusable, and the update is so slow than I can't reload a big folder until the end: 24H was insufficient! For the big folder, it only loaded 7000 files during a day..

Audiosoft, I don't know if my PC is in question or eJukebox??

Thanks.

Is the Bob Segar song it crashes on a wma or mp3?

Sadely as I restarted eJukebox since my yesterday folders rebuilding attempt, after a long eJukebox starting delay (PC 100% paralysed..), my database just rised back to 7255 songs, from more than 40000 files before the update...

It looks like our issues are related.... on one part it makes me feel better that it's not just me.... Makes it easier to go through everything.


40,000 Are you kidding me?! Woa! and I thought I had a lot of music, with a very extensive collection. I can't even fathom how many gigs that takes up. I was looking over my library this go-around and noticed that my library takes 49 Gb now, which in itself is decent LOL

jojo

Yeah man, 40000! I can give you a trick: if you want eJukebox manages that much songs, you must go through all your songs with a fine-tooth comb BEFORE to import them in eJ. My 40,000 songs/tags are totally clean, and eJukebox works perfectly good with them. The bad idea was to try to remove some unwanted eJukebox popularity tags using a external editor.. Otherwise all is fine!

Quote:

Originally posted by Pirk Yeah man, 40000! I can give you a trick: if you want eJukebox manages that much songs, you must go through all your songs with a fine-tooth comb BEFORE to import them in eJ. My 40,000 songs/tags are totally clean, and eJukebox works perfectly good with them. The bad idea was to try to remove some unwanted eJukebox popularity tags using a external editor.. Otherwise all is fine!

OK jojo, I think you are on the right way: Perfect tags will save you many -even all- future problems in eJukebox.. The thing is to start!
As far as I'm concerned I like to play with fire..


Audiosoft,

That would be great if eJukebox was able to manage its own "asn" tags using the song editor: Reset popularity or rating tags for a song, or a complete album. Even maybe the AutoList Builder could be used to select a targeted group of songs.. All the changes would be saved in the song files, of course! Not only in the database.. In anticipation of any future database rebuild!

Yeah tag&rename is very handy.. There is also a new tag editor, well new at least for me: "The Godfather". It's a freeware but it seems quite good.
Good luck with your songs and eJukebox!

Maybe you guys should try turning off antivirus when building a large database since antivirus tends to hog the harddrive and slow things down.

Also, if you do find that an audio file is causing the crash please attach it to a post so I can try to get eJukebox to work with it.

Thanks for your advise Audiosoft, since I've turned off my antivirus the database rebuilding doesn't freeze my system. My PC still slow down but it is not frozen. And the eJukebox database updater continue to make its valorous job in the background while I write this message! That was not the case with the antivirus turned on..

Suggestion: It's a Tip -"Turn off your antivirus during a big database update, to speed-up the process"- that would deserve to be displayed somewhere in the eJukebox database updater dialogues! Because I already knew that, but I forgot it..

Aside Question: Your forums was inaccessible for me since my last posts: Is it you Audiosoft who blocked me?? or the CIA?

Audiosoft, is there a tool I can use to find out why my tracks fail to import (Crash EJ) I did some tag work and renaming and moving files, but now I'm getting the crash on tracks that worked before.

I'm moving files to:

C:MediaMusic%artist%Album%TR#-%artist-%tittle.xxx

xxx=file type wma, mp3 etc.

Of course all this, I've not even had a chance to get to the tracks that come in as artist "0" <sigh> Is there some way that EJ can report the problem, or have some kind of ability to continue importing other files and reporting problem tracks.

I'm open to ideas here.

Well, it seems we are both in the misery..

Audiosoft, in my last post I said things become better for me, but unfortunately that was only temporary: The database update worked good from 0 to about 25400 files, but it suddenly deteriorates with no apparent reason! The update became very slow again for the first song of each album (id3 image..), and my PC was again 99% paralized, even if the database update continue slowly.. I can write this post because it has just finished from 25400 to 29314 files imported.. So it took all the afternoon for only 3914 supplementary files imported! And I've not finished.. but I hesitate to start another importation.
I'm quite sure that my problems are related to the virtual RAM memory management, which becomes very slow -and freeze all my system- at some point during the database update process. Strange!? It seems the antivirus is not the unique responsible..

I'm also open to ideas!

Pirk,

Interesting you mention virtual ram. Tell you what...I will post an 4.62 ejukebox.exe that always runs the database update 'in ram' so you can see if it is faster/more stable that way. I am also going to make it so the db.m3u's last file will always be the last song that was attempted to be tag read/added to the database. That way if there is a problem eJukebox will skip over it when you add new files.

As far as 99% CPU - the only known issue that can cause this is incompleted music file downloads...particularly incomplete torrent downloads. Also I discovered eJukebox was attempting to read in ID3 tags on non mp3/mpc files which was slowing it down a little. That has also been fixed so non mp3/mpc will be added faster.

Also, when the database update freezes or fails you should then just go in and "Add new files"...instead of rebuilding the whole thing again. If you do "add new files" eJukebox should pickup where it left off.

v4.62 is now available for download from the forum under Latest Updates.

Link to 4.62 Download

Thanks a lot Audiosoft! I will try that this afternoon, now I go to eat.

Well.. I've just tried to add some files to the database using ej 4.62, but things are not better for me. My system is a bit less freezed during the update process, but it is still extremely slow... The importation of the first song of each album is even more slow than with 4.61: more than 2 minutes with 4.61, about 3 min 20s... with 4.62) So it still takes ages to import new albums! Maybe should I remove all the id3 images of my albums?
I managed to take a screenshot during the database update.. Audiosoft, do you think that all these material faults on the resource monitor are normals??

Hey Pirk,

I have had the same problem since around 4.2, but I just put it down to my PC as it only had 384MB ram in it. 2gh pentium4

When I last re-built the database (about 2 months ago roughly) it took almost 48 hours to add 27,000 songs. The PC its installed on is standalone and does not access the web at all. It has no firewall, anti virus or anything else running, in fact I have even stopped all non essential services from running at startup, but still it took 2 full days to re-build.

I am ok for now as it has been pretty stable for a while, but I fear for it happening again! Other than that I love EJ!

Hi Well_Jaggy,

48 hours for 27,000 songs? If you have only 384MB ram maybe it's "normal" it took a long time, I don't know..
In my case I haved not made a full rebuild since a very long time... I can't remember if even I haved not copied my database from XP to Vista! Only as these last days I've removed a lot of unwanted Audiosoft popularity tags in my mp3s using a external editor, now I need to rebuild otherwise eJukebox will re-write its old "asn" datas in my files..
OK, so what is very strange for me is eJukebox has imported more than 25,000 files in a morning, then suddenly (and sadely..) the scanning process performance fallen down with no apparent reason!
The only thing I've changed these last days is when Audiosoft put a version of eJukebox that requested a online registration, 4.59 I think. Then before he posts a fixed version I haved reinstalled a quite old version.. Once he posted the fixed version 4.60, I've made a full install over the old version, but maybe I breaked something in the eJukebox install?? That's crazy!

Pirk,

Do you have enough free hard-drive space for the 'Temporary Internet Files' IE7 folder? I will do my best to get the database update to import mp3s with the id3 embedded images faster. Also I am going to remove the run in ram from the database update for the next version since that doesn't seem to be helping when you don't have allot of ram. I will also look into the memory faults.

Audiosoft, thanks for your help..

I've just tried to move the temporary internet folder on another disk on which there is more free space, there was only 9Gb free on the system disk, but the database update is not faster than before.. I've also increased the temporary internet folder to the maximum size, I don't know if that can help.. And I haved already tried to delete the temporary internet files.

Do you think that would help if I try to remove the id3 images? The cover.jpg image importation will be faster than embedded images??
EDIT: I've tried to import a album without id3 image, cover.jpg only.. but it seems that's not faster!!! Also probably that often I use too large images..

Memory faults: I've read on the web that it's not real "faults", but just when windows can't find datas in RAM then it counts "a fault", and it takes datas from the disk instead..

Thanks.

PS: In my previous posts I said the first 25,000 files was added quite fast. Now I'm thinking that even if the Homepage displayed 7500 songs remaining in the database after the "initial" crash, maybe many images have been recovered (from where?) during the first rebuild? That would explain why the 25,000 first files were faster to add than the following...

PS #2: I'm also thinking that 1024Mb it's not that much for Vista!! As the system monopolizes 600Mb.. it only remains 424Mb for eJukebox!
So I'll try to add more RAM. How much RAM can manage Vista 32 bits? 2Gb, 4Gb?

Hi Audiosoft,

Well, it 4.62 is faster, as promised however it's not doing what we were hoping it would, as far as keep going when a track fails to inport. It seems that there are some stability issues when inporting still.

I've not been able to get a successful library add. It crashes on both WMA and MP3 It seems to crash on tracks that were accepted last night.

I did attempt a re-build since I've been moving and renaming the tracks.

I'm open to ideas, I'd love to help get this fixed up. Below is most recent crashing song

Audiosoft,

Could you make so eJukebox doesn't paralize the system during the database updates? The processor is not used a lot but even so it's almost impossible to use the PC during a update, in fact each time it loads a image all the RAM is used and the system freezes (see my screenshot).. I think it's not normal: the database update can be slow without it necessary freezes the system, no?

Thanks.

4.63 makes the database import faster on songs with an id3 embedded image/cover/folder.jpg image.
Give it a try and let me know how it performs.

Download 4.63

Audiosoft,

Once more you rooted me to the spot: 4.63 works at the speed of a rocket!!
But how can you make it goes from extremely slow to so fast?? Are you sure that 4.63 has still enough time to import images, at this boosted speed? What is your secret?!

Well, now I'm got over this new version -My database is now up to date! It imported the last 1800 files so quickly..- I can say a little thing: At the very beginning of the database update, my system was 99,9% freezed during maybe 2 minutes, but then the booster taked up his post and it imported the remaining files in less than.. time to say it!

Thanks a lot for this efficient update Audiosoft! I think I'll save some money on RAM.. although prices have fallen much.

Audiosoft,

That's right, with 4.63 I noticed that each time I import a new group of albums, the update process first scan the folders very fast (like before), then as it seems to import the first song my system freezes during maybe 1 or 2 minutes.. But since this version all the following songs and albums are added torrentially and during the database update my system is not freezed at all! So the version 4.63 is already a hell of a progress..

Thanks.

Pirk,

wow! so it went from 48 hours for 27,000 to only 2 hours for 40,500 with v4.63...very impressive!! The reason is is so much faster is because eJukebox now turns the images into jpg on the fly instead writing a bmp to the drive first. Also it previously filled a recordset with all the image data in the database every time a new cover was imported....now it only does that one time at the beginning of the update process.

Audiosoft,

OK, thanks for your explanations. 48 hours for 27,000: Well it's not me.. In my case that was to slow, but furthermore, the database update was also very erratic because of the system freezing.. phew! In any case, you made a nice piece of coding.. Bravo!

Just a crazy dream which goes through my mind: If ever you could boost the ALBUMLIST construction in the same way!

Thanks again.