Isengard Beta 1 MySQL Upgrade issue
#31
(2015-05-03, 22:38)Milhouse Wrote:
(2015-05-03, 16:41)Montellese Wrote: Where do these long actor names containing multiple actors come from? Sounds to me like the main problem is somewhere else as those multiple actors could be stored separately.

Agreed, the problem is certainly somewhere else, just as the leading and trailing spaces that cause duplicates is a problem somewhere else, but we don't know where this data is coming from so for now we have to deal with it during the db migration and then henceforth deal with it the best we can until we do know where it's coming from and can finally fix it there.
first fine the cause of the problem where it's coming from. If you do a migration now and later on you may end up with the same crap if the root cause is not found
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#32
So leave the data sanitisation stuff in as part of DB upgrades. That's sensible defensive programming.

You have a rich third party tool using community, that is not likely to change. Regardless of the cause of the problem, Kodi would benefit from not failing in migrations, without notification (and worse, it appears to work, starts, just stuff is missing and on the following start the junk is still there!) - i.e. by having this in (or similar) you'll save yourselves a lot of grief when people hit these issues.

Even if your solution is just brute force - take the first actor only and trim it - approach during migration, at least the DBs will come over and people won't get wierd, un-notified failure conditions.

In my own case, this DB has been upgraded and carried forward since Camelot or certainly no later than Dharma, without these issues. I use only Sickbeard, Ember and TinyMM, all of which are very popular....so I am likely not an edge case here at all. I note on git one of the team says they don't use any third party tools and hit this issue....so surely the only sensible thing is to put in some sanitisation stuff?
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply
#33
I had the same problem (the actors and studio table showed up with lots of duplicates)
what fixed it for me was deduplication using ALTER_IGNORE_TABLE

ALTER IGNORE TABLE MyVideos90.actors ADD UNIQUE INDEX idx_actname (strActor (255))

ALTER IGNORE TABLE MyVideos90.studio ADD UNIQUE INDEX idx_stuname (strStudio (255))

please backup before you try
Reply
#34
I'm pretty sure this is a Sickbeard problem in one way or another. Sickbeard is the only 3rd party tool that I use that writes nfos, and I have the same problem as the others.
Reply
#35
It's really hampering my Isengard testing and github has gone quiet on it....are there any updates devs? Is this what is holding up the betas?
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply
#36
I believe this and one other thing are the "critical" issues holding up the next beta. I'm not sure what the status is on it, since most of the discussion is above my head, since I'm not a dev ;)
Reply
#37
Just a big thank you to all on this one - no issue upgrading helix to Isengard B2 it seems.

I'll delete all my test files etc now, and report if I find anything else separately.
Addons I wrote &/or maintain:
OzWeather (Australian BOM weather) | Check Previous Episode | Playback Resumer | Unpause Jumpback | XSqueezeDisplay | (Legacy - XSqueeze & XZen)
Sorry, no help w/out a *full debug log*.
Reply

Logout Mark Read Team Forum Stats Members Help
Isengard Beta 1 MySQL Upgrade issue1