Xpendable Posted January 13, 2019 Share Posted January 13, 2019 (edited) I'm having major problems. After a recent update, BigBox is hanging on the second game launched. It doesn't matter what game you try to launch (only talking Mame at the moment), it launches the WRONG game and it get stuck and I can't get out of it. I have to forcefully kill BigBox via TaskManger and restart it after EVERY game. What is going on here? Edited February 8, 2019 by Xpendable Changed title of thread to reflect current issue. Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted January 13, 2019 Share Posted January 13, 2019 If you're using MAME via Retroarch, it may an issue with the startup screens. Try disabling the startup screens in Big Box under Game Startup. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted January 13, 2019 Author Share Posted January 13, 2019 I don't believe I am using retroarch for mame but I will try disabling screens to see if it fixes the problem. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted January 28, 2019 Author Share Posted January 28, 2019 I did disable the startup screens and the problem went away. I also think there is a memory leak. BigBox is crashing after a day (even if nobody plays anything on my machine) due to being out of memory. My computer unfortunately only has 4 GB of ram which I'm unable to expand due to something being wrong with the 2nd memory slot, so at the moment, adding memory isn't a solution for me. Others probably have more ram and aren't as likely to see this as often if at all. Quote Link to comment Share on other sites More sharing options...
Omen Posted January 28, 2019 Share Posted January 28, 2019 1 hour ago, Xpendable said: I did disable the startup screens and the problem went away. I also think there is a memory leak. BigBox is crashing after a day (even if nobody plays anything on my machine) due to being out of memory. My computer unfortunately only has 4 GB of ram which I'm unable to expand due to something being wrong with the 2nd memory slot, so at the moment, adding memory isn't a solution for me. Others probably have more ram and aren't as likely to see this as often if at all. 4 GB is insanely low. LB caches all artwork as it encounters it, so even if someone isn't playing, attract mode alone will use up memory over time. That doesn't mean there is a memory leak, it means your system isn't able to keep up. Honestly 8GB is a low amount of RAM these days. Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted January 28, 2019 Share Posted January 28, 2019 There is no memory leak; I know this because I can run it for days and days (just got done with a test running it for 3 days and the memory wasn't any higher than it should be). But yes, 4 GB is bare minimum for RAM, and may or may not be enough depending on the theme and views that you're using. CoverFlow is known to be very RAM-intensive due to the required caching of large images, for example. Regardless, all that RAM is recycled when leaving the view. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 5, 2019 Author Share Posted February 5, 2019 (edited) On 1/28/2019 at 11:44 AM, Jason Carr said: There is no memory leak; I know this because I can run it for days and days (just got done with a test running it for 3 days and the memory wasn't any higher than it should be). But yes, 4 GB is bare minimum for RAM, and may or may not be enough depending on the theme and views that you're using. CoverFlow is known to be very RAM-intensive due to the required caching of large images, for example. Regardless, all that RAM is recycled when leaving the view. Some more information for you, Jason. I am indeed using CoverFlow. The crash occurs after running for several days. I have Attract Mode set to NOT cycle platforms. It always stays on my "Arcade" platform (MAME) which has about 1536 titles. I've captured the .NET crash below... it is the exact same error on every crash: - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name=".NET Runtime" /> <EventID Qualifiers="0">1026</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2019-02-04T13:24:37.000000000Z" /> <EventRecordID>21005</EventRecordID> <Channel>Application</Channel> <Computer>HTPC</Computer> <Security /> </System> - <EventData> <Data>Application: BigBox.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ComponentModel.Win32Exception at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D) at MS.Win32.HwndWrapper..ctor(Int32, Int32, Int32, Int32, Int32, Int32, Int32, System.String, IntPtr, MS.Win32.HwndWrapperHook[]) at System.Windows.Threading.Dispatcher..ctor() at System.Windows.Threading.Dispatcher.get_CurrentDispatcher() at System.Windows.Media.Imaging.BitmapDecoder..ctor(System.Uri, System.Windows.Media.Imaging.BitmapCreateOptions, System.Windows.Media.Imaging.BitmapCacheOption, System.Guid) at System.Windows.Media.Imaging.PngBitmapDecoder..ctor(System.Uri, System.Windows.Media.Imaging.BitmapCreateOptions, System.Windows.Media.Imaging.BitmapCacheOption) at DynamicClass.(System.Object) at Unbroken.LaunchBox.Wpf.Controls.CoverFlow.ThumbnailManager.Worker(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch()</Data> </EventData> </Event> It appears to be loading content when the crash occurs. When the crash occurs, Windows is so exhausted of memory that it cannot even display Task Manager! In true .NET fashion, as soon as I kill BigBox.exe, Windows recovers and the memory that the .NET program had been using is returned. I believe that 4GB is simply NOT enough memory, at least for the number of ROMS I have in my arcade wheel. Probably as it's approaching all remaining free memory, the crash occurs because the OS does not have enough resources. You probably never see this because I'm betting a computer that has more than 4GB of ram will be capped at 4GB (possibly default limit on a .NET program... and since there is still plenty of ram left over for the OS, everything is fine.) I'm assuming you are compiling 64-bit and not 32-bit, but that would still be irrelevant in my case with only 4GB of RAM (and less than that would be available for BigBox). One final thought... this problem NEVER occurred for most of last year, I have not added any roms or changed any media. No other changes have occurred on this computer. That would mean a program change is causing a problem where one didn't manifest itself before. Food for thought. Edited February 5, 2019 by Xpendable Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted February 5, 2019 Share Posted February 5, 2019 @Xpendable I guess that does make sense that CoverFlow is just pushing the memory limits there. The memory is all cleaned up when you leave that view, but if you have enough games in the list to hit the limit, then you will hit it. There is a CoverFlow Image Quality setting in the Big Box options that should help if you set it to a lower value (it uses a smaller image cache and thus less memory if you use lower quality). Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 5, 2019 Author Share Posted February 5, 2019 Thanks, I'll give that a try. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 5, 2019 Author Share Posted February 5, 2019 (edited) Shoot, I already have CoverFlow Image Quality set to Lowest (Fastest). One more thing... after a fresh reboot and after BigBox is started, total memory usage for Windows 7 + BigBox is about 2GB. Meaning, there's about 2GB free. It will be interesting to see what that looks like after 4 hours, 8 hours, 12 hours, etc. Edited February 5, 2019 by Xpendable Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted February 5, 2019 Share Posted February 5, 2019 Sorry to hear. I currently don't have any other solution (other than more RAM, or using a different view). The game clear logo wheels should be much less RAM-intensive. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 7, 2019 Author Share Posted February 7, 2019 So after running for more than a day, BigBox RAM usage increased to 2.62GB (from 2GB). That sort of proves there is a memory leak before it taps out at the max .Net allows. At this point Windows reported that it was low on memory and recommended that BigBox.exe be stopped. I caught it before memory was exhausted so no crash occurred. Also I was using the Unified theme, if that helps. I'm trying a new test with the Default theme to see if I have the same problem. Also, I have always used the game clear logos. And a reminder that this problem never occurred until after an update within the last few months. Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted February 7, 2019 Share Posted February 7, 2019 You had previously said you were using CoverFlow, which is different than the clear logo wheels. There's a huge difference in memory usage between the CoverFlow views and the clear logo wheels. In all blunt honesty, I don't understand how that proves anything at all (it really doesn't). Regardless, there were some VLC-related things that were fixed that could possibly be improved and use less memory now; I'm not sure if you're using VLC or Windows Media Player for your video playback engine, but it would be worth trying the latest beta (9.4-beta-10) to see if it makes any difference. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 7, 2019 Author Share Posted February 7, 2019 My fault, I misunderstood what CoverFlow meant. I thought that was a theme name, but that's not correct, right? Does CoverFlow refer to certain view types? The theme I am using was "Unified" and the view I was using has a vertical wheel on the right. So I guess I am not using CoverFlow at all, I'm using a clear logo wheel. Again, my bad. If memory serves, I am using Windows Media Player for the video playback. When I first installed LaunchBox, I recall that I couldn't get the VLC to work... I'll take a look at that again and confirm. Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted February 7, 2019 Share Posted February 7, 2019 Yeah, CoverFlow refers to the views that use the big images that flip. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 8, 2019 Author Share Posted February 8, 2019 (edited) 1. Ok, memory issue occurred using the default theme & vertical wheel 2 as well. On startup, BigBox is using around 800-900 mb. After < 24 hours, it's using > 2 GB of RAM. Shutting down BigBox and all the memory comes back. 2. I did just renew my license for another year (had expired a couple of days ago) and updated to 9.4 Beta 10. 3. I confirmed that I was indeed using Windows Media Player for video playback. I switched back to VLC and noticed video corruption right away in many of the game videos. I believe this is why I switched to WMP in the first place. I just did some searching, and I see a recommendation to install the K-Lite codecs which supposedly resolves the issue. I just downloaded and installed that and I'm trying it now... Nope, this does not seem to resolve the issue. The animations (on top of the video) are also sluggish with VLC. By the way, I have a pretty beefy graphics card in this system... Nvidia 770GTX. Did some more testing and BigBox in general has gotten sluggish as hell with VLC. I can hear the hard drive thrashing like mad, which doesn't happen when I use WMP. When I switch to WMP, those problems go away entirely. Why is VLC the recommended video engine? A quick search and it looks like I'm not the only one who has problems with VLC. Here's a YouTube video I made showing the difference in performance between VLC and WMP on my computer: Edited February 8, 2019 by Xpendable Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 8, 2019 Author Share Posted February 8, 2019 (edited) I will try setting up a scheduled task to reboot the computer nightly. That should more or less resolve my issue since it appears to take at least a day for things to go south. Worst case scenario I could do it twice a day. Edited February 8, 2019 by Xpendable Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted February 8, 2019 Share Posted February 8, 2019 Okay, I'm guessing maybe memory usage could be improved for systems with low amounts of RAM if the user ends up staying on a single screen for a long time. Admittedly our testing has always involved switching between views regularly, as that's a more common use case. I will add that to my list to review; unfortunately I can't make it a high priority for the moment because it's less than the recommended memory requirements (8 gigs) and isn't a common use case, but hopefully I can look at it relatively soon. Per VLC, it is often more taxing on hardware than Windows Media Player. The primary reason we recommend it is that it plays all types of videos out of the gate, but Windows Media Player needs third-party codecs to be installed to play many of the videos. It sounds like your system is just beneath the recommended specifications (though I don't know what they are exactly). To be honest I would not consider a GTX 770 to be beefy these days, as the card is almost 6 years old. I'm guessing that CPU and RAM limitations are more coming into play though than the video card, though I can't say for sure. Quote Link to comment Share on other sites More sharing options...
Xpendable Posted February 8, 2019 Author Share Posted February 8, 2019 Actually I misspoke. It's actually a 970GTX. Even if it was a 770GTX, that is way overkill for the front end and mame. I know this because I previously used a 10+ year piece of crap $49 gt card and this all worked fine. Absolutely no difference. You aren't leveraging much of the graphics card to be honest. No shaders or meshes, right? I used to code for both openGL and DirectX, so I actually have some experience here. Yep, get this is a lower priority. Quote Link to comment Share on other sites More sharing options...
JaysArcade Posted February 22, 2019 Share Posted February 22, 2019 For the last year or so, I've used a scheduled task to kill Bigbox every morning at 9:00 am and another to restart Bigbox at 9:05am for the same reasons. After running for a few hours, Bigbox becomes sluggish and/or unresponsive and I've occasionally got the out of memory error. Not sure how much memory I have but pretty sure it's 8 gigs. If not, I'll upgrade. I'll check next time I'm on my cab to see what I have in there. Its disheartening to see BigBox crashed every day when I come home. Using the task scheduler has really improved things for me. FWIW, the latest releases - 9.4 and 9.5 have seemed to be a lot more stable - at least the menu controls seem to be more responsive after an extended period of not touching the system. Previously, I could walk up to my cab and press buttons, or try to navigate, and the the attract mode would just keep spinning like I wasn't even there. This thread really has me curious. I will definitely look to see how much RAM I have this weekend when I have time. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.