Mezzmo: Display of existing video thumbnails broke after backup restore on new system

Hello,

I had to reinstall my Windows 10 a couple days ago and restored my Mezzmo Pro Library via a recent backup created by the app.
But no video thumbnails of my media library are shown anymore (in the Mezzmo App, as well on any connected DLNA device).
The only images shown in the Mezzmo App are folder backrounds (...\Artwork\Backdrop).

If I add new video files to the folders the library is scanning, Mezzmo is generating proper file thumbnails as it always did. But existing files are still shown without there previews.
"Missing" thumbnails are also not getting updated when I visit the folder in the app, where the video file is located, because the thumbnails in fact exist, they simply don't get displayed (...\Artwork\Poster is filled with 10k's of images)

What I have tried so far:

• Selected delete cover image in some affected file properties, to force generating new ones
• Started Maintain Library and let it run for 2 days till it sorts of got stuck and only produced TBs of network traffic doing nothing useful (see below)
• Deleted VideoPreview.dll and Artwork folder, another library maintenance (got stuck at around 4k previews of around 22k files doing nothing for the rest of the day, aborted and restored from backup again)
• Set access rights of Mezzmo Library folder to user “anyone”
• Running Mezzmo as windows process (w/o admin credentials)
• Run Mezzmo App as admin

How can I get the thumbnails of my existing video-files showing up again?

BTW: Why does the maintenance process takes multiple days (back on the old system where all was working, no preview updates selected) when the files are stored on a Synology NAS connected via Gigabit Ethernet?

Hi,
we had another user with a similar problem, did the path to the Mezzmo database change when you restored your backup? The path to the posters is stored in the database and gets updated when you move your Mezzmo database but if you restore it to a location different to the previous location then the path to the posters will not be correct. You can view this using SQLite Spy or another sqlite viewer and run an sql query to update it or use the Maintenance tools in Mezzmo to search and replace for the path and update it.

That is indeed the case. The Mezzmo Database was stored on "E:\Mezzmo Database" on the old Windows installation.
I restored this backup to "I:\Mezzmo\Database" onto an SSD-drive to boost the database access time.

The maintainance tools in Mezzmo only work for media files stored in the Mezzmo Database itself. They don't seem to alter internal database entries of absolute paths.

So if I understood you correctly, I need to do the following:

1. restore a backup to the old path "E:\Mezzmo Database"
2. Use the move database feature inside the Mezzmo App to move the whole database to the new path of "I:\Mezzmo\Database"

So this will also update the absolut path for the thumbnails stored in the SQLLite-DB from "E:\Mezzmo Database\Artwork\Poster\..." to the new path "I:\Mezzmo\Database\Artwork\Poster\..."?

Yes this is correct, if you can restore it to E:\Mezzmo Database the thumbnails will show up correctly then you can move the database using the Options in Mezzmo to I:\Mezzmo\Database

Ok, so did what you recommended. The thumbnails still not showed up after transferring the database using the Mezzmo tools from the old to the new path. Only Backdrops worked, as before.

It's getting technical now:

So I looked into "Mezzmo.db" with "SQLLite Spy" and found out that, TABLE MGOBackdrop was updated correctly with the correct paths.

On the other hand, TABLE MGOPoster had only updated the last row (highest ID) with the correct paths, all other rows had the old path :confused:

So, I executed the following SQL statement to fix the other rows:

Code:

---

UPDATE MGOPoster
SET Path = REPLACE(Path, 'E:\Mezzmo Database\', 'I:\Mezzmo\Database\')
WHERE Path LIKE ('E:\Mezzmo Database\%')

---

This updated only the first around 10k entries, then it stopped with an SQL 19 Error - a UNIQUE Constraint violation of the tables INDEX:

Code:

---

CREATE UNIQUE INDEX Index_MGOPoster ON MGOPoster (Path);

---

DROP'ing the INDEX fixed that, but the INDEX could not get created again because of the still violated constraint. Also I don't know how the Mezzmo DB would handle that, my last SQL sessions during my study are to long ago and I don't work on the low end level of databases very often now. So, I restored the backup of the "Mezzmo.db" and did another approach.

I DELETED only the ROW with the one correct path (with the last/highest ID) and executed the SQL statement to fix the paths again and it run through without the error.

Now the Thumbnails seem to work as they should.

So it looks like the Mezzmo tools that change the database paths during your migration process created an inconsistent state of the TABLE MGOPoster, that resulted in this operation getting aborted.

Another question:
I also noticed there is a huge amount of old database entries containing old file paths to files that no longer exist. These are basically files that have been moved from local disks to the NAS, all using the Mezzmo tool to fix the path inside the app after they have been copied to the NAS. That only worked half way, because a lot of files where considered as new when starting the maintenance library process.

Therefore, there is also a huge number of unused images for these files in the ".../Artwork/..."-folder. It’s now almost 25 GB huge and probably only 1/4 of this is still relevant.

Is there a maintenance option in Mezzmo to get rid of all these abandoned data?

Selecting the option "remove files not found during the maintenance process" seems not to remove these old entries and artwork form the DB so its growing over time. No wonder the maintenance process takes days to complete.

Compressing the DB with the Mezzmo Tools did nothing but give me 86 MB less from a normaly 2 GB "Mezzmo.db". Also zero change to the mentioned abandoned database entries and the obsolete thumbnails in the Artwork-folder.

If you run Maintain Library from the toolbar or the menu with the option to remove files that cannot be found on disk selected it will remove the files. Right-clicking on a folder and Maintaining the folder will not remove the files with the option to remove files that cannot be found on disk selected because when maintaining a folder Mezzmo just gets the list of files in the folder and any files that do not exist are not processed.

Yes, I did run several Maintenance processes and they removed deleted files from Mezzmo (Frontend). But what stays is the artwork found in “…\Artwork\Backdrop” and “…Artwork\Poster”. They are also kept in the database. Please see the following screenshot:

Attachment 1124

This is one example file from my Mezzmo DB. There are two references for the artworks “Poster” and “Backdrop”. As you can see, there are two files with the same name, but different paths. “disk-e” was the old path on the pc. “disk—192-168-2-108” is the new path on the NAS. The file with the path “disk-e” is no longer in the Mezzmo DB, but it’s artwork is still stored in the database but is not used, as you can see in the last part of the image. Despite of the fact, that the [Poster/Backdrop]-ID is no longer linked to a file of MGOFile, Mezzmo is not deleting the file.

Add this up to a huge database where you moved almost all files to a new location (NAS), sometimes even multiple times before I had the NAS. You generate a lot of garbage that is bloating up the Artwork-Folder with no longer used posters and thumbnails. They don’t get deleted, because there are still managed by the Mezzmo DB, despite the fact not being referenced to an actual file.

All I am asking for, is to please add a fix to the maintenance process, that deletes dead artwork entries in MGOFile and therefor also deletes the no longer managed images.

Mezzmo re-uses poster and backdrop files for multiple files, so if you have two files in the database that use the same backdrop and poster then Mezzmo will not delete the artwork until both files are removed from the library. This saves space where you have multiple episodes of a series they will use the same artwork.

Quote:

---

Originally Posted by Peter

Yes this is correct, if you can restore it to E:\Mezzmo Database the thumbnails will show up correctly then you can move the database using the Options in Mezzmo to I:\Mezzmo\Database

---

I ran into this problem, and issuing the procedure above, it did fix the icons within the Mezzmo program, but the icons are still missing on my Roku's.

I tried using the maintain database from the toolbar, but it doesn't fix the problem.

Any idea how I can fix this?

Thanks,

Ron

It could be a problem with the transcoded files, posters are transcoded for devices to adjust the size so you will need to check to see if the path to the transcoded files is correct.

If you're referring to the path in the pulldown transcode screen, yes it seems correct.

The strange thing is some are now showing, and some are not. On the screen it shows a white box with a grey box in the middle and an asterisk in the center where the icon should be.

It could be a permissions issue, can you please enable diagnostic logging in options in Mezzmo then after restarting your Mezzmo media server try browsing the files on the Roku and then send the logs to support [at] conceiva [dot] com so we can investigate.

OK, I got it fixed.

There were 3 issues. When changing (moving) the database to a new drive, The Mezzmo database does not correctly update the paths in the following areas: MGOBackdrop and MGOPoster
This caused the Icon/Thumbnails issue.

Using PixelAviator instructions, code (Thanks PA), and SQLiteSpy, I got the paths corrected. This fixed the images/thumbnails in the Mezzmo windows program.

The problem with the Roku icons was caused by a corrupted Device profile or something along those lines.

I discovered this while testing some of my other Roku's, and They were showing the correct icons.

Once I switched profiles, and restored the original profile, The Icon problem was fixed.

Although the problems are not likely related, There does seem to be a problem with the backup/restore/move database function. Maybe this is Windows 10 related?

BTW, I'm never moving the database again..LOL

Glad to hear you have resolved the problem, we have had a few users report this issue but have not been able to reproduce it here yet. When the database is moved using the field in options the MOGBackdrop and MGOPoster tables are updated but there may be cases where this does not happen.

Thanks Peter,

Just to be a bit more clear.
This happened while using the tools\options\mezzmo database location.

The Media files themselves where not moved, so I did not use the Tools\Maintain library\options.

When I changed it from it's original place on the "G" drive to "C" drive, That's when it went downhill.
It prompts if I want to move the database to the new location, I selected "yes"
It seems to work ok, but when restarted, all the icons are messed up.

I changed it back to the "G" drive again, and that fixed the icons as you outlined in the post.

I tried it a second time, and I got the same results. That's when I checked with the SQLiteSpy and found out what happened.

Still have some issues I think.

Last night, I ran the tools\maintain files\ with the following settings: "Update all attributes"
and "Remove files not found" settings ticked, and the icons were messed up again.
I did this to clean up any loose ends from the Database move. Guess that wasn't a good Idea.

When troubleshooting, I discovered that the Artwork\Posters file was reduced from 600+ MB to 105MB or so.
Once I restored the Posters directory and contents, The problem was fixed again.

Should this have happened? or do I still have an issue with the Mezzmo database?

TIA,

RB

Did you have the option to update artwork selected? If you did then this will remove the existing artwork and replace it so this could be the problem. If you run Maintain Library again does the Posters folder get reduced again?

Yes, I had update artwork selected.
But the artwork was deleted, not replaced. It changed most of them to what looks like folders.

I did not run it again for fear of the same thing happening again.

I also ran into another problem with a few icons that were messed up on the Roku, but looked OK in the program. The only way I could fix them was to deleted them in the program, and then replace them manually.

I'm not sure what's going on, but it looks like I may have to start with a fresh copy and rebuild it. Not ideal as I have a pretty big collection, but it looks like something may be corrupted.

Could you add your Mezzmo.db file to a zip and send it to support [at] conceiva [dot] com so that we can investigate?

Thanks for the kind offer, but at this point it seems to be getting better.

I will try again Monday to let it run with delete files not found, and see what happens.