Thread: ICE³ v2.0

That sucks man, maybe srbatty can tell you a trick or two

It eventually crashed and quit on its own, I can't get it to open anymore. I think the VM usage would be the swap file, the ~900 MB is real memory usage. My free memory goes to like 5 MB as Ice3 tries to start up.

As far as memory is concerned, I am only interested in ICE³-"Real Memory", System Memory-"Free", and System Memory-"Swap Used". See attached picture.

Hmm, as soon as I rename the music folder where Ice3 is looking, it'll start up just fine. Any thoughts?

On startup, ICE³ will scan the Music Path (which you set earlier), and build a database from this. If you change the name of the folder, ICE³ will scan a folder which does not exist, therefore not creating a database and starting with a blank music library.

I mean, of course I don't know the indepth programming of the front end, but if iTunes can handle the 10000 songs, then I don't know what could be the problem.

ICE³ is not iTunes. ICE³ creates a memory resident database on startup, which is slower to load but faster to use. I don't know how Apple has written iTunes, but I assume that the majority of the database is accessed on demand from the "iTunes Music Library.xml".

While I was switching songs in Ice3, it came across a deauthorized song, and an iTunes warning came up, so I'm assuming the frontend is using something iTunes related.

ICE³ uses the QTKit framework for music and movie playback. I assume iTunes does also. If this is the case, then Apple must have written something within this framework which picks up on DRM protection.

Checking memory usage with no songs loaded into Ice3, I'm at 838 MB VM, and 100 MB of real RAM. That is acceptable.

I agree.

Memory management is an on-going job. Unfortunately every time we manage to shave some fat, a damn bug rears it's ugly head.

Thanks for the feedback.

Sure thing, loving the work you do and the hours you put into it. Here's a shot of what happens when my library is 10000 big.



Like I said, the Virtual Memory creeps upwards to over 3.5GB.

Definitely a memory issue!
You only have 24MB free with a swap file of 200MB.
I'm sorry to say that until we can trim some more fat, you will have to lighten your library.

p.s. This might help with the screenshots:

Originally Posted by srbatty

Definitely a memory issue!
You only have 24MB free with a swap file of 200MB.
I'm sorry to say that until we can trim some more fat, you will have to lighten your library.

p.s. This might help with the screenshots:

Thanks, will keep it trim for now.

The mac does not have internet connection at the moment, otherwise I would have posted from there, oh well!

Oh, sorry.
You will have to be careful when using coverflow. Watch the memory usage while flicking through covers and you'll soon see what I mean.

After using ICE3 for a while now, I have noticed a issue with the way the volume is controlled. I dont think the current percentage increments work best. When my system is configured so 100% is loud enough, 5% is usually too loud for the lowest setting. Adding smaller increments when at 5% and below may help, but I think a different concept would work best for this.

For decades, professional audio equipment(and even some consumer equipment) has used dB levels for increments in controlling volume which increase logarithmically. I think ICE3 should implement some type of volume control based off a db level. A percentage does not represent the way our ears hear, but a volume control should.

I understand that the success in implementing this depends on how it must be programmed, but I'm sure a better solution must be possible because of so many other applications that achieve this.


p.s. A volume slider would be awesome too

After using ICE3 for a while now, I have noticed a issue with the way the volume is controlled. I dont think the current percentage increments work best. When my system is configured so 100% is loud enough, 5% is usually too loud for the lowest setting. Adding smaller increments when at 5% and below may help, but I think a different concept would work best for this.

For decades, professional audio equipment(and even some consumer equipment) has used dB levels for increments in controlling volume which increase logarithmically. I think ICE3 should implement some type of volume control based off a db level. A percentage does not represent the way our ears hear, but a volume control should.

I understand that the success in implementing this depends on how it must be programmed, but I'm sure a better solution must be possible because of so many other applications that achieve this.

Thanks and yes, we are looking at using a log based volume which will be included into a future build.

p.s. A volume slider would be awesome too

What happens when you are changing the volume and drive over a pot hole?

Originally Posted by srbatty

What happens when you are changing the volume and drive over a pot hole?

Haha! That's a good point that I never really thought of, but maybe you could leave that up to the user. I know I would love to have the option to have a slider pop up when I hit the volume button instead of the current buttons.