Library is lost and must be rescanned if network shares aren't available at startup

[displayname0504 24]

This may be a niche case, but I had it happen twice in a night.  After a power outage, (after battery backups were exhausted), everything came back up, but Emby was missing everything in the movie library.  Despite reboots, I had to do a full library rescan.  I also then had to fix all the library issues, (duplicates, mismatches), etc.

Is there an option or feature to somehow detect if the whole library is missing and not just dump it?

[thecoache 0]

There's no way for Emby to know whether you intentionally emptied out your library or if the share failed to mount properly and I don't think it should be up to Emby to figure out which it is.
 

What I did to prevent this library purge you experienced was to add conditions to the [Unit] block of the Emby service file to prevent it from starting if shares aren't mounted. So if you're running Emby through a systemd service, this should help.

This little guide assumes a Debian bare-metal install, so if you're running Emby on something else, your mileage may vary, but it should be similar on other Linux platforms running systemd.
 

If you've never modified the Emby service file before, copy the default service provided by Emby to /etc/.

cp /lib/systemd/system/emby-server.service /etc/systemd/system/emby-server.service

Edit "/etc/systemd/system/emby-server.service" and add the following block under "[Unit]". Modify the lines to fit your setup. I run 3 shares in my setup, but if you only have one, you only need one of each "ConditionPath" conditions.

RequiresMountsFor=/mnt/Animation /mnt/Movies "/mnt/TV Series"
ConditionPathIsMountPoint=/mnt/Animation
ConditionPathIsMountPoint=/mnt/Movies
ConditionPathIsMountPoint=/mnt/TV Series
ConditionPathExists=/mnt/Movies/.Movies.md5
ConditionPathExists=/mnt/Animation/86/.86.md5
ConditionPathExists=/mnt/TV Series/24/.24.md5

And remove the following line from the file.

After=network.target

Then run 

systemctl daemon-reload

and that's it.

"RequiresMountsFor" replaces the "After" condition and will start the service when these shares are mounted. However, if these mount points don't exist in fstab or in systemd's view as a whole, this condition passes without triggering any errors and starts the service, which is where the second condition `ConditionPathIsMountPoint` comes in just in case. And then we have a sentinel file on each share with `ConditionPathExists` to make sure the right share is mounted on the right path. That sentinel file can be any file inside the share that is always expected to be present.
 

With this, Emby will fail to start whenever shares aren't mounted correctly and it would be up to you to investigate why before restarting the service manually. I believe that's a better outcome than what you had to deal with.

Hope that helps.

[displayname0504 24]

Thank you for this. I went a slightly different route and put in a ping service which detects if my file server is up. 
 

I run emby through docker so I made that service a requirement of docker. 
 

to the original question/your reply. I get it doesn't know if it's intentionally purged,  maybe a buffer before dumping the data, so if it's restored it doesn't require a rebuild. 

[Q-Droid 1050]

In addition to the startup checks both of you might want to consider a monitoring component because if the mounts disappear while Emby is running a scheduled scan could also wipe the library.

The devs could resolve this problem and I don't think it would take a lot of effort or be a major overhaul. Some solutions could introduce other useful library management features that Emby users already struggle with. The big question is what are the numbers? How many are affected by this and other problems that could be solved in one go?