FR: Moving media causes it to be considered "new"

[brothom 177]

Moving existing media entries from Folder A (D:/Media/Movies) to Folder B (E:/Media/Movies) belonging to the same library, causes these items to be considered "new" within this library.

For example I have a Movies library:
E:/Media/Movies/
D:/Media/Movies/ 

If I move the folder "E:/Media/Movies/Apocalypse Now (1979)/" to "D:/Media/Movies/Apocalypse Now (1979)/", the entry for "Apocalypse Now (1979)" is added to the "Latest Movies" section and the "Date Added" is also changed to the moment of the move. 

I find it hard to believe this is intentional design. Am I doing something wrong or missing a step perhaps?

Edited September 24, 2025 by brothom

[GrimReaper 4739]

3 hours ago, brothom said:

I find it hard to believe this is intentional design.

It currently is. Doesn't matter if you move between folders in the same library, different libraries or just change the filename/upgrade within same folder  - Emby doesn't recognize concept of "moved" or "upgraded" item, on any of these actions item is completely removed from the db/reset and re-added as a new item. 

The only way to preserve Date Added and for the item not to be considered a new one is to write NFOs with media in which case <dateadded> tag will be respected. 

Edited September 24, 2025 by GrimReaper

[brothom 177]

1 hour ago, GrimReaper said:

It currently is. Doesn't matter if you move between folders in the same library, different libraries or just change the filename/upgrade within same folder  - Emby doesn't recognize concept of "moved" or "upgraded" item, on any of these actions item is completely removed from the db/reset and re-added as a new item. 

The only way to preserve Date Added and for the item not to be considered a new one is to write NFOs with media in which case <dateadded> tag will be respected. 

Having multiple versions (i.e. - 1080p.mkv, - 4K.mkv) merges those together, regardless of their location on whichever drive.

Wouldn't it be an idea to "wait" before removing the original entry (this should cause the entry to be merged like a version, right?) and only remove it after a set amount of time or until the library has been scanned manually?

In the time between moving and removing, the previous meta entry (with it's meta in the DB) should be preserved until the "old" file is removed right? 

Also: I manually edited the Date Added of the new items (the folder was pretty small so managable).

Maybe this thread should be moved into a FR I suppose?

[GrimReaper 4739]

2 hours ago, brothom said:

Maybe this thread should be moved into a FR I suppose?

Rename topic Title as you desire and I'll move it to FR forum. 

[brothom 177]

1 minute ago, GrimReaper said:

Rename topic Title as you desire and I'll move it to FR forum. 

I've updated it. Thanks! 

[adminExitium 355]

This is probably one of the few things Plex does very well with its concept of "Trashed Items". Items that are deleted are actually only marked as trashed and only deleted after the scan is complete if the "Automatic Cleanup of Trash" is enabled. If the option is not enabled, they are left as is in the "Trashed" state so they can be filtered upon by the users and dealt with manually (either by deleting it from the UI or restore the item in the filesystem).

Delaying the deletion allows it detect renames by matching file size, timestamps, inode numbers etc.

Edited September 24, 2025 by adminExitium

[GrimReaper 4739]

3 hours ago, adminExitium said:

This is probably one of the few things Plex does very well with its concept of "Trashed Items". Items that are deleted are actually only marked as trashed and only deleted after the scan is complete if the "Automatic Cleanup of Trash" is enabled. If the option is not enabled, they are left as is in the "Trashed" state so they can be filtered upon by the users and dealt with manually (either by deleting it from the UI or restore the item in the filesystem).

Delaying the deletion allows it detect renames by matching file size, timestamps, inode numbers etc.

You can lend your support here:

 

[adminExitium 355]

I bumped up that too, but I don't really require that explicit option. I am fine with it emptying the trash automatically, it's just that it needs to be done at the end to allow for rename detection.

If I am understanding the linked thread correctly, even this thread should be merged into that.

[GrimReaper 4739]

3 hours ago, adminExitium said:

If I am understanding the linked thread correctly, even this thread should be merged into that.

Well, they might be considered somewhat related, we'll see what's the Devs' stance whether to keep a single FR only. 

[brothom 177]

46 minutes ago, GrimReaper said:

Well, they might be considered somewhat related, we'll see what's the Devs' stance whether to keep a single FR only. 

I agree. I can see how these two issues can be considered separate, either give trashed items a delay before deletion ór only delete items áfter a scan.

Personally I would opt for the trash/delete delay as it would also prevent accidental deletions (by accidentally moving a folder, happens to me more than I would like to admit) or whenever drives are unplugged after hardware maintenance (this also happens to me sometimes, one of my sata cables is kinda broken and I always forget to replace it).

[ebr 16169]

Isn't this the same as this?

 

[brothom 177]

1 hour ago, ebr said:

Isn't this the same as this?

 

Not really, that thread is about moving within Emby but this one is about how items that are moved on the drive are immediately considered new.

[ebr 16169]

3 hours ago, brothom said:

Not really, that thread is about moving within Emby but this one is about how items that are moved on the drive are immediately considered new.

Right but, if there were a facility within Emby to effect the move or tell it about the move then that would solve your issue.

[brothom 177]

22 minutes ago, ebr said:

Right but, if there were a facility within Emby to effect the move or tell it about the move then that would solve your issue.

Not really because it's the other way around. If a folder, movie or drive disappears, it's immediately deleted if there are no others versions.

If Emby were to wait a certain amount of time before permanentely deleting an entry it would prevent unnecesarry data loss.
Maybe even add a log somewhere that the entry was deleted to warning the administrator, that'd be golden.

[ebr 16169]

What I'm saying is the other request has a variation of this discussion in it.  A facility where you could tell Emby "hey, I moved these items over here" and then it could take care of the rest.

The basic "feature" being requested here is all the same - better awareness of the "same item" (I quote because that could potentially be difficult to define) moving physical locations in the system.

This request is just suggesting a specific method of potentially achieving that.  I like to think of FR from a  higher level though instead of getting mired in potential implementations.

[brothom 177]

1 hour ago, ebr said:

What I'm saying is the other request has a variation of this discussion in it.  A facility where you could tell Emby "hey, I moved these items over here" and then it could take care of the rest.

The basic "feature" being requested here is all the same - better awareness of the "same item" (I quote because that could potentially be difficult to define) moving physical locations in the system.

This request is just suggesting a specific method of potentially achieving that.  I like to think of FR from a  higher level though instead of getting mired in potential implementations.

I agree that helping Emby detect move items would be beneficial, especially for installations without live detection.

I'd still want to argue that having a "trash delay" is more the direction I'd like this FR to head towards. Basically I'd like items to not be radically deleted on a whim but it would be nice if the action of deleting is delayed for a certain amount of time and that the admin could filter items marked for deletion within that library. Just to be sure no funny business is going on.

Would you like me to change the title of this FR so we can differentiate this FR from the other one to indicate "prevent instantely removing entries" and "helping Emby detect moved entries"?

[ebr 16169]

16 hours ago, brothom said:

I agree that helping Emby detect move items would be beneficial, especially for installations without live detection.

I'd still want to argue that having a "trash delay" is more the direction I'd like this FR to head towards. Basically I'd like items to not be radically deleted on a whim but it would be nice if the action of deleting is delayed for a certain amount of time and that the admin could filter items marked for deletion within that library. Just to be sure no funny business is going on.

Would you like me to change the title of this FR so we can differentiate this FR from the other one to indicate "prevent instantely removing entries" and "helping Emby detect moved entries"?

Okay, then that would make it a duplicate of the topic Grim linked to above...

But, the pre-requisite of that would be the concept of a recycle bin for the database in the first place.

 

[brothom 177]

15 hours ago, ebr said:

Okay, then that would make it a duplicate of the topic Grim linked to above...

But, the pre-requisite of that would be the concept of a recycle bin for the database in the first place.

 

And also not "disabling" the automatic deletion, but being able to delay it or better yet; confirm it.

In that case a filter would be cool to search for all "marked for deletion" and confirm their deletion via Emby. 

[Luke 42077]

34 minutes ago, brothom said:

And also not "disabling" the automatic deletion, but being able to delay it or better yet; confirm it.

In that case a filter would be cool to search for all "marked for deletion" and confirm their deletion via Emby. 

I guess. That does sound like a lot of manual labor though.

[brothom 177]

11 minutes ago, Luke said:

I guess. That does sound like a lot of manual labor though.

True and I suppose that would (maybe even should?) be the case when someone's drive goes bust or corrupts.

Regardless of any of that though, as @ebr the "trash function" itself first has to be built and the simplest way that I can think of would be to extend the media table with an "is_deleted"(tinyint = 1/0) column and a "deleted_at"(datetime) column.

That way any "disappeared" item can have its is_deleted set to 1 and be automatically deleted when the current_time >= (deleted_at + deletion_interval). Which in addition would also require a new deletion_interval setting. and an additional scheduled task to handle this logic.

Taking into account the scope and intention of the product I'd say it's a good QOL addition and allows for some extra functionality (i.e. searching deleted media specifically) and should also reduce the amount of posts in this forum I suppose.

Do with that information what you will but you guys decide in the end anyway.

Edited September 26, 2025 by brothom

[ebr 16169]

7 hours ago, brothom said:

I can think of would be to extend the media table with an "is_deleted"(tinyint = 1/0) column and a "deleted_at"(datetime) column.

Definitely not how we'd do it  as that would add a condition to every single query.

But, there are ways to do it although, none of them are trivial.

[brothom 177]

13 minutes ago, ebr said:

Definitely not how we'd do it  as that would add a condition to every single query.

I'm wondering how adding a column would require the backend to add a condition to all queries? The only time when it would need to become a condition is when it's being searched for either 1/0 values. The backend shouldn't care within each query if the items are marked for deletion or not, that sounds like an awful way of implementing something as minute as this.

[adminExitium 355]

7 minutes ago, brothom said:

The only time when it would need to become a condition is when it's being searched for either 1/0 values.

Exactly.

Plex shows it the same way too. The trashed items are shown in all listing like a regular item. It's only if you go to filtering, that you can choose either to exclude them or only show them.