I experience weird things happening to ejukebox when I let it run for a few hours with the "link songlist to currently playing song's album
when inactive" option enabled. In 3.83 the albumlist tended to "disappear" leaving black room where the albumlist was supposed to
be... I had to hit the albums tab to get things back to normal.
In the latest version, the albumlist get totally wrapped all over the place and the graphics of the application get's messed up. This does not
happen when the mentioned option is unchecked.
I got no idea what is causing this, except that it's related to the "link songlist to currently now playing..." somehow.
Anyone else experiencing simular things?
Ok I have done some more research around this and it's not due to this option checked or not.
It seems to be a memory problem. When I for instance have many webpages up at the same time ej's albumlist get's messed up. It doesn't
always happen when I use a lot of ram, but seems to depend on how long ej has been running..
The weird thing is that I have a bunch of ram (1 GB) and around 50% available when this happens. I have 1 gb free space on C: and a pagefile at 1gb. I
have tried to decrease and increase the pagefile without positive results...
Worth to note is that when I restart ej everything works ok again... Ejukebox does takeup around 2mb of my total ram all the time, like it used to do
in prior versions as well..
I have around 600 mb available space at the drive where ej is installed (can this be a problem?). There is around 1600 albumimages in my albumlist and
I have not experienced this prior to 3.86. Can there be some memory leak in this newest version, or is this due to my setup somehow?
I should mention that I have overclocked my system a bit, but this was never giving me problems in prior versions. My system temps are normal and all
other applications are responding fine when this problem occurs in ej..
I have also tried to rebuild the database to see if that solved it, but no .
The asn is at 66.1 mb which is normal.. I use the latest IE and Winamp 2.91
Hope someone can help or give some input on this. It's really, really annoying..
Here is a screenshot. Not something I would like to hang up in my living room, but sometimes reality hurts:
Every window and elements in each window (i.e checkboxes, text labels, select boxes, buttons) are identified in the Windows environment by a handle
known as a hWnd. On Win95-98 there is a limit to the maximum number of handles. On Win2000-XP there is no set limit. This is probably occurring
because there is not enough video card memory or video card capability to deal with the large number of open windows handles.
Because it tends to occur when you have allot of web browsers open.... Using a tabbed web browser program like MyIE2, to keep all your web pages under one interface (less buttons, address bars
etc), may help.
Aha! Could this be why i come home to a crashed machine some times, getting upon startup that my graphics card caused the system to crash?
As you might know, the eJukebox2web 1.0 PHP script causes my IE to open a new window for each new song at times.
After the crash, i get this error report:
WindowsVersion: XP
EventType: 0xEA - Thread Stuck in Device Driver
//
// The driver for the display device got stuck in an infinite loop. This
// usually indicates a problem with the device itself or with the device
// driver programming the hardware incorrectly. Please check with your
// display device vendor for any driver updates.
(...)
ShutdownCount: 17
Shutdown: 0
EventCount: 3
BreakCount: 3
BugcheckTriggered: 1
DebuggerNotPresent: 1
DriverName: MTXPARHD
EventFlag: 1
DeviceClass: Display
DeviceDescription: Matrox Parhelia 128MB
hmm.. I have a nvidia geforce TI 4800 with 128 mb ram. Should be powerful enough to handle quite a lot of 2d graphics?
Quote: |
Quote: |
Fishy, now i am experiencing this as well. Have no idea what to do with it except trying out if disabling "link to songlist" helps.
Pirk, sorry to hear about the loss of your mp3 collection.
Junk: Belive me that won't help much... Totally out of clue... It's most definately something in the skin engine which arctic doesn't
like or vica verca... I am back with the default skin now
Wondering if this also happens with skins which has used our dis and graphics as starting points as well... Like the cool one Slick is working on...
Would hate to see this become a mass phenomenon...
Pirk: .. Try to run a scan on it to see if you can delete some bad clusters
when you get hold of a new one.. Or is the damage so bad that it won't be possible ? Sad anyway...
Hmm...it could be because the gele.jpg in the Arctic skin is so large (427KB)...if that image was optimized to reduce its file size, by Saving For Web
in Photoshop, it could possibly fix this problem. Same goes for nowplay.jpg and artistlistbac.JPG. That is just a guess...
We will take a closer look at the coding of the Arctic skin soon, if optimizing those files doesn't fix it.
Quote: |
Fishy, eJukebox stood on all night without any problem, when "Link songlist to (...)" was switched off. I can't really thing what is different from this version and the previous versions that worked perfectly with the arctic skin, besides this function. Yet it still happens at your place with this feature turned off?
Yepp.. but only under heavy memory usage (having a lot of webpages up at the same time for instace) and only with the arctic skin.. I can also let it run overnight without problems, if I don't have a lot of stuff loaded.. This does not happen with the default skin no matter how much memory I use.. Really weird...
I think I am about to isolate the problem.
Done two interesting oberservations
1. The bugs in arctic appears only when the artistlist is open.
2. I tried to replace the artistlist.dis in arctic with the one from Slicks skin. Still wouldn't work. BUT, when I use the colors.ini file from
slick's skin arctic works just fine .
Conclusion: The problem is in colors.ini somewhere. Probably in the area where some of the colors of the artistlist is defined.
Edit2: .YES! Think I found the black bird..
Found this code in the colors.ini:
[ArtistBarLetters]
UseDefault=0
Background=153
Text=13421772
HiBackground=2296066
HiText=16777215
Style=7
SelBackground=2296066
SelText=13434879
SelStyle=7
It sent my artislist on a very bad trip.. It seems like selstyle=7 (simply flat) makes the artistlisttext bug a lot. And it takes the graphics of the
rest of ej with it... Demanding a restart of ej to work normal again, before it starts messing things up again after a while..
When using something else then 7 for instance 9 and 3 at the respective places it works fine all the way... At least for this particular skin.
Don't know if it's universial, and then a problem in the skin engine itself... I've consistently recreated this bug through changing
between 7 and other values in arctic though.. This should maybe be looked into...
Just to be sure Arctic now uses style=2 nearly all over the place. Which I think is a good looking style anyway..
I remember that I played around with these styles, adding these 7 values, right before 3.86 was released so it is possible that this problem was
present in 3.83 as well.. But I saw the problem in action just when I installed 3.86 and by error attributed the reason to 3.86. Sorry for that one..
Nevertheless arctic now works fine again
Slick: Thanks again for your new skin. Your colors.ini was very alike the one from the arctic skin, except you didn't include those values that
made the skin "buggy"... Smart move The alikeness made it easy
to discover the bogus things..
Here is the new colors.ini which should work properly.
Great, Fishy! Nice debugging I've included your new colors.ini file in the arctic archive now.
Well done on finding the problem. I based my skin on yours because I'd liked very much what you had done. Looks like you've identified your
problem - good for you!
I agree with audiosoft - when you have a database running, your machine is getting a bit of a workout. To give your machine a chance, it's better
to keep files as small as possible. You have some large graphic files in your skin that are using valuable resources just to sit there and look
pretty. If you want me to optimise them for you, let me know.
Well, the big .jpg files Audiosoft mentions would allocate just as much memory even if they were saved with heavier compression. They would occupy a bit less space on your HD, that's all. The ratio where the files become faster to load is also where the quality becomes compromised, so at the moment i cannot really see any good valid reason to reduce the quality of the backgrounds except reducing the size of the skin archive (which still fits on a floppy disk. ).
I appreciate what you are saying, Junk, but I disagree. Anyone that's ever used Microsofts Access database knows that graphics can cause massive
overheads, even when it appears illogical! Another example would be a CD-ROM. You could make it up to 650MB, but it does run better if file sizes are
generally smaller.
You could recompress the "gele" for example from 428Kb to about 80Kb without any noticible visuals (at a guess). Perhaps you could replace
the gele, artistlistbac and nowplay images with plain black to see whether there is a difference in performance, if you are still having issues.
Just a thought. Remember, file sizes are always on my mind! Performance problems mean your machine is doing too much!
I am test running this now. With the relevant jpg's compressed can't see any difference. But doesn't feel any faster either. But I have a pretty fast computer too.. It would maybe be noticeable on slower computers with less ram and cpu..
hm, i still see this bug every day when i come home from work... but only then. It's like having a child that makes a mess whenever left alone.
Quote: |
The strange thing is that I thought my earlier edit of the color.dis file fixed it.. I changed some of the styles of the artistlist in colors.ini and
it made the bugging occur a lot more seldom at least.
However it still occurs in some cases, but I have not been able to detect when and why.
I am pretty sure audiosoft got better things to do than puzzling with our .dis files, so I guess it is up to us to fix this. I am concidering using
bitzumo.red as a starting point and just add the different values from arctic progressivly while testing it to see if that might isolate the problem.
I don't think the problem lies in colors.ini because it is more or less the same as bitzumo now. The fact that the bugging happens so seldom and
randomly makes it a tricky task to isolate the problem though...
How often does it happen at your computer? Does it happen if you got the albumlist and/or artistlist closed? Maybe you could try to have those closed
when away from the computer for a while and see if it still happens? At my system it occurs so rarely that I've almost stopped worrying about
it.. Would be interesting to figure out what is causing it though.
It happens every day, when i come home from work, eJukebox is a graphical mess, and completely useless. I have to shut it down (can find the 'x' button, usually), then start it again, and everything works fine until i come home from work the next day.
Ok. Try to leave it with the albumlist and artistlist closed one day (Just the songlist open or something). If it still happens than. I think the problem is in songlist.dis. If it doesn't happen. Then leave it with the artistlist open and so on. You get the deduction here Would be a lot easier to track the problem if we knew which dis file to look in directly.
Tried it all, no difference.... and this does not happen at your house? This is strange indeed... i believe it to be a memory leak issue of some kind, allthough i have no experience with such from before (i am running win xp with 512 mb RAM). The only thing i know, is that when i come home from work, eJ uses 80-90% of my CPU, 20 mb of my memory, and has its graphics shattered all over my monitors. I cannot take a screenshot of this, because i get a win 3.11-style error message saying: "Not enough memory to create point graphics" or something similar.
I also got this pretty often before I modified the colors.ini. But, as mentioned, after that event it has happened *extreamly* rarly. Yet it's
pretty annoying when it does happen of course.
I don't think it has happened to me during the latest month though.. Hmm.. This will sound like deviltalk, but: Sorry, I am quite blank on this
issue. First saw it right after the 3.80 release. You can always play around with the styles in colors.ini to see if that makes a difference for you.
Just change the "styles" values to "4" for instance and do it consistenly at all definations in the configuration file. Changing
those values helped me at least.
I don't know if other users of the arctic skin have this problem as well? Would be very helpful with some input if that is the case.
As suspected, the problem goes away when i disable "Link songlist to currently playing song's album".
hm.. I haven't used that feature in ages and it is disabled on my system. I have experienced the phenomenon of bugging even if that feature is disabled. But, if that makes things function alright on your system, great
aha, if you haven't used the function, no wonder it ain't happening at your place. i kinda like the function. :
Do I have to remind you of that it happens with me, just not that often?
Anyway I actually would like to close this thread for two reasons:
1.
We're really not making any progress in finding out what the problem is. And since the problem occurs so rarely it's kindof hard finding the
right motivation to track the source of the problem. Why hunt the bee when it doesn't cause you any problem?
2.
I guess 4.0 will have to break skin compatibility with 3.x (correct me if I am wrong) and provide us with a lot of new snacks which I think will
motivate us to make an entire new skin anyhow.
My computer freezes up now that I've started overclocking my videocard. Geforce4 Ti 4200. ~10-15%
I did a system restore this morning, and will never overclock again. I'll see if ejukebox survives the night without a freezeup.