Off the wall question but, if a game is deleted from the database, what happens to users who's games were linked to it next time their database is updated in launchbox?

[Fugus]

Sorry, just started wondering about that, are they given any notifications? Does it show an ID number until they update it next and then tries to find the next possible match?

What exactly happens when those database entries are deleted for the end users side?

[damageinc86]

Interesting question.  Wouldn't it just not update that game and leave all previous data about it intact?

[Fugus]

15 minutes ago, damageinc86 said:

Interesting question.  Wouldn't it just not update that game and leave all previous data about it intact?

Don't know which is what I am wondering.

The options i can think of.

1) The game ID clears without warning running the risk of it automatically picking a new game incorrectly without the user knowing out it. The worst option overall.
2) The game ID remains and it stays linked to a dead account which means no more updates. It's not a great option but better than #1.
3)  Launchbox informing you that the game ID linked with that game no longer exists and ask if you want to try and assign it to another ID. That seems like the best option.

But no clue which it actually does.

[damageinc86]

So is this like if you are running an entire platform media/metadata update?  And you're wondering what would happen in that scenario?  I've only updated all my metadata once past my initial import, because my first import was before the database really got going.  But I usually only need to update a few games at a time nowadays.  Couldn't you just hit the cancel button if the new data wasn't to your liking? That is, if you're just looking at one game.

Edited December 1, 2022 by damageinc86

[Fugus]

Just now, damageinc86 said:

So is this like if you are running an entire platform media/metadata update?  And you're wondering what would happen in that scenario?  I've only updated all my metadata once past my initial import, because my first import was before the database really got going.  But I usually only need to update a few games at a time nowadays.  Couldn't you just hit the cancel button if the new data wasn't to your liking?

Was thinking along the lines of if you decided to update an entire platform and replace what was there because you hadn't done it in a long time and wanted to update to newer media. It would overwrite all your old media and metadata with updated versions from the database which should all go fine for the stuff that still has the database ID still intact.

But lets so your game was linked to a duplicate of a game and that duplicate was deleted. How would launchbox handle that situation?  Because, while the database has been fairly accurate, I still make sure to manually check the name to make sure due to mismatched results when the games are added. But how does it handle that decides on if you need to manually recheck your games after an update like that as well.

My method involves setting up the display to a list and have the first 3 sections being the file path, the title, and the database ID and compare the name to the path name and make sure it has a database ID.

[kurzih]

13 hours ago, Fugus said:

But lets so your game was linked to a duplicate of a game and that duplicate was deleted. How would launchbox handle that situation?  Because, while the database has been fairly accurate, I still make sure to manually check the name to make sure due to mismatched results when the games are added. But how does it handle that decides on if you need to manually recheck your games after an update like that as well.

This has been an issue when a duplicate game has been replaced in the database by a completely different game (because the deletion doesn't seem to always work the first try on the online database):

For example I had a DS game, which was eventually a regional duplicate. The same ID it had used was replaced with a game that had nothing to do with that platform, but it had some media files that my entry didn't have. Then when I updated media/metadata it downloaded the "missing" media files. Then the entry was a mix and mash of the media I already had and the media I didn't have but was for the wrong game (that's how I realized I had a regional duplicate and had to re-search for the correct entry and delete the wrong media files).

I would prefer that no one would replace those games that don't seem to delete, with a game not in the database yet - they WILL delete eventually. It's more problematic to have ID's that completely change content than a duplicate than just flows around in the online database (as long as it's renamed as a duplicate or something - so it will not scrape as it shouldn't).

Edited December 1, 2022 by kurzih

[Fugus]

7 hours ago, kurzih said:

This has been an issue when a duplicate game has been replaced in the database by a completely different game (because the deletion doesn't seem to always work the first try on the online database):

For example I had a DS game, which was eventually a regional duplicate. The same ID it had used was replaced with a game that had nothing to do with that platform, but it had some media files that my entry didn't have. Then when I updated media/metadata it downloaded the "missing" media files. Then the entry was a mix and mash of the media I already had and the media I didn't have but was for the wrong game (that's how I realized I had a regional duplicate and had to re-search for the correct entry and delete the wrong media files).

I would prefer that no one would replace those games that don't seem to delete, with a game not in the database yet - they WILL delete eventually. It's more problematic to have ID's that completely change content than a duplicate than just flows around in the online database (as long as it's renamed as a duplicate or something - so it will not scrape as it shouldn't).

Understood, honestly, I know it will never be done, but I would have preferred a slightly different setup where the Database wasn't just numbers but the first 1-4 characters were actually a system designation with the next character being a designation of whether the game was legit game or a hack and then go for there.

Example: A Official or Unofficial Nintendo game would have a database ID of "NESA######"  while a hack or aftermarket title would be "NESB######".

Would make the database a little more fault proof when it came to issues like that. And having the official games separated from the other stuff would make that portion of it much more stable and less subject to changes. Could quite literally make an entry for each game in the No-Intro and ReDump databases for those systems and lock that entire section from having any more added and deleted without moderator approval and only the the media or metadata itself could change which would make that section near rock solid from being too far off with the only real things would be the games like Arc the Lad Collection on PSX where it is a single box title but has like 4 games in it which would end up making 5 entries total (1 for the total box and 4 for the 4 actual games in it so people could have them added to their collection either way).

But should have a way to detect if a game has been removed from the database or replaced.

[kurzih]

Yes, there is huge potential to make the online database better (in both logic, content and reliability), it hasn't had any major changes for years. I really hope someone will take over it's development to have a shiny "2.0" out of it.

A long time ago I also tried to ask about the idea of commercial/official game version separation vs. hacks, translations etc.  it didn't get any push though... more of an inconvenient idea having multiple entries/databases for basically the same "base" game.

[Fugus]

The irony of that is the database if full of entries for hacks, homebrew, and aftermarket games. Having the different entries for them isn't a big deal. Having a set database with all the legit stuff that is pretty well stable and locked in would be a huge deal though. But that would probably end up having to be a huge undertaking with a full time worker going to just managing that transition if I had to bet.