Emby behaving strangely after backup/restore

[Carlo 4330]

I'm pretty sure I just edited the sysctl.conf directly and added the two lines then restarted the NAS as root.

[FrostByte 5052]

There are different ways to put the INOTIFY commands in, I prefer to add them as a task that runs every time I reboot my NAS and that way they are always there.

However, like H2P mentioned if you aren't getting INOTIFY errors then that probably isn't the problem.  You should get errors saying you maxed out INOTIFY watches or instances if it's INOTIFY .

[Carlo 4330]

There is at least 3 different ways people are modifying these values.

Regardless how you do it it's easy to check the current settings active via SSH.  Also as both Happy2Play and FrostByte said when the Inotify setting is to low it gives an error that is easy to find in Emby logs. At least that has been the case that we've always seen up to 4.6.4 release on DSM 6 & 7.

This assumes you're running the the native Synology version of Emby Server and not running the server on another platform or in docker.

[Grimmer 3]

I installed the inotify-tools. And started a watch:

sudo inotifywait -rme crea
te,delete,move,modify /volume1/MyEmbyMedia/Cartoons                        
Password:
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/volume1/MyEmbyMedia/Cartoons/ CREATE,ISDIR The African Queen (1951)
/volume1/MyEmbyMedia/Cartoons/The African Queen (1951)/ CREATE The African Qu
een (1951).mp4

After 20 minutes or so there have been no additional inotify hits and no files created by Emby (i.e. no RTM scan) 

Attached is the corresponding Emby log. 

embyserver.txt

[Grimmer 3]

Question... If I were beyond the inotify instances and watches limits, should inotifywait have thrown an error? 

The first time I ran it (without sudo) it said:

user@host:/volume1/MyEmbyMedia/Cartoons$ inotifywait -rme create,del
ete,move,modify /volume1/MyEmbyMedia/Cartoons
Setting up watches.  Beware: since -r was given, this may take a while!
Couldn't watch /volume1/MyEmbyMedia/Cartoons: Permission denied

I added the sudo and it worked fine. Is that to be expected? It appeared to have permission to execute the inotifywait, but then choked on the permission of the folder, which my login user should have had access to (and would assume that any system user executing the inotifywait code should have also had permission to access that folder. At any rate I went back and checked with ls - n and compared it against /etc/passwd to confirm that the userid and groupid's matched. And they do.

Ah, I think I see why... It created a folder @eaDir which is owned by root... 

Edited September 16, 2021 by Grimmer

[Luke 37115]

Hard to say since we use .net core apis, which in turn use inotify, so we're actually two layers removed from it.

[Grimmer 3]

I was poking around on the internet some more and got the idea to create a new library to test it out...  The new library is working for RTM.  At the same time, I created a new media file in one of the old (restored) libraries and it failed to RTM.

So I wonder if there may be some latent file owner or permission issue (even though the OS permissions are all lining up to the current owner & group.  I don't know if it matters, but when I first installed Emby, the owner of the files Emby created was "embysrv" (or maybe "embysv" - at any rate it wasn't the current "emby" that is displayed  as the owner for all directories (even the old restored libraries).  Is there a way to look into the Emby configuration files to check for something like this? and where?

What would happen if I stop the Emby server and then delete all (or part) of its configuration files (located in /volume1/Emby/)?  Upon restarting the server, would it rebuild the missing config information or would it just blow up? Maybe I should uninstall Emby, then delete /volume1/Emby, then reinstall Emby?

Emby server log from right before I added the new media to the test library TestLib.

Contents of /volume1/Emby/

 

embyserver (6).txt

[Carlo 4330]

Hi, There is hardly any information in that log file.  

[Grimmer 3]

OK, now I'm totally confused...

I created a new test library and the RTM worked just fine.  So I figured there was some legacy configuration that was screwing things up.  So I uninstalled Emby, deleted it's configuration / database folder and deleted the emby user and it's home directory.  Rebooted the NAS and then reinstalled Emby. It was assigned a new userid, so I changed the owner of all the library files to the new emby userid. 

The new server came up fresh and empty and walked me through the typical first time install setup.  I manually rebuilt all of the libraries and after 6 hours of scanning them, they were all present and accounted for.

Then came the big test.  I created a new media file directly from Handbrake like I always do and it has not scanned it after about 30 minutes. I'm getting the inotify triggers from the file system using inotifywait.  But it seems they are still falling on deaf ears.

[Grimmer 3]

Well, shit...  I figured it out.

I was changing the ownership of the individual Library directories.  Turns out that somehow (likely part of the restore process), the parent directory of the libraries was owned by root. I changed that back to emby / users and it appears to be working again.

Thanks for all the help.

[Luke 37115]

Thanks for the feedback.

[Grimmer 3]

For posterity...

I have also discovered that if any "permission denied" error occurs on any folder during the scan, it will stop Emby from discovering media changes everywhere.  For example, Emby again stopped picking up the addition of new titles added to the normally accessible file structure.  Permissions were all just fine there but I had recently re-transcoded a movie in the restricted file structure and those permissions were messed up resulting in a permission denied error.  That "unrelated" error stopped all media change detection.

For most users none of this would even be a potential problem, unless they too have younger network savvy kids that could try to circumvent the parental controls by skipping the Emby server and going directly to the network share to play the file.  For those that do have similar kids, I've found it to be very effective to set the owner of the file to "emby" (the current user for the Emby server software) and remove the permissions for everyone except the file owner.  However, that probably requires a linux based server (I'm not too confident about Window's ability to manage file permissions) and takes some extra effort on the admin's part.  Just make sure that the Emby server can always RWX everything within each library.  I use a sub-folder in the library called "Restricted" and each title subfolder and file below that has only Owner permissions for RWX; Group and Others have no permissions at all.  I then use two tags in the Emby metadata: "Restrict L1" and "Restrict L2". Younger kids' user profile are blocked from both L1 and L2, whereas the sub-adults are only blocked from L2.

[Luke 37115]

Quote

I have also discovered that if any "permission denied" error occurs on any folder during the scan, it will stop Emby from discovering media changes everywhere.

Hi, this should be resolved in the upcoming 4.8 server release. Thanks.