Jump to content

migrating Emby server from macOS to Ubuntu


dance4ever
Go to solution Solved by Luke,

Recommended Posts

dance4ever

I’m planning to run Ubuntu on my mac mini instead of macOS.

Has anyone made this transition?  Is it is a straightforward process?  Is it as easy as moving the database home directory to the Linux user?

Will it be easy to map the new root directory given the entire file tree for all my movies, TV, and pictures are exactly the same?

Anything else I should know before making the transition?  Like are there any subtle differences in functionality of the server itself?

Link to comment
Share on other sites

  • 11 months later...
dance4ever
Posted (edited)

Luke: please excuse the long silence while attending to life & put my Emby explorations on hold!  You've been amazingly responsive & I appreciate you 🙏🏼 My communication style tends to lean on "leave this in my court while I GSD" so thanks also for being patient - Ill be checking in on 2 or 3 other open loops here as I have bandwidth.

Good news is I've since been successful rebuilding our server and transition from macOS to Ubuntu Server 22.04.4 LTS.  I drank from the firehose & learned Docker & loved how easy it was to get Emby up as a service.  (Got some wonderful help from the peeps on DevOps StackExchange for anyone who tries to translate the Emby docker run command to docker compose)

My first instance of Emby moved over great with no issues.

My second instance of Emby that is super heavy on custom metadata was lossy.  Some favorites & resume times were transfered and some were not.  I tried to make two different snapshots of the database while it was shutdown but it was still a "lossy" transfer.

I don't recall where I posted the feature request but I also tried to dump the metadata into new .nfo files and even though I have the nfo metadata handler checked, the Ubuntu Emby instance didn't import the .nfo metadata & seems to be paying attention to metadata in its database instead.  For future reference, is there a way to force Emby to import all .nfo metadata?

I started to wonder if indexing hundreds of photos was impacting the database so I decided to delete the Photo library & stick to videos.  This seems to have made the server more stable.  Is there a clean way to ask Emby to rebuild it's database?  I thought the "vacuum" option might work but I think it ran for a few milliseconds so it must not have had much to do!  I just want to make sure the database is clean of any possible problematic references to my old photo library.  Ideally, Id love to initialize the database using my .nfo files as  baseline metadata if this is possible.

Outside of the metadata blips, both Emby instances are up & running well on Ubuntu!

Thanks again to your team for all your hard work - I've noticed of all the media servers I've evaluated, Emby pays a lot of attention to small delightful QoL features both on the user & especially the admin side of things that allow us to overlook a few quirks here & there :)

Edited by dance4ever
Link to comment
Share on other sites

Quote

For future reference, is there a way to force Emby to import all .nfo metadata?

When an nfo file changes, just run a normal library scan and the server will pick up the changes. Beyond that, there's no way to do this for existing content. 

Link to comment
Share on other sites

Quote

Is there a clean way to ask Emby to rebuild it's database?

Not really other than deleting the library.db file, but then you'll have quite a bit of things that will need setting up all over again after doing that.

Link to comment
Share on other sites

dance4ever
12 hours ago, Luke said:

When an nfo file changes, just run a normal library scan and the server will pick up the changes. Beyond that, there's no way to do this for existing content. 

are resume times & favorites stored in the database?  can you think of any reason why resume times did not get migrated for over 2/3rd the items?

Its a non-issue now that I've manually restored the metadata but it would be good reference to know for a future migration what the most reliable way to retain the metadata is.

12 hours ago, Luke said:

Not really other than deleting the library.db file, but then you'll have quite a bit of things that will need setting up all over again after doing that.

I haven't gone crazy on custom settings so if it's just setting up the libraries again, this is okay as long as Emby imports all the metadata in my nfo files which I've verified to be correct (and have the metadata I'm looking to preserve like tags, watched status, favorites and resume times)

I have a lot of custom identifications & images that I have Emby store next to the nfo files & assume these will be picked up as well.

I know I had to tinker & transform many of the XML files to get my playlists & collections back up because macOS & Linux mounts the same drive under different pathnames (eg. /Volumes)

Link to comment
Share on other sites

Quote

are resume times & favorites stored in the database?  can you think of any reason why resume times did not get migrated for over 2/3rd the items?

@dance4everif metadata changed from the old system to the new, then yes, this could be why.

Specifically if any external id's from a movie or series are different than before.

Can you please provide a specific example? Thanks.

Link to comment
Share on other sites

  • 2 weeks later...
dance4ever
On 4/9/2024 at 2:31 PM, Luke said:

@dance4everif metadata changed from the old system to the new, then yes, this could be why.

Specifically if any external id's from a movie or series are different than before.

Can you please provide a specific example? Thanks.

hey i just want to close this loop.   Let’s pick up this ball the next time I encounter this issue during a migration so I can capture the exact behavior and state a specific example.  While it was quite the meditative exercise, I restored all the resume points and favorites by hand.

  • Thanks 1
Link to comment
Share on other sites

dance4ever
Posted (edited)
1 hour ago, dance4ever said:

Let’s pick up this ball the next time I encounter this issue during a migration so I can capture the exact behavior and state a specific example. 

This ball was picked up sooner than I thought :)

in an attempt to migrate from what seems like a possible corrupt install, I decided to try importing metadata and inserted an example you requested in a new thread as I want to keep the issues separate and I’m no longer migrating from macOS :)

Edited by dance4ever
  • Thanks 1
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...