Emby in Docker: full rescan messed up the `date added` metadatas

[ryancey 55]

Hi,

I recently moved my media files on the host. The new host drive is a fuse mount (previous was a real, simple hard drive) but the files have the same timestamps as before. The media paths in the container, as Emby see them, did not change.

When relaunching Emby after my files migration, it did a full rescan and it seems replaced all the metadatas. It messed up the `date added` on each item, and I rely a lot on it to organize my libraries.

The metadatas are stored on the host (custom location) and not in the media folders.

What happened? Can I get my chronology back in any way?

Thanks.

Edited March 9, 2022 by ryancey

[Happy2Play 9780]

When you do not write nfo files with media it is only stored in the database and when you move media that item is deleted and readded as a new item.

If the file maintained its creation date, then you need to ensure "Date added behavior for new content" is set to use creation date instead of scan date.  Settings-Library-Advanced.

Note this option only applies at the time the item is imported.

Edited March 9, 2022 by Happy2Play

[ryancey 55]

29 minutes ago, Happy2Play said:

When you do not write nfo files with media it is only stored in the database and when you move media that item is deleted and readded with the new path.

Even with the "custom metadata path" setting set to a custom path on the host? Also, the files paths didn't change from the container perspective. It only changed on the host, but the mapping with the container is the same, that's why I didn't expect this behavior.

 

29 minutes ago, Happy2Play said:

If the file maintained its creation date, then you need to ensure "Date added behavior for new content" is set to use creation date instead of scan date.  Settings-Library-Advanced.

Note this option only applies at the time the item is imported.

That might be my only solution so far. I would have to re-import all my files though, should I do that by creating new libraries?

Edited March 9, 2022 by ryancey

[Luke 42078]

Hi, yes and what happy2play said is correct.

[ryancey 55]

Actually I just checked and I already had this setting set to File creation date on the existing libraries before my migration.

To summarize:

• The files didn't move from the container perspective
• The files creation date is correct on the disk
• The settings didn't change
• The nfos are stored on disk (not with the medias, but in a custom location)

but still the chronology is messed up.

Creating a new library didn't solve it.

Using "real" disk instead of a fuse device yield the same result, it doesn't seem to read the file creation date.

[Luke 42078]

Hi there, can you please go over a specific example? We've been through this enough times before to know that we investigate where the value came from, we'll find it.

[Happy2Play 9780]

3 minutes ago, ryancey said:

The nfos are stored on disk (not with the medias, but in a custom location)

Metadata is written with media or only in the database only images can be saved to custom central location.  And technically those are deleted if item database item changes.

May need go over a specific example.

[ryancey 55]

33 minutes ago, Happy2Play said:

Metadata is written with media or only in the database only images can be saved to custom central location.

Oh okay, I got confused by the help text under the form (Specify a custom location for downloaded artwork and metadata.). I thought metadata was saved too as a NFO in this custom location.

An example with a random album in the metadata manager

And on the disk

And the setting is

 

NOTE: when creating a new library, I didn't delete the previous one to prevent losing artworks (some of them I needed to manually upload), so the files were still somehow indexed in the database I guess, which might explain why it didn't read the creation date. If I should delete every library referencing the files, how to prevent losing the artworks that are saved in the custom location?

[Happy2Play 9780]

I am guessing that is not the actual file creation date on that platform, but do not know anything about that platform.  I can say I do not see this issue on my Windows systems.

[ryancey 55]

8 hours ago, Happy2Play said:

I am guessing that is not the actual file creation date on that platform, but do not know anything about that platform.  I can say I do not see this issue on my Windows systems.

The platform is Linux (official Emby in Docker image). The actual creation date is december 20, 2020. Is that a bug then?

[Happy2Play 9780]

9 minutes ago, ryancey said:

The platform is Linux (official Emby in Docker image). The actual creation date is december 20, 2020. Is that a bug then?

Would be a weird bug if it only affects you, but dev or someone more familiar with the platform will have to comment further.

[Luke 42078]

It could be that the .net runtime is unable to get the date created timestamp for your file system. If that's true then the next release of the server may help with this as it updates to a newer version.

[ryancey 55]

Updating to 4.7.0.30 fixed it, the chronology is back  Lost my artworks though. Any way to recover it?

In general, is it better to store artworks & metadata with the files to prevent any kind of loss in the future? i.e by importing the medias in a brand new Emby instance.

@Happy2Play

[Happy2Play 9780]

On 3/11/2022 at 7:41 AM, ryancey said:

Updating to 4.7.0.30 fixed it, the chronology is back  Lost my artworks though. Any way to recover it?

In general, is it better to store artworks & metadata with the files to prevent any kind of loss in the future? i.e by importing the medias in a brand new Emby instance.

@Happy2Play

If it is not stored with media not likely.

Yes it is better to store images and metadata with media as it can always be reused.  Emby centralized images/database metadata is dependent on that specific database and import id.  Once a item is moved or there are database issues the item gets purged and readded as new.