Moving content changes watch status

[sudo72f 2]

Dear Emby Community,

I am looking more for a recommendation on how to handle moving content then reporting a problem with the media server itself. It could be that I am missing a setting only...

My movies and tv shows are indexed properly and have a watched / unwatched status set. The content is spread among several disks / shares in a NAS (e.g. movies_4k_1, movies_4k_2). When one disk is getting full, I of course have to move some content to another disk. As soon as I move just one entry to another disk, after scanning the library, it shows up as a "new" movie and the watch status is reset to "unwatched". With JellyFin I was able to handle this moving since it somehow knew that just the location for this movie changed (NFO metadata, images etc. are all stored within the movie folder) - I assume there were some additional information stored in the database, but I cannot confirm it of course.

How do you guys handle this? Are you experiencing the same? Is there any special order which I need to keep so that the moved content will not be recognized as "new"?

Thank you in advance for any help!

Greetings
 

[Abobader 3469]

Hello sudo72f,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[rbjtech 5284]

Watch status on items should be tracked by the Provider ID (tvdb, tmdb etc) and thus it should not matter at all 'where' those items are.   I have moved items countless times, and never had an issue.

So #1 question - do the items in question have a valid 'Provider Id' in their metadata ?

If yes, then it's worth testing just a single item, move it to another area, let it re-find the item - and the 'watch' status for that item for that user, should be exactly the same.

If the item does not have a Provider ID (lets says 'home video' for example) - then emby has no way of knowing if it's unique or not - and thus, moving that type of media will result in it creating a new 'watched' status for it.

[sudo72f 2]

Thank you very much for the quick answer.

Yes, the IDs are properly set for the items I am moving (screenshot attached). I just tried it with two different items individually (both have the IDs set before and after moving), but the watch status gets reset.

I tried turning off the automatic change recognition in the file system structure, since I thought that this might interfere somehow, but it did not help either. In the embyserver.txt logfile I can also see, that the file "Oben_2009_BDRIP.mkv" gets deleted and inserted again while changing from share media_4k to media_4k_4 (if I understand the log file correctly).

My version is btw. 4.8.0.44 beta by the way, forgot to mention that.

 

embyserver.txt

Edited September 4, 2023 by sudo72f
wrong screenshot attached

[ebr 16187]

Hi.  Make sure a library scan has completed after the move occurs.

[rbjtech 5284]

2 hours ago, sudo72f said:

Thank you very much for the quick answer.

Yes, the IDs are properly set for the items I am moving (screenshot attached). I just tried it with two different items individually (both have the IDs set before and after moving), but the watch status gets reset.

I tried turning off the automatic change recognition in the file system structure, since I thought that this might interfere somehow, but it did not help either. In the embyserver.txt logfile I can also see, that the file "Oben_2009_BDRIP.mkv" gets deleted and inserted again while changing from share media_4k to media_4k_4 (if I understand the log file correctly).

My version is btw. 4.8.0.44 beta by the way, forgot to mention that.

 

embyserver.txt 7.74 kB · 2 downloads

Hmm ok - I've just tested this myself - moved a TV series with watched items out of emby, scanned to ensure it was 'gone' - then moved it back in again, and the watched status for all the episodes were still there (as I expected them to be).

I'm not sure why yours is losing them .. as Eric says, make sure you do a scan, as while Real Time Monitoring 'should' identify the changes - sometimes it needs a full scan to correct things.

If viewing in a browser, it would also be worth doing an F5/Refresh - just to check your browser is not playing tricks on you with the watched status.

Edited September 4, 2023 by rbjtech

[sudo72f 2]

Thanks to both of you for the hints. Unfortunately no positive results after trying all of the suggestions. Attaching a debug logfile, but as far as I can read it, there is nothing suspicious. Scan of library took 38 seconds, I even waited approximately 15mins afterwards to check the status.

Although JellyFin did not have a problem with this, could it be that a remote share is causing this? I have Emby installed on a separate NUC client which is connecting to the remote shares on my NAS (and thus might not have direct access to the filesystem). On the other hand, if you say that the watched status is stored according to the provider ID in the database...

embyserver.txt

[sudo72f 2]

I cannot edit my last post, which is why I have to create a new reply. I think I found a few clues which lead to the situation as described before:

As told, once I move the movie to a different location, it will get the status "unwatched" - or basically it will be handled as a new movie in the database. I noticed, that the NFO file - which was present already - gets renewed or updated (see screenshot). I then tried to move that same movie to the initial location back, and it was properly recognized as "watched" already. I also moved it to a third location, just to make sure that it is regardless of the location, and it was still recognized as "watched".

So something is happening when moving it in the first place. After comparing the NFO files from before the first move and after the first move, I can see that some changes were written. I initialized the database with the stable version, but after having problems with the transcoding I had to update to a beta build. Maybe I will have to reinitialize my whole database?

[rbjtech 5284]

NFO's shouldn't make any difference, as watch state is not held in the NFO's.

It should not need it - but have you tried moving a 'watched' item - and then running both the tasks below ?

If you have premier, then it would also be worth using the backup/restore - and see if you can restore the watch state onto a new instance .. but this involves a bit of work and also some risk.

As a side note, I would also look into 'drive pooling' software - as this would then eliminate this problem in the first place - as all drives would appear under a single drive letter ..

 

[sudo72f 2]

Tried your suggestion, but it still gave me the unwatched state afterwards. Backup and restore is indeed a bit of work which is what I want to avoid. But I think I found a solution for my problem:

I can confirm now, that after refreshing the metadata (and thus writing a new NFO file) the watch state will be kept when moving the file. I understand that the watch state is not written in the NFO, but somehow emby seems to think it needs to handle it as a new file maybe?

My theory is the following:

Either the NFO files from the stable version are different than the ones from the beta and lead to emby think that it needs to write the data again. When I take a movie that was indexed with the stable version, I have the "false" behaviour as written above. But when I move a movie that was indexed with the beta version, then the behaviour is as expected: the watch state will be transferred to the new location. I was able to reproduce this multiple times.
Alternatively, but this I cannot confirm, maybe the NFO files were still from JellyFin. But that would not explain why they all received the datestamp when I installed emby and started to add them to the database.

Either way, for now my solution looks like I have to refresh the metadata and get a new NFO file written for all entries.

Edited September 4, 2023 by sudo72f

[Luke 42083]

Essentially you need the external id's in the metadata editor to match what it was before in order for your watch states to be utilized.

[rbjtech 5284]

16 hours ago, Luke said:

Essentially you need the external id's in the metadata editor to match what it was before in order for your watch states to be utilized.

Agreed, and that's what I said in my first reply, but - the crossover from stable to beta and possibly NFO's seem to be messing with things.  But I believe the OP now has a workable solution.

[Luke 42083]

@sudo72fhas this helped?

[sudo72f 2]

@LukeRefreshing metadata of the complete library indeed helped. Was testing afterwards with moving a couple of items around, and they kept their watch status. Topic can be closed / I will mark this one as the solution.

Greetings