DBRepair development

Actually I do have some older dbs from the weekly plex backup. I’ll pm you that as well as the log

Older PMS backups are just as good.

If the backup is known to be from 1.43.5 – that’s ideal

DM sent

ALL:

Regarding the “Warning: New index found” report of today, I know I asked to push this to GitHub but it feels like a “need it now” kinda thing.

  1. I looked at where it’s coming from
  2. I know why it’s being reported.
  3. One is obsolete, one is actually missing.
  4. The obsolete one comes from a much older version of PMS. It shouldn’t be there.
  5. The genuinely missing one should be, and is, regenerated.
  6. I can easily fix this but I would like to do another Testing cycle to ensure there is no fallout from it.

How it would work:

  1. DBRepair looks at the tables, indexes, and triggers.
  2. Before creating them and transferring any data or reconstructing, DBRepair would confirm it’s still ‘current’ for this PMS version. (Part of it’s verification pass)
    – If obsolete, it will tell you and not recreate it (junk removal) and will never be seen again.
    – If current, it will proceed normally, recreating (if needed) as it does now.
    – If new/unknown, it will still recreate & copy it as it does now but also flag as new and let you know.

I would finish implementation by giving DBRepair the database schemas for every PMS build I have. ( I have 318 released builds ). DBRepair would instantly gain all that DB knowledge. The amount of new data added to the tables is actually very small due to how I store them.

My question to you:

  • Spend the extra time to add and test the changes before Public release
  • Wait until after Public release and add it to the first update with all the other bug fixes
0 voters

Personally, I think it’s worth adding now as it provides peace of mind about what’s going on in the DB as well as cleaning out junk (abandoned structures) in the DBs.

As for the Blobs DB bloat, that will CLEARLY wait until a future release.