Library Question (moving hard drives)

[Nosferatu 2]

Currently I have a large amount of media on two drives.  Their subfolders are exactly the same.  For the sake of discussion I mean on one drive it's let's say D:\Movies and the other is E:\Movies. 

 

I just bought a few new hard drives that are considerably larger.  I plan on moving all the E:\Movies to D:\Movies.  Is there an easy way for my Emby shares on the E:\Movies to get redirected to D:\Movies or am I going to have to remove all the E:\Movies and then have them all get re added under D:\Movies?

[Deathsquirrel 745]

Move your movies, run a media scan.  That's about it since in your example no pathing for the libraries has changed.

[Luke 42083]

Move your movies, run a media scan.  That's about it since in your example no pathing for the libraries has changed.

 

Yea it's really as simple as this. please let us know if this helps. Thanks !

[Nosferatu 2]

Move your movies, run a media scan.  That's about it since in your example no pathing for the libraries has changed.

 

I mean if I move my movies from say E:\ to D:\ will that cause it to lose all my saved points (e.g. which movies I watched or didn't watch or where I left off to resume).  

[Cheeseburger 8]

Think this is a bit tricky. Basicially moving a library physically but keeping the paths intact usually works without any issues, done that a few times.

 

I think there is a big risk however that Emby think that you have new movies if you change the path, if I understand your intentions correctly: the movies moved from E to D will be perceived as new files, whereas the movies that are moved from hard drive to hard drive but keeping the path of E will not have it's meta-data changed in any way. Unless Emby gets a feature to do a "library move" there is probably no perfect way for this. Anyone correct me if I'm wrong.

 

In Windows you can assign multiple drive letters for a hard drive, and software running on the machine would not be able to tell the difference, i.e. E drive could be listed as a D-drive duplicate as well. Another possibility is symbolic links where you tell windows file system to redirect file traffic from a requested location to another location, even on another disk, be it a file or whole folder. Either of these would make it possible to fool Emby - however! Since the movie folders have the same name and you seem intent on merging the folders, having two libraries set up pointing to different but in reality the same directory would mean that you did not loose anything but got duplicates of everything once the first scan was made...

 

Totally out of my depth: make a script to edit the actual Emby database, rewriting the file paths in the meta data. Maybe not even possible?

 

Or maybe you can partition the new drive with two volumes and assign it D and E respectively? Doesn't solve the long term problem of having to folders, but will save you the pain of loosing the Emby information. A similar move that is more space efficient could probably be made with Symbolic Links as well, having the real folders E:\Movies and E:\Movies 2, but telling windows that there is a virtual folder (pointing to E:\Movies 2) at D:\Movies.

 

Regardless of what you try, make sure that everything is working (file transfer done, any "fake paths" set up and working etc) before you let Emby scan, easiest is to make sure it is switched of, if not possible, disable scheduled library scans and real time monitoring.

[ebr 16187]

I mean if I move my movies from say E:\ to D:\ will that cause it to lose all my saved points (e.g. which movies I watched or didn't watch or where I left off to resume).  

 

As long as they are properly identified before and after the move, that data should be retained.

 

With something like home videos that don't have a global identification (e.g. from tmdb) then those will not be retained unless the path is preserved.

[Guest asrequested]

Drivepool to the rescue

[ebr 16187]

Drivepool to the rescue

 

Excellent suggestion.  Any drive pooling solution makes this moot.

[Dibbes 514]

I'm not behind a PC right now, but wasn't there an option to write watched status to a .nfo file in the folder?

 

I mean drive pooling is nice, but you need either Windows Server for that or Windows 10 to run this natively. Besides, you still may lose the current paths.

 

 

Sent from my iPad using Tapatalk

[ebr 16187]

I mean drive pooling is nice, but you need either Windows Server for that or Windows 10 to run this natively. Besides, you still may lose the current paths.

 

There are a number of Linux-based solutions as well (at least unRaid) I believe.

 

We have stopped reading watched status from nfo files because it caused too many problems with external programs modifying them.  As long as the items are properly identified, it shouldn't be an issue though.

[Dibbes 514]

We're going to need a list of all features that have been deprecated over the years... Lol

 

 

Sent from my iPad using Tapatalk

[Nosferatu 2]

As long as they are properly identified before and after the move, that data should be retained.

 

With something like home videos that don't have a global identification (e.g. from tmdb) then those will not be retained unless the path is preserved.

 

 

Drivepool to the rescue

 

Yes they were all properly identified.  I may give this software a try later this week.  Thanks for the heads up team!

[Nosferatu 2]

Okay I did DrivePool and made one big store.  

 

Good news - It remembered everything

 

Bad news - Kodi when I launched it now shows all the stuff duplicated (new location and old location).  What's the quick & easy way to fix this?  Should I just nuke Emby on the Kodi boxes and just reinstall them?  Is there an easier way?

[Luke 42083]

If you are referring to Emby for Kodi i would guess you'd need to run the sync process.

[Nosferatu 2]

If you are referring to Emby for Kodi i would guess you'd need to run the sync process.

 

Sync didn't help.  What did help was picking "force local database reset."  Clearing cache but keeping settings intact.  

[Luke 42083]

Thanks for the feedback.