Quick Throwaway Question about Metadata

[nmkaufman 50]

First of all, loving 4.8.0.26 so far.

The refreshed UI elements are very nice, and it's great having specials back without workarounds.

 

 

I'm curious about the way emby stores it's internal/cached metadata.

Is there a functional reason metadata is stored using obfuscated paths/filenames?

eg "C:\emby\programdata\metadata\library\0b\0b0d4eaea4a4bb6d458c48caf47bbbff\poster.jpg"

I would love the ability to backup my metadata / migrate to another emby installation without having to store the metadata next to my media files.

My media is stored across 4 external enclosures / 16 disks, and I don't like the way they all get woken up when I'm browsing my library.

I would love to re-absorb the metadata/art into emby's internal folders to prevent this, but the obfuscated file/paths are keeping that from being possible.

Edited March 28, 2023 by nmkaufman

[Happy2Play 9783]

Devs will have to comment on path/filename.

Migrating to another install is easy as long as paths do not change via the new system ie move the programdata folder from machine to machine.  But once path change the written path in the database is broken and now item is lost.

So using a different path/naming scheme becomes irrelevant as moving still creates the exact same issue with recorded path dependency.

 

Should show your support for this FR.

 

[ebr 16187]

1 hour ago, nmkaufman said:

Is there a functional reason metadata is stored using obfuscated paths/filenames?

Hi.  It isn't for the purpose of obfuscating anything.  It is done in a way that guarantees that it will both be unique and be identifiable as the specific location of the target.

Storing the metadata with the media completely mitigates this.

[nmkaufman 50]

36 minutes ago, ebr said:

Hi.  It isn't for the purpose of obfuscating anything.  It is done in a way that guarantees that it will both be unique and be identifiable as the specific location of the target.

Storing the metadata with the media completely mitigates this.

That makes sense. I just wish parts of the path/folder names were at least indicative of their contents, so I could manually recover them if necessary.

I made / scanned / edited a lot of custom artwork for some of the more obscure items in my library, which would be very time consuming to replace.

They're almost always borrowing other peoples art, so I can't them upload them to TMDB to share, either.

 

42 minutes ago, Happy2Play said:

Devs will have to comment on path/filename.

Migrating to another install is easy as long as paths do not change via the new system ie move the programdata folder from machine to machine.  But once path change the written path in the database is broken and now item is lost.

So using a different path/naming scheme becomes irrelevant as moving still creates the exact same issue with recorded path dependency.

 

Should show your support for this FR.

 

That's so funny. I've already gone down the exact same rabbithole rbjtech did to try to address the problem.

It does speed things up, but drivepool still has to access every disk where that folder resides. Even if the files it needs are on the SSD.

 

I'll throw my +1 in there. Thanks for the tip.

Edited March 28, 2023 by nmkaufman