Pages: 1 2 |
jojo
Member
Posts: 101
Registered: 9-25-2003
Location: Florence, Oregon
Member Is Offline
|
posted on 5-18-2007 at 09:49 PM
|
|
|
moderate news
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
|
posted on 5-19-2007 at 02:29 AM
|
|
|
Quote: |
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??
|
Yeah no point in doing that since cover.jpg and id3 embedded images get added to the database the same way. Extremely large images will take longer.
eJukebox used to add them as JPG to the database with 90% quality. I changed it to 100% quality with 4.60 so that there will be no loss of quality.
The only thing is this makes the size of the jpg's in the database larger and slower to add. Maybe I should change it back to 90% quality. What do
you think?
jojo,
With v4.62 the last line in the db.m3u will be the last file attempted to be added to the database. So check that file if it locks up again and post
the file here so I can test with it.
Audiosoft
|
|
jojo
Member
Posts: 101
Registered: 9-25-2003
Location: Florence, Oregon
Member Is Offline
|
posted on 5-19-2007 at 06:47 AM
|
|
|
Quote: | Originally posted by Audiosoft
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. |
Thanks, Audiosoft.... for the continuing help on this issue. I've had so many crashes it's hard figure what it is, There doesn't seem to be any
pattern, it even crashes on songs it accepted earlier.
Edit: I was sitting here, thinking of the disk space issue. The HTPC has plenty of drive available...(off topic a bit, but not) My own PC has been
giving me "drive is full" I run the disk cleanup, it gives me some... but almost nothing... Then I reboot and I have 50 GB avail ???! I've never
seen this happen before. This is on XP Home with 1.25 GB
|
|
jojo
Member
Posts: 101
Registered: 9-25-2003
Location: Florence, Oregon
Member Is Offline
|
posted on 5-19-2007 at 06:54 AM
|
|
|
Quote: | Originally posted by Audiosoft
Quote: |
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??
|
Yeah no point in doing that since cover.jpg and id3 embedded images get added to the database the same way. Extremely large images will take longer.
eJukebox used to add them as JPG to the database with 90% quality. I changed it to 100% quality with 4.60 so that there will be no loss of quality.
The only thing is this makes the size of the jpg's in the database larger and slower to add. Maybe I should change it back to 90% quality. What do
you think?
jojo,
With v4.62 the last line in the db.m3u will be the last file attempted to be added to the database. So check that file if it locks up again and post
the file here so I can test with it. |
I was thinking the images looked really sharp in the current versions, I guess I attributed that to re-doing all tags and renaming.
As for the crashes, I'ts been bad... Really bad today I pretty much just
pulled each album that gave me trouble. I'll re-rip them to MP3 next week, or when I get a chance. There have been many times I'd only get a
partial name (Path only) not the actual file that failed.... So that hasn't been so helpful, other than giving me the album.
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-19-2007 at 10:23 AM
|
|
|
Quote: | Message original : Audiosoft
Extremely large images will take longer. eJukebox used to add them as JPG to the database with 90% quality. I changed it to 100% quality with 4.60 so
that there will be no loss of quality. The only thing is this makes the size of the jpg's in the database larger and slower to add. Maybe I should
change it back to 90% quality. What do you think? |
I would prefer you keep 100% QUALITY! Even if it's slower to import the images, eJukebox will look better! I will try to boost my PC adding more RAM..
Thanks.
Pirk
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-19-2007 at 10:33 AM
|
|
|
Quote: | Message original : jojo
I was thinking the images looked really sharp in the current versions... |
Same here! I noticed my skin looks better, in particular the songlist.. I was thinking Audiosoft has improved the transparency!!
Otherwise concerning your problems, just a idea if you use Tag&rename: Have you unchecked the option "Write unicode data in id3v2 tags"? because
eJukebox is incompatible with unicode..
Pirk
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-19-2007 at 12:18 PM
|
|
|
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.
Pirk
|
|
Audiosoft
|
posted on 5-20-2007 at 12:41 AM
|
|
|
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
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-20-2007 at 11:01 AM
|
|
|
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.
Pirk
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-20-2007 at 04:09 PM
|
|
|
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
|
|
Audiosoft
|
posted on 5-21-2007 at 01:07 AM
|
|
|
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
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
posted on 5-21-2007 at 12:18 PM
|
|
|
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.
Pirk
|
|
Pages: 1 2 |