Importing an old view history (option 8) results in issues about plexdbrepair

[ChuckPa]

The table has a unique constraint which prevents duplicates.

I think what's happening is , with Plex's Cloud-based watch history, this feature is colliding with it.

In this case, there are 13 references to the series but the series was matched using a different Agent so it shows up as negative (not found).

When importing, I don't know what the PMS settings are for the Agents.

My recommendation to you is either use Cloud-based history tracking or DB-based. You can't use both

I'm considering removing this feature.

[Tkkg1994]

The table has a unique constraint which prevents duplicates.

I think what's happening is , with Plex's Cloud-based watch history, this feature is colliding with it.

In this case, there are 13 references to the series but the series was matched using a different Agent so it shows up as negative (not found).

When importing, I don't know what the PMS settings are for the Agents.

My recommendation to you is either use Cloud-based history tracking or DB-based. You can't use both

I'm considering removing this feature.

Thank you for the answer. However it's not exactly what's happening since:

1. I wouldn't need to import my Plex History if the cloud based tracking was enabled. It isn't in my case, it's fully locally on my database
2. When I mark all episodes as "unwatched" the counter goes back to 0. It only turns negative when it's watched by myself on the old database and marked as watched on the 2nd database. And then merged of course.

i'm digging around in the db to see if I can find anything useful but as you are clearly a pro at this, any input and help is very much appreciated!

[ChuckPa]

When I mark all episodes as "unwatched" the counter goes back to 0. It only turns negative when it's watched by myself on the old database and marked as watched on the 2nd database. And then merged of course.

If it turns negative when you watch it, independent of importing anything, stop right there.

Scenario:

1. Mark unwatched
2. Observe no negative counter
3. Play normally / mark as watched manually

It only turns negative when it's watched by myself on the old database

5. Observe negative count.

If this is what's happening then ALL STOP. That's a DB corruption deeper than what I can help with.
The only choice is to use a backup DB (full swap) from elsewhere.

My tool works on structure and whole tables. It doesn't have C++, agents, or metadata backing it like PMS does.

[Tkkg1994]

When I mark all episodes as "unwatched" the counter goes back to 0. It only turns negative when it's watched by myself on the old database and marked as watched on the 2nd database. And then merged of course.

If it turns negative when you watch it, independent of importing anything, stop right there.

Scenario:

1. Mark unwatched

2. Observe no negative counter

3. Play normally / mark as watched manually

It only turns negative when it's watched by myself on the old database

5. Observe negative count.

If this is what's happening then ALL STOP. That's a DB corruption deeper than what I can help with. The only choice is to use a backup DB (full swap) from elsewhere.

My tool works on structure and whole tables. It doesn't have C++, agents, or metadata backing it like PMS does.

So I found a potential answer for this issue:

https://technicalramblings.com/blog/migrating-view-history-between-two-plex-servers-avoiding-negative-unwatched-count/#part-two-removing-the-duplicates

I will test this out tomorrow on my database (of course with a backup) and if it works fine, I'll let you know. Then you can include the command in your tool! Will for sure help people

[ChuckPa]

I have the same SQL from our devs.

"DELETE FROM metadata_item_settings
WHERE id in (SELECT MIN(id) 
FROM metadata_item_settings 
GROUP BY guid HAVING COUNT(guid) > 1);"

When this was tested, it didn't work in all cases.
Maybe it was those particular databases but also maybe not.
(I'm not the sharpest database guy)

If you look in DBRepair.sh , line #1274-1284, you'll see it's there but commented out.
You're welcome to experiment with it.

There might be a case where I ask to "Purge duplicates?" after importing because of Managed Users.
I'm open to ideas.

[Tkkg1994]

I have the same SQL from our devs.

"DELETE FROM metadata_item_settings
WHERE id in (SELECT MIN(id) 
FROM metadata_item_settings 
GROUP BY guid HAVING COUNT(guid) > 1);"

When this was tested, it didn't work in all cases. Maybe it was those particular databases but also maybe not. (I'm not the sharpest database guy)

If you look in DBRepair.sh , line #1274-1284, you'll see it's there but commented out. You're welcome to experiment with it.

There might be a case where I ask to "Purge duplicates?" after importing because of Managed Users. I'm open to ideas.

Sadly I tried different things and the minus never disappeared. I'm now in contact with the writer of the article, but currently I have no news for you.. Sorry

[ChuckPa]

You may have to purge the watch history where the count < 0.

Doing this has always been dangerous.

"DELETE FROM metadata_item_settings
WHERE id in (SELECT MIN(id)
FROM metadata_item_settings
GROUP BY guid HAVING COUNT(guid) < 0);"

You might have to purge ALL the current watch history and then import fresh.

[Tkkg1994]

@ChuckPa

I have fixed the issue with the minus counts. You can include it in your script and hopefully make some people happy. See the code below

DELETE FROM metadata_item_settings WHERE rowid NOT IN ( SELECT MIN(rowid) FROM metadata_item_settings GROUP BY guid, account_id );

Right now everything looks fine but when I see any problems I'll report back.
Credits would be lovely😊

[ChuckPa]

@Tkkg1994

Is this

DELETE FROM metadata_item_settings WHERE rowid NOT IN ( SELECT MIN(rowid) FROM metadata_item_settings GROUP BY guid, account_id );

a complete replacement for

"DELETE FROM metadata_item_settings
WHERE id in (SELECT MIN(id)
FROM metadata_item_settings
GROUP BY guid HAVING COUNT(guid) < 0);"

?

where the NOT IN is the key change ?

[Tkkg1994]

@Tkkg1994

Is this

DELETE FROM metadata_item_settings WHERE rowid NOT IN ( SELECT MIN(rowid) FROM metadata_item_settings GROUP BY guid, account_id );

a complete replacement for

"DELETE FROM metadata_item_settings
WHERE id in (SELECT MIN(id)
FROM metadata_item_settings
GROUP BY guid HAVING COUNT(guid) < 0);"

?

where the NOT IN is the key change ?

This command from me is a complete replacement, yes.

Not only the NOT IN, it's a complete rework as I search for matching guid and account_id and group them, then delete all but one entry

[ChuckPa]

@Tkkg1994

Included in v1.0.10

Thank you.