Jump to content

Emby Server - Preserve Watched Status of External-ID-less Files (such as Extras) When Moved


funwithmedia

Recommended Posts

funwithmedia

Per another thread ( https://emby.media/community/index.php?/topic/38173-watched-status-resets-with-moves-between-library/&do=findComment&comment=484965 ) video files that do not have an external ID (eg, TheMovieDB, IMDB) associated with them in Emby will lose their Watched status if you ever move the files to another location. This is because currently the only way to determine the uniqueness of the file (if it does not have an external ID) is to use the full path to the file.

 

Now, most items will have an external ID, but the big exception can be Movie Extras and TV Specials. Some TV Specials will have an external ID. And some Movie Extras do exist in the IMDB and TheMovieDB, but currently there is no metadata lookup available for Movie Extras ( https://emby.media/community/index.php?/topic/43845-emby-server-emby-theater-support-nfo-files-and-automatic-metadata-lookup-for-extras/ ). So if a Movie and it's associated Extras is ever moved, the Watched status for those extras will be lost.

 

This feature request is for there to be some better method of identifying files such that those files which do not have external ID's can still be correctly identified (and thus Watched status preserved) even if they are moved. I am most interested in this for Movie Extras.

 

I'm not sure what the best route for achieving this would be, but wanted to put the idea out here for consideration.

 

Thanks!

:)

  • Like 1
Link to comment
Share on other sites

nfo is probably the best route, but nfo is only designed to hold watch data for one user. we'd probably want to add something proprietary into the file to hold data for all users.

Link to comment
Share on other sites

jnheinz

+1 to this.  I had to manually migrate my watched status for stuff like this.  This applies for sporting events too -- no external ID.  Even if were just the file name or an arbitrary ID generated for these, it would be better than the full file path. 

Link to comment
Share on other sites

+1 to this.  I had to manually migrate my watched status for stuff like this.  This applies for sporting events too -- no external ID.  Even if were just the file name or an arbitrary ID generated for these, it would be better than the full file path. 

 

What arbitrary ID could be tied back to the item when it is moved to another location?

 

The issue with trying to save this data with some other (not truly unique) ID would be that it would then make it possible for the watched data to be overwritten by something else that somehow matches the same ID.  IMO that would be a worse outcome than the issue here (which should be quite rare).

 

As far as saving in nfo, well, we've been down that path before and had to disable it due to all the problems we had with other programs wiping that data out and then people reported that Emby had "lost" their watched status.

 

So, I'm just not sure there is a perfect answer here but we are definitely open to ideas.

Link to comment
Share on other sites

jnheinz

The ID would have to have a prefix that would be unique to this endeavor.  Not just a random hash.  Definitely makes Emby feel a little less portable when watched status for everything can't be transferred.  Migration woes.

Link to comment
Share on other sites

The ID would have to have a prefix that would be unique to this endeavor.  Not just a random hash. 

 

That's what we have now.  It isn't a random hash it is something we are positive will relate to that exact file.

 

There is probably a way to skin this cat though and we don't have to discuss implementation specifics here.  Luke and I would have to figure it out if there is enough support for this feature.

Link to comment
Share on other sites

funwithmedia

Glad to see there's interest in this. And I totally agree with the various points regarding the challenges of implementing this.

 

A thought I'll throw into the mix: If we created a hash value of each file (using something like http://corz.org/windows/software/checksum/ ) we could be certain of the identity of the file (if we use a hashing algorithm that is free of collisions). The obvious downside of this is that this process is computationally expensive (especially the larger the file gets). So perhaps when a file is added (that has no external ID) it would start with the current location-based id, but then there could be a periodic server process/task that goes through and creates hashes of those files which then becomes the new, permanent ID (and we'd probably want to provide the user with a way to force this process manually). Then, if it finds that a hash-ID already exists in the DB it associates that already present DB data with this file. I would recommend the DB be setup such that if a user chooses to have multiple instances of the same file (which I've run into a few times with certain DVDs), which would thus all have the same file hash, that they all get linked to the same DB data (eg, If I watch the Extra in one place, it makes sense for it to show as Watched when a copy of the same exact Extra file is in another location).

 

Obviously, all of the above could be much further refined. And if it is helpful I'm certainly happy to brainstorm further with folks (I like finding creative, workable solutions to things). :)

Link to comment
Share on other sites

jnheinz

That was actually my first thought, an MD5 checksum or something similar.  Maybe could be performed using a scheduled task to mitigate the barrage of disk activity to generate the checksums at undesirable times?  As @@funwithmedia suggested, I am just brainstorming too.

Link to comment
Share on other sites

Using a file checksum (as well as slowing things down) also will then lose the data when you replace the file with one of a different quality.  I think that is probably more likely than the situation we are trying to solve here (moving everything to new locations).

Link to comment
Share on other sites

funwithmedia

Using a file checksum (as well as slowing things down) also will then lose the data when you replace the file with one of a different quality.  I think that is probably more likely than the situation we are trying to solve here (moving everything to new locations).

Fair point. I hadn't considered that.

 

Perhaps we're coming at this all wrong: Maybe instead we should be thinking about having a method/process whereby we can tell Emby, "Hey, I'm moving these files to this location -- please keep track of them"? I'd have to think some about how that might work, as I think a typical user behavior is to just move their files (independent of Emby) and then only go into Emby Server if something hasn't worked right with the move (ie, lost Watched status). Perhaps if there could be a user setting to have Emby retain data for old/missing items for a user-defined amount of time. And then we could use that data in conjunction with some sort of dialog for matching up moved items manually to old/missing items in the DB. That sort of manual process would go most quickly the less parts of the path one has changed (eg, if you've only changed the root, but not the later parts of the path, in theory you could match up larger batches at a time).

Link to comment
Share on other sites

  • 3 months later...

​It would be very useful if Emby detects moved files (files that are moved within the library folders). It seems like I loose the watched tag of a movie that I watched  if I move the file to some another place :( So now I rtefrain from reorganizing my library because I am afraid that I will loose my stats.

Edited by bigeyez
Link to comment
Share on other sites

We store watch data based on things like IMDb and movie db IDs. As long as the metadata remains the same thing should be able to move movies, TV and music.

Link to comment
Share on other sites

​Well, I never watch movies, shows, tv etc. I use Emby to watch some tutorials I download from Youtube and such. Does that mean that moves cant be detected?

Edited by bigeyez
Link to comment
Share on other sites

yea those will be a little more difficult. storing watch data in nfo is always possible, although we've been down that road before and had problems.

Link to comment
Share on other sites

​Can the files get hashed to be uniq so it does not matter where they are?

 

yea those will be a little more difficult. storing watch data in nfo is always possible, although we've been down that road before and had problems.

Edited by bigeyez
Link to comment
Share on other sites

Why not provide moving mechanisms in the Emby (akin to delete) gui for now, until a better way is figued  out? That way Emby will already know the files are moved? So we would need some rudimentatry move and rename kind of thing.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...