Will moving content to another disk make me lose existing metadata?

[embylad892746 15]

I have a movies library consisting of 2 paths /disk1/movies + /disk2/movies. I want to replace this with /media/movies which is from mergerfs and combines disk1 + disk2 as though it is just one.

Will this make me lose all my existing metadata (e.g. preview thumbnails) or is the way that Emby links metadata to content, not dependent on file folder location i.e matches based on movie names or IMDBs?

(i'm not using nfo btw).

Edited July 18, 2023 by embylad892746
format

[Gilgamesh_48 951]

Since I store all support files alongside my media I cannot say for sure but I believe, if no scan happens while Emby cannot see the files involved, then Emby retains all support data. However, should a scan happen after the files(s) have been removed and before they are back where Emby can see them, that would cause Emby to remove all data related to the file.

One more thing, if you store the support files alongside the media and you remove the media but leave the support files Emby will not delete those support files. I do not know what happens if you delete a file through Emby and that file has locally stored support files. I suspect that only the media file gets deleted.

One more disclaimer I do NOT use individual folders for movies but I do use Emby recomended structure for TV shows.

I believe that if I delete a media file through Emby then Emby should delete all support files but that does not seem to happen and there may well be a good reason for that behavior that I simply do not run into.

[Luke 37389]

Hi, without nfo files it will essentially be a fresh start, although you may see some favorites and watch data still preserved.

[ebr 14992]

Hi.  This is why we have the option to save metadata alongside the media - it makes that media very portable.  If you don't have that option already set, note that setting it now is not going to automatically migrate all your info.  You would need to refresh metadata on everything to cause it to be re-saved in the new location.  That could be a good path for you to get where you want though.  Turn on the option, then refresh the library in question.  Then confirm the NFO and image files are with the media and make your move.

Also note that there are separate options for things like thumbnails so be sure to enable those and re-build if necessary.

[embylad892746 15]

31 minutes ago, ebr said:

Hi.  This is why we have the option to save metadata alongside the media - it makes that media very portable.  If you don't have that option already set, note that setting it now is not going to automatically migrate all your info.  You would need to refresh metadata on everything to cause it to be re-saved in the new location.  That could be a good path for you to get where you want though.  Turn on the option, then refresh the library in question.  Then confirm the NFO and image files are with the media and make your move.

Also note that there are separate options for things like thumbnails so be sure to enable those and re-build if necessary.

Thanks @ebrthis is very useful to know. I totally understand the portability option. My only concert is that up to know. The reason I didn't turn on nfo + preview thumbnails next to media is because my media is on HDDs and everything else is on SSD. I did this intentionally thinking that for performance, you would want everything metadata related on fast storage. Is my thinking correct or is it not this cut and dry? Thanks.

[ebr 14992]

3 minutes ago, embylad892746 said:

Thanks @ebrthis is very useful to know. I totally understand the portability option. My only concert is that up to know. The reason I didn't turn on nfo + preview thumbnails next to media is because my media is on HDDs and everything else is on SSD. I did this intentionally thinking that for performance, you would want everything metadata related on fast storage. Is my thinking correct or is it not this cut and dry? Thanks.

It depends really.  Were you experiencing any performance issues?  For the purposes of display, metadata is read from the database, not the NFO files - those are just backup/source storage.  Images are cached but at specific sizes so that depends.

[embylad892746 15]

3 minutes ago, ebr said:

It depends really.  Were you experiencing any performance issues?  For the purposes of display, metadata is read from the database, not the NFO files - those are just backup/source storage.  Images are cached but at specific sizes so that depends.

I've only ever deployed Emby with metadata on SSD. So i can't comment whether performance would have been worse keeping preview thumnails on HDDs. Maybe I should try first.

[ebr 14992]

Preview thumbs are not cached anywhere so they will need to be accessed at playback time.  Whether that translates to an actual issue for you, not sure. 

[embylad892746 15]

17 minutes ago, ebr said:

It depends really.  Were you experiencing any performance issues?  For the purposes of display, metadata is read from the database, not the NFO files - those are just backup/source storage.  Images are cached but at specific sizes so that depends.

i can't help but think that re-building metadata like preview thumnails should be dealt with in a more intelligent way that doesn't require re-building an entire library's preview thumbnails just because the file paths changed. This suggests to me that the backend considers the file path as the indicator as to whether a file has changed or not. Shouldn't it be something like hash of movie file + hash of metadata = cumulative hash.  --> move the file paths all you want but if the hashes are same then no need to rebuild anything since nothing changed. I'm thinking out loud.

[ebr 14992]

1 hour ago, embylad892746 said:

i can't help but think that re-building metadata like preview thumnails should be dealt with in a more intelligent way that doesn't require re-building an entire library's preview thumbnails just because the file paths changed. This suggests to me that the backend considers the file path as the indicator as to whether a file has changed or not. Shouldn't it be something like hash of movie file + hash of metadata = cumulative hash.  --> move the file paths all you want but if the hashes are same then no need to rebuild anything since nothing changed. I'm thinking out loud.

There are a lot of considerations there.  One is that just because that hash changed doesn't mean the metadata has to.  Another is that hashes are not free.  Do we really need to slow all scans and operations down to generate hashes for a situation that only happens very infrequently?  One of the top complaints we see is "my library scan is taking too long" so that is a very important consideration.

[Gilgamesh_48 951]

For what it is worth I do not use any SSD at all and I have never noticed any particular slowness in media access. In fact the only real speed improvement I have seen in testing has been in boot time but I reboot my server(s) so rarely that does not really matter.

For me I see no need for increased speed and I gain nothing of importance by adding an SSD or two. It just wastes money that could be better spent acquiring more media.

But it is people's own money and they can throw it wherever they wish.

I do wonder why it is that so many people find Emby and their computer "slow" when I do not see any slowness with my server at all.

[rbjtech 4375]

You can actually have the best of both worlds if you combine with drive pool software and use file placement rules.

I for example, use a fast nvme/ssd to store all my non media emby files - be they images, BIF's (for the thumbnails), NFO's, SRT's etc but they 'appear' next to the real media (mkv etc) on the file system.

There are other benefits on keeping the 1000's of 'small files' on the NVME as opposed to HDD - such as block size and huge latency improvements.

But I agree with the above comments as well - this is not essential by any means as even before this (keeping the files on the HDD's) performance for me was never 'slow' in the first place - but I would recommend keeping the main emby cache and db on an SSD if possible.

Edited July 19, 2023 by rbjtech