Found inconsistency in the following files while validating database

What you could try is to remove that line from the Blockset table, and see how it reacts… But, backup of the DB to be sure…

(Try it at your own risk! No guarantees…)

That might make sense. It seems to be the only reference to that blockset.ID. I notice that the original error message said:

System.IO.InvalidDataException: Found inconsistency in the following files while validating database:
/Volumes/Storage/Media/Movies/BlahBlah.mp4, actual size 2765141701, dbsize 0, blocksetid: 1356
. Run repair to fix it.

and the entry in the Blockset table shows the same length. Looks like this line might be the culprit. Not sure how it got broken (if, indeed, it is broken).

I’ll try backing up the DB removing the offending line and re-running repair and backup. I’ll keep you posted.

I guess this should come as no surprise.

Looks like we broke something (else). Restoring the database and awaiting @kenkendk and his wisdom.

Meanwhile, I have this folder backed up elsewhere, so I’m ok for now (if the house doesn’t burn down).

Last suggestion, as there are other entries with 1356 as BlocksetID indeed:

DELETE  FROM Blockset WHERE ID = 1356;
DELETE  FROM BlocklistHash WHERE BlocksetID = 1356;
DELETE  FROM Metadataset WHERE BlocksetID = 1356;
DELETE  FROM File WHERE BlocksetID = 1356;
2 Likes

I tried deleting rows from database, but it ended with more problems. Finally I recreated the database (which took long) and now everything seems ok. I will post again after backup finishes

Good News! With the records deleted, a run of the backup has now passed through the consistency check and is on to verifying backend data. Looks like this might have done the trick. Thanks for your help @Wim_Jansen. I’ll keep you posted on how things progress.

2 Likes

Fingers crossed… let’s hope all goes well!

I have added an issue on github to keep track of this.

The backup has been running for 24 hours now, but it still showing a status of "Verifying backend data… ".

Digging into details, I see that the mono process is consuming 100% of one cpu core of my relatively squirrel powered Atom 330 processor. I’m not seeing any network activity related to backend communications.

Does anyone know if this is normal behavior or what is happening during the verify process? The fact that it’s verifying backend data, but not accessing the backend is a bit of a flag for me. I’m wondering if something is caught in a loop due to the database manipulations I performed.

You can check in “About > Show Log > Live > profilng” for detailed logging. Could always be a query that has been running for a long time…

I’ve tried that. I get a message indicating the server started and is listening. Then nothing. In the past (before canary switchover) I’ve let it sit there for hours with nothing coming up during a backup.

image
image
Been monitoring for an hour and a half now.

Definitely stuck. I killed the server and restarted the computer last night. Re-started the backup and captured profiling logs. Shortly after starting the “Verifying backend data” process, the logs stopped. The log entry looks similar to an entry I saw in a bug report. I will be moving this to that bug report.

Thanks for your help, @Wim_Jansen. I suspect we solved problem number 1. Now on to problem number 2.

Thanks for this. I ran out of disk space which caused a backup job to fail.
Then I got the error message
Mono.Data.Sqlite.SqliteException (0x80004005): Abort due to constraint violation
columns BlocksetID, Index are not unique

and

Found inconsistency in the following files while validating database: /data/filename.dat, actual size 2037617077, dbsize 0, blocksetid: 1516 . Run repair to fix it.

I ran the 4 delete statements and now everything is working fine.

1 Like