[ERR] Guide database failure: merging err: merging failed: invalid address 15/491094

23 lines like this in the dvr log from this mornings guide update

2022/01/28 09:38:29.272834 [ERR] Guide database failure: merging err: merging failed: invalid address 15/491094

Running latest prerelease version 2022.01.27.0906, but you can probably see that in the logs.
Logs have been submitted as 6e4d3908-9e1d-466f-9c47-5aa719c72c8c

Just did a Delete and Recreate Database.
No errors on that.

I marked this as a self fix.
Guessing it was corrupt guide data and/or a corrupt database.

These 10 errors in the log from the guide update this morning

2022/01/29 09:30:58.657559 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:31:17.294908 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:31:30.818580 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:31:41.208026 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:31:51.181798 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:32:01.412359 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:32:07.303353 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:32:12.909010 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:32:18.415165 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input
2022/01/29 09:32:21.564941 [ERR] Guide database failure: merging err: merging failed: snappy: corrupt input

Logs have been submitted as d6c4df4f-f340-4782-9bc6-81912c34711d.

I did a Save Database Backup in case you need it before doing a Delete and Recreate Database
2022/01/29 09:53:43.870398 [SYS] Created database snapshot: backup-20220129.095343

Another dvr server with the same source doesn't get these errors.

If it's getting corrupted repeatedly it means there is some kind of hardware failure happening. Might be RAM going bad or disk failing.

I was thinking snappy: corrupt input meant corrupted guide data coming in.
Also both times when I did the Delete and Recreate Database it worked w/o errors.
NAS disks are healthy. I'll reboot the NAS and see if there's a way to test the RAM.
This dvr instance is a Synology DSM 7.0 package install.

Update: I disabled memory compression in the Synology NAS settings and rebooted it.
Disk and Ram are fine.
If it happens again, I'll move the dvr to a docker container as those are working fine on this NAS.

snappy is referring to the on-disk compression being used by our guide database. It is unrelated to where the guide is coming from.

It means we wrote data to the database and when we tried to read it back, it was corrupted.

The common reasons why a database was corrupted are:

  • A forced shutdown of the DVR process while it was in the middle of writing
  • The data that was written to the disk was garbled (bad RAM)
  • The data that was read from the disk was garbled (bad disk)
1 Like

Thanks for the excellent explanation.

This may be a factor, time will tell. My other Synology NAS also has this enabled but not getting the error.
The docs don't say how this is accomplished technically.

Memory Compression

You can enable Memory Compression to improve general system responsiveness under load by compressing the least recently used data in memory.

When you have multiple applications running and the memory begins to fill up, the dynamic Memory Compression shrinks the size of seldom-used items in memory, minimizing memory usage. When the items are needed again, they can be instantly uncompressed. This reduces the need to read and write memory swap files on disk, improving efficiency and responsiveness.

To enable Memory Compression, simply tick the checkbox.

https://kb.synology.com/en-me/DSM/tutorial/How_can_I_run_a_memory_test_on_my_Synology_NAS

1 Like

Thanks, will give that a try.

Well, turns out that memtest found errors on 3 out of 4 runs.
Had to do some searching to find the results are logged in /var/log/messages.
If it's the 2GB soldered onto the motherboard, I'm SOL unless I want to pay Synology to fix it.
I plan to remove the socketed add-on 2GB SODIMM module I purchased with the NAS 8 years ago.
Clean the contacts and run memtest with it still removed to see if it's the 2GB on motherboard failing.
Then put the SODIMM module back in and run memtest again in case it was a bad connection.
I can always buy another 2GB SODIMM module.

Meanwhile it's still running and no errors during the guide update this morning.

Told ya so :grimacing:

1 Like