Vlansix

Hiya @Chris Kant, So, I'm actually looking deeper into this and I've noticed that the above actually isn't a game we have in the database, hence you wouldn't actually be able to link it to an ID, so you're probably pulling your data from wikipedia when you go through them a second time. There's the option of doing so during import (look for the checkbox on your next import!), otherwise you could also add the game to the database to make it easier for you (and other users! ) on future imports! Edit: Brad has better words than I do.

Hi @WTutwiler, I'm looking through the database for game entries that match the names of the games you've put up, but I'm getting either a ton of returns or nothing for the PC platform. Can you be a bit more specific? Links to the specific games (or just a platform for each) would be awesome :).

Here's the long and short of it- New game submissions create a parent change request in one table, which is then used to refer to all other associated requests that are stored in a separate table. (i.e. name, rating, wikipedia url, etc). Once loaded up into the moderation view, the next available parent is pulled and all associated change requests for that parent are displayed for the moderator to go through and approve/deny. Once any action is performed, the parent and/or individual requests are sent to a different moderation table to calculate approval/refusals for each item and action them appropriately, if needed. Same deal with images, with some extra logic. Also the same deal with developers and genres. All of these items have PK/FK relationships. So, the issue isn't with the database really, as nuking a bunch of rows isn't a big deal, as long as we're doing it in a way that makes sense with the PK/FKs setup. The issue is with the frontend ;). Basically, as the requests have already gone into the moderation queue by the point I see them, I'm too late to stop them from being submitted (which is the real fix). I now have to catch them as exceptions coming out of SQL server through the frontend app. The exception handler is a last-step error correction system, so I only see the errors after "Accept" or "Reject" is clicked on the moderation view, which causes the following issues: 1) since I'm not working inside a stored procedure at that point, I can't modify the data and continue with the request before returning to the frontend app seamlessly. 2) Since I'm at the end of the "approve/reject" process, the webpage is awaiting some form of reply and is currently setup in a manner to accept only that reply (or an exception - see internal server error). 3) As the prior request encountered an error in SQL server and stopped it being executed, throwing an exception to the calling function in the frontend, my options are either to let it crash (internal server error), or catch that exception and try to fix it there. 4) Since, by that point, I'm at the end of a very long line of logic in the frontend, if I want to make it seamless to end-users, I have three options: Correct the erroneous field and try to return the proper SqlDataReader object that the function calling *this* function expects (which is what we're doing now) recode most of the frontend to not use this means of communication, hence letting me null out the erroneous request before resubmitting. reconstruct the entire submission manually, resend it to whichever stored procedure that was being called, catch exceptions from that one (if there are any, in case), and then return to normal frontend execution. Basically, the solution is to prevent the frontend from submitting erroneous data in the first place :). All I'm doing now is a last-ditch effort to prevent users from seeing internal server errors while bad data is being worked out of the system, as those specific issues will be scrubbed out before they get to the DB in the future ;). All in all, if I were simply showing DB rows, erasing them wouldn't be difficult, but, as I'm showing DB rows that have tons of metadata linked to them, at the end of a process where every row is expected to be there and not be null, I can't just remove them :). Why am I not validating the data inside stored procedures instead. Ergh. Jesus. You make for a good rubber duck, Enverex. Thanks.

@Enverex - Sadly, we rejoiced too quickly. I was right initially, I'd just forgotten why. The database columns can be null, the data that contains submitted requests cannot. Just figured I'd update you. We'll need to geet keep (how the hell did I write geet instead of keep?) slodging through corrupt date entries until I fix the frontend to prevent them from being submitted in the first place.

So. Good news. The issue with "games being submitted with no name" is actually an issue which I've previously fixed. The games weren't being submitted with no name, the request containing the name of the game were getting approved, but the rest of the submission wasn't due to one of the errors above, which caused another cascade failure where the system was trying to add corrupt data and crashed. So, that's taken care of too :). We're getting somewhere. Woot woot. (p.s. I'm going through all the records in the moderation queue at the moment and I'm stuck in an endless sea of Nintendo Satellaview new game requests that are all working fine. Might take some time before I'm satisfied that the errors have been taken care of. If that's the case, I'll push the changes up!)

So, quick update, Currently working on another issue which would cause an "Internal Server Error". Basically, the field that hold the wikipedia URLs has a maximum character size. Exceeding that size causes the server to be unhappy. This isn't an issue when submitting wikipedia URLs, as they are generally under 255 character long, but submitting things like " https://books.google.no/books?id=BzxTtml8Jq4C&pg=PA20&lpg=PA20&dq=Astrocade+Blackjack+/+Poker+/+Acey-Deucey&source=bl&ots=8ZqQ1Tf83v&sig=oeln2nS6mXmuJsbEKdkrpU3DKJA&hl=no&sa=X&ved=0ahUKEwjO75T2rdnTAhVsKpoKHT-hAW84ChDoAQg8MAc#v=onepage&q=Astrocade Blackjack %2F Poker %2F Acey-Deucey&f=false " causes our current DB setup to crash. Will fix it and advise.

@Enverex - You know what? You made me doubt myself, so I went and rechecked the data validation on the database columns, and I'm a moron. That field does accept null values. The issue I was having was that I was completely removing that specific request (i.e. the release year request that goes through the moderation system), which causes a cascade failure of other systems getting the wrong number of requests in for this specific parent request. If I simply null the change out, it'll still get processed normally, but nothing will come from it. Heh. Looks like I need more coffee. Good catch! This'll make our lives easier :).

Hi guys, Aye. Examples would be great. Your XML files with the problematic entries would be awesome as well :). Could help us identify the root cause of the mis/no-match.

Hi @Enverex, That was my initial thought as well! Turns out that date fields are not nullable once they're submitted, and I'd have to remove that field, remove any and all prior moderation attempts on that field, and then recreate the request and resend it through to get the new game submission setup properly, OR I could simply remove the entire submission. What I ended up doing was setting the release date to the current date if the DB detects an issue with that field, which then allows the submission to be denied/approved normally. I'd rather have the mod team see that the date is incorrect and reject the change organically (or approve it if they'd rather simply have a date to fix later) than try to duct tape things together and hope I haven't broken anything else in the process :).

So, last word before I log off for the day: 1) I'll be back tomorrow at 5h30PM EST. 2) The exception manager I'm currently building to handle all of these issues is currently pretty aggressive. In essence, it locks me into a specific issue until it's fixed, which means that I can't upload all the fixes until I'm done. I assumed I'd be done before 8 PM EST, but it seems like there's still some work to do related to deleting zombie requests and errors with the developers, which means that I can't upload all the changes yet. I don't feel like locking you guys into endless error loops, so I'll wait until tomorrow when I've finished taking care of these issues before uploading everything :).

Update: *exhales* So. Due to some errors, which have mostly been patched, some changesets got partially approved. That, as of itself, isn't an issue. The problem is that I spent over three hours trying to debug garbage requests caused by these partially approved changesets, since they depended on some of the prior ones to be processed correctly x.x In any case, good news! There is no image bug, from what I can see, as most of the errors are being caused by one of the other issues which have been addressed already, meaning they should filter themselves out organically as the moderation system is used.

Update: The internal issue which was causing these errors to show up has been addressed. Will be uploaded later today, once I'm done getting all of these bloody things sorted. Now working on another issue (causing this same error to show up) with game image submissions. Stay tuned x.x

Update: Erroneous date problem has been fixed in the dev build. Should be pushed live later today. Will advise. Currently working on an internal issue that is also causing the above error, as well as new game submissions being sent in without any name (?!) also causing this error.

Good catch then! I'll see where they're coming in from o.O.

9AM Update: Determined that one of the reasons why we've been getting the "Internal Server Errors" (which is a catch-all "Something's not right." error) is because we're getting erroneous new game submissions. Somehow, someone is submitting a ton of new games with their release date set in the second century AD, and this is making our database server angry. I'm currently working on automatically deleting these date entries to correct for this in the future. Will update when done.

Hi @Enverex, This is a known issue. When we originally scraped together a bunch of data to start up the database, some of the data we received was formatted incorrectly. (i.e. see the htmlentities in your second quote above) As it's not a code-breaking issue at the moment, what we've done is a simple stopgap measure to correct for it when it shows up. Basically, the database GUI currently tries to hide the erroneous text from most of the places where it is displayed. If you notice some erroneous htmlentities anywhere, simply submit any change request to that item (i.e. you can even submit an empty change request for it. Hit the edit button, edit nothing and hit submit.), and the backend will remove all htmlentities present in that item. Removing them all server-side is something we're thinking of doing once we've stabilized the database. For the moment, removing them organically will have to do :).

Thanks @FistyDollars, it's been a while :). I'm currently busy cleaning the issue tracker and reading through the changes Jason uploaded, but yeah, my main goal is to get this issue sorted ASAP. It's been bugging everyone (including me), so I want it gone :P.

Hi all, I'm looking into this as we speak. Will keep you updated here.

Hi guys, I'm back. Had to leave due to some unforeseen personal issues, but that's all taken care of now. I still love you guys, and LaunchBox. In any case, here's what's happening now: 1) I'm currently consolidating the issues on the DB issue tracker so as to make managing new issues feasible for me (and not immensely time consuming. I'm just one guy! ;), so, if you see that I've closed your issue and/or marked it as a duplicate, don't worry, I'm not out to get you personally :). My main focus for the next little while will be to stabilize the database and improve its performance. Hence, most feature requests / minor interface issues will be put on hold until I get through the major problems. (In essence, gotta get the engine turnin' properly before we make the car pretty.) 2) First thing I'm taking care of are the throngs of "internal server errors" that have been popping up everywhere these last couple months. I'm glad that the "Skip" button has allowed some people to bypass them, but wow, they're everywhere. I'm currently consolidating all the bug reports into issue 261 as it's the first I came upon while parsing through the issues, so no worries about issue 220 or the votes on it, it's still my top priority :). P.s. R.I.P. Jason's Beard. Ye shall be missed.

Aye, i'll be looking into this shortly. Kind of annoying that this is still happening. I won't be resubmitting the oreviously approved requests as some people may resubmit and/or change those entries, and I don't like mass deleting things generally speaking, so no worries.

Thanks for the feedback guys. Will look into this shortly. Ugh.

Morning guys, Real quickly- Whoever's been submitting changes for the Judge Dredd games and adding "I AM THE LAW" randomly as a reason, you made me spit coffee everywhere. Well played, heheheh.

Hi @syntax_X, Welcome to the party :). So, here's the long and short of it. The main issue is that most of the titles you listed are not actually in the games database. You can resolve the issues you're having with them by adding any metadata/images you have for them to the database so as to help improve it :). Right now, Launchbox will either scrape images from emumovies or Wikipedia, depending on how you set up the import wizard during import. Concerning battle mania, it's the same issue. Launchbox finds a match for Battle Mania in Battle Mania Daiginjo. You can either add Battle Mania to the database to correct for it, or simply edit the game in LaunchBox and remove its association from that games database id from your local machine if you prefer. Hope that helps! Sorry for the short reply, just woke up and am commenting from my phone

So. Quick update. Change reasons now work for every type of change request (images/game deletions/etc), same thing for the skip button. As usual, let me know if something doesn't work or catches on fire.

There we go. Should be fixed now. Good catch, by the way. I've been seeing this error in the logs and was wondering where it was coming from. You helped a ton :).