Jason Carr

Thanks @eatkinola. I'm going to assume that it's not an issue with this release. @ckp Not since the official 7.11 release; nothing has been changed that should ever cause *more* RAM to be used. However, as I stated I above I did add a mechanism to aggressively decrease RAM usage on low-RAM systems. The 1.7-2.0 GB of RAM use is normal and expected on a 16 GB system, as it's not as aggressive (the aggressive RAM reduction can decrease performance).

The memory leaks have been solved @ckp. That was the whole point of the last week of development I put in...

This is not at all a good idea as it could result in corrupt data files to routinely kill Big Box.

High quality is probably only noticeable in full-screen CoverFlow, where the images are bigger. I'm seeing a huge difference in RAM usage though between the Medium and Lowest image quality settings. Something like 400 megs.

Gotcha, that makes sense. I'm glad to hear that RAM is so low when you turn that stuff off.

Nice. Are you using WMP? Or do you have any videos in there at all?

One thing I'm noticing with the RAM requirements is that the CoverFlow image quality makes a HUGE difference. I'm seeing Big Box easily stay under 1 gig of RAM always when the CoverFlow image quality is set to lowest. The most RAM-intensive part of Big Box is indeed the CoverFlow images, just because there are so many of them on the screen at once and they can be pretty big once loaded into RAM. I'm finding that the highest CoverFlow image quality setting can even be a tad bit too RAM-intensive on 8 GB systems while running CoverFlow. Edit: I think what I might do is force a lower CoverFlow image quality setting on systems with less RAM.

Yeah, a lot can be done here with different themes, but yes, something like this would be nice. Unfortunately though it's probably not currently that high up on the priority list. But we'll get there eventually.

If Big Box on your main system consistently only uses 1.2 gigs of RAM, then you must not be using all the bells and whistles. That's pretty much the bare minimum of typical memory usage. I'm not saying that Big Box should consistently use 3 gigs of RAM, of course not, but RAM usage will fluctuate significantly as images are used and disposed. 1.6 gigs of usage is not at all alarming. The way Windows handles RAM is very flexible and fluid, as it should be. Yes, Big Box may use 3 gigs of RAM while working, switching views, loading images, in attract mode, etc. That's certainly nothing new and should not come as a surprise because Big Box has used that much RAM pretty much since the beginning. Still, please try the new beta as it should make a difference. Just please don't expect RAM usage to always stay under a gig, because that's not even practical with everything going on.

Alright, got another new beta out. @neil9000 Please let me know if the startup videos still don't show up every once in a while. On systems with 8 gigs of RAM or less, I'm now being very aggressive running the memory clean-up processes, to the point where it might affect performance. However, due to RAM fragmentation possibilities and related things I'm finding that slower systems with 8 gigs or less can crash with out of memory errors even when there appears to be plenty of free RAM (I blame Windows for this as there's nothing I can really do about it). If Big Box was an MS-DOS game, the system requirements would read like this: RAM: 4 GB (Required) 16 GB (Recommended) Keep in mind that this is when using the more advanced themes and all the pretty features. It's certainly possible to get the RAM requirements way down if you use a simpler theme, etc.

Yeah, I understand that, but straight out of the gate, Big Box uses 1 GB of RAM. So 1.6 GB is very much within the expected range. That said, I'll be putting out a new beta shortly to force being more aggressive with RAM reduction on 8 GB or less systems.

@alnyden @eatkinola I'm seeing some errors with Ao.Bigbox.Plugins in the Nostalgia theme. It's possible that I changed something in the betas that would cause this; I can work with you @eatkinola to get it fixed. I'm guessing that the freezes you were experiencing @alnyden are related. Here's the last error I got:

Honestly 1.6 gigs is very normal and expected memory usage, especially if you have over 16 gigs of RAM. CoverFlow is very RAM intensive with all those images, and there's always a trade off between RAM usage and performance. Big Box is now more or less aggressive at reducing RAM depending on how much RAM you have free and in your system. Bear in mind that VLC alone can take up around 500 megs of RAM, with several HD videos playing at once. Depending on the theme, 1.6 gigs is about average (and correct) memory usage for Big Box currently. Getting it to be significantly less than that would only ruin performance. What shouldn't be happening is for Big Box to get up past 3 gigs and stay there for long periods of time (or keep growing).

Our moderation "staff" are all volunteers. Anyways, your refund is on its way.

I am more than glad to offer you a refund @GunerX. To be honest I haven't been following any of this drama but I'm glad to avoid all of it with a simple refund. I'm sorry to hear that you've had a bad experience. I'll follow up with you via PM to get your license email.

@neil9000 Good to know. I'll take another look at that issue.

@GunerX Is Big Box locked by chance?

Beta 13 is out now as well guys. Believe it or not, we had a different memory leak that only occurs when a sound card is just randomly ripped from the computer (or disabled, etc.). That doesn't sound like much of an issue, but it is on arcade cabinets where TVs are commonly turned off while the computer is running, and since sound often goes through the TV's HDMI port, the sound card is essentially disabled when the TV gets turned off lol. Learn something new every day. I've also made some more minor RAM and performance improvements in this beta. I've been doing extensive testing on an 8-year-old machine with a Core 2 Quad CPU in order to eliminate as many issues as possible. We're pretty smooth at this point, even when run for days at a time on crappy hardware. Depending on how everything goes for you guys with this beta, I'm hoping to put out the official release tomorrow.

@ckp Yes it should, or at least that's what I'm hoping. Please test and let me know if you can. @damageinc86 That's quite strange. Are you using any file sync services or anything that could delete or change files in the LaunchBox folder? Big Box uses a file located at LaunchBox\Metadata\videoActive to determine if the video is still playing, so if something happens to be interfering with that file, that could be causing the issue. Other than that, I'm lost. I suppose it could also possibly be an issue with a particular video file. Yeah, I'd go ahead and restart the computer to see if that makes a difference, as well as confirming 100% the LaunchBox version number (which should be at least 7.12-beta-12).

FYI guys, got all the translations into the latest beta yesterday. Thanks all once again. I should have the official release out before the end of the week.

Alright, beta 12 is now out as well. As I stated earlier, I've been working primarily on performance and reducing RAM usage. I did find a memory leak that I think was introduced in 7.11 that should be fixed now as well. I'm now loading even more things in background threads to prevent stuttering in the interface.

@neil9000 I'm actually still working on putting out another new beta today, which is why I haven't mentioned it yet lol. Been working on more RAM reductions and performance improvements.

@emko Background images not loading on the platform screen can actually be caused by several different things; for performance reasons, Big Box will just give up if it goes through 5 or so random games and doesn't find a background image for any of them. That logic has been in place for a long time though. I guess my only point is that the background images when viewing a specific game is a better test for that scenario. @damageinc86 It's difficult to get the timing exactly perfect; obviously the goal is to show Big Box immediately after the video ends, with no delay, and without the video getting cut off. That is happening on some systems but I guess on others a split second of the video might get cut off. You're the first person to even notice that that's an issue lol. I'll see if there's anything I can do to improve it, but it's a difficult thing to get exactly right on every possible system.

@emko I ran a test on that image and I can confirm that it's not loading properly with .NET's WPF JPEG decoding utility, which is pretty odd. I'm not sure how to fix it without coding my own JPEG decoder (that'd be a nightmare). We're using a more performant method of loading images now, which is probably why this is a new issue since 7.11. All I can figure is that that particular image uses some kind of strange codec format; that stinks but I'm not sure what to really do about it. If we figured out exactly what the problem is, we might be able to batch convert problematic images on the games database, though. How many images have you found?

@mcfilmmakers Try turning on the option to "Skip the game details screen". I believe that will do exactly what you want. Games will play directly from the games lists without having to press a different button.