Search the Community

Hi all, Sometimes while browsing my media, sometimes while starting video playback, or second video after the first has finished - the server becomes unresponsive. Most often access is from Firefox web browser in Fedora on the gigabit LAN. I can't ssh in and APCI shutdown doesn't work. I resort to pressing the reboot button or press and hold the power button. Not good, I know. It has become so frequent I can no longer use Emby, I am browsing my NFS shares and playing in VideoLAN. I have used different server distributions, deleted both the Docker image and container, deleted Emby configuration. Setup Overview My media collection is hosted on a local Synology NAS. Shared via NFS. Linux server distribution Ubuntu 20.4 server LTS, was running CEntOS 8 stream. Docker installed with apt-get Emby is installed via docker-ce 19.03.8 NAS Settings Server Settings mengoshmink@phantom:~$ cat /etc/fstab | grep video guardian:/volume1/video /mnt/guardian/video nfs rw,intr,nfsvers=4,noexec 0 0 mengoshmink@phantom:~$ ls -lh /mnt/guardian/video/ total 0 drwxrwxrwx 1 root users 10 May 13 09:40 Archive drwxrwxrwx 1 root users 198 Jan 5 20:33 Video version: '3.7' services: emby: volumes: - /mnt/store/var/docker/emby:/config:rw - /mnt/guardian/video:/mnt/guardian/video:rw - /mnt/guardian/tmp:/mnt/guardian/tmp:rw network_mode: "host" restart: unless-stopped environment: - UID=1000 - GID=100 container_name: emby image: emby/embyserver:latest Log files attached Any more information needed, please ask. Any ideas? Thank you in advance, take care and be safe :-) mengoshmink hardware_detection-63725769007.txt embyserver-63725769460.txt hardware_detection-63725769467.txt hardware_detection-63725770749.txt embyserver-63725770741.txt embyserver.txt

Background: I hate CIFS/Samba (just kidding, I loathe that technology) so my setup consists of a CentOS server that also acts as an NFS server containing all of my media. Emby runs on a separate Debian server, and it mounts the NFS shares via autofs. I have been wondering why my metadata was not getting saved back to the media directories on my NFS exports. So I got off my lazy arse and actually started to do some real troubleshooting. Initially, my /etc/exports consisted of shares configured like so: /srv/nfs/media 192.168.100.0/24(rw,async,no_root_squash) And on my Debian server running Emby, my autofs setup is something like this: auto.misc movies -fstype=nfs,rw NFSSERVER:/srv/nfs/media/Movies tv -fstype=nfs,rw NFSSERVER:/srv/nfs/media/TV Emby never had issues mounting these directories when needed, and reading data from them. But it could not write any metadata back to the shares (.nfo files, posters, etc.). Instead, it would give me "permission denied" messages in the logs, and instead write the metadata files into the /var/lib/emby structure on the Debian server. So first I looked into the UID and GID that Emby was using. On my Debian installation, the ID mappings look like this: uid=998 gid=998 However, I once had Emby running on a separate CentOS installation, and the mappings were different: uid=988 gid=988 No idea as to why, that's just how it was. Initially, I thought that maybe I just needed to add an 'emby' account to my CentOS host, using the same uid/gid pair. But I couldn't do that, as 998 on CentOS was reserved for the 'irc' service, at least on my installation. No big deal, the 'video' group exists on both installations, so I'll make Emby a member of that group on the CentOS installation, as it is already a member of that group under my Debian host. So I set up an 'emby' user on my CentOS server: useradd -s /sbin/nologin -u 998 -G video -M -r emby Neato. Now I go and attempt to "Refresh Metadata" on a movie, and check the share. No metadata is written. Well, damn. I look at the logs, and it still says "permission denied". I double check the uid and gid on both systems. Well, there was a mismatch (because god-forbid we should have our Linux distributions agree on some things). The GID for 'video' was different between both installations: Centos: video gid = 49 Debian: video gid = 44 No worries, I'll change the GID on my CentOS install (making sure that the number would not conflict with another group): sudo groupmod -g 49 video Another attempt at refreshing metadata.... permission denied. Ok, well the GID now matches between both hosts, so let's set up the exports so that the group has ownership of anything written to that directory. This is the typical approach that would be taken under such circumstances, and is typically the final solution to such a problem. sudo chmod g+s /srv/nfs/media Ok, so now things look like this: drwxrwsr-x emby video /srv/nfs/media Another attempt to refresh metadata. Another failure. What the hell? Emby is in the correct group, it has full write access to that location, and the group has ownership of that directory! Just for grins and giggles, I went nuclear: sudo chmod -R 777 /srv/media After another "Refresh Metadata" round, still no dice. How on Earth is this still not working? I started to mess around with ACL's to try and fine-tune the permissions more, even changing the mask value for this export. Nothing was working. I even tried doing a SUID on the directory, but the Linux kernel (smart for security, anyway) will typically ignore such requests. Then I got smarter. I went and looked at man(5) exports. Instead of doing a 'no_root_squash', I could instead do a 'all_squash'. This forces all new entries written via NFS to effectively use the UID and GID of 65534 (known as the anonymous UID and GID). But, I can force the anonymous UID and GID to match the UID and GID for the 'emby' account on my CentOS server. I changed the export to: /srv/nfs/media 192.168.100.0/24(rw,async,all_squash,anonuid=998,anongid=49) Re-exported the share: sudo exportfs -a Ran another metadata refresh... SUCCESS! In summary, even though the GID matched, the Emby service was still unable to write to the share as I'm guessing either the Emby service or the NFS service needed the UID to be the effective owner of the directory of where the data was going to be written to. Anyways, maybe this will help someone else out or whatever, but I thought that I would share my experience on this fun exercise in permissions.

Hi, Before anything else I simply must thank you for your otherwise excellent product: I really like Emby and have been using it for over a year now. It's pretty, easy to use and the cross-platform apps are superb. Thank you very much. So, I'm having a problem playing back media. Whether TV shows, movies etc. doesn't matter. They play fine: in the browser, using my Apple TV (4th gen) or the iOS app (iPhone). The catch though is the scrubber doesn't display relative to the length of the media itself, only relative to the amount it has buffered. For example, if 'Dick Spanner: The Case of the Human Cannonball' is 50-ish minutes long then the scrubber will initially show 30-40 seconds total length. Then more will buffer and the total length will go up. In order to skip 20 minutes into the media file, I need to wait for 20 minutes worth of media to buffer before the scrubber will let me go that far. Here's a screenshot of an episode of Father Ted to illustrate: It's only about 5 seconds in, but the scrubber makes it look like we're 2/3 of the way through the episode. It also seems that the media files don't buffer beyond a certain amount- about 5 minutes or so ahead (which makes good sense, saves on bandwidth) but that means I can only skip ahead 5 minutes or so each time. I'd like to be able to start a movie, stop watching it halfway through and then restart it later and scrub to where I left off. I often access the Emby server remotely and, due to remote access problems, it's not uncommon for movies to cut-off or have to be restarted. In those cases Emby isn't necessarily aware of where they left off (so no 'Resume' option) and I must scrub to the correct point manually. Now Emby didn't do this until recently, ie in the last week or so, so I can only imagine its either something I've done to our network (quite possible!) or some setting that I've flipped accidentally. Has anyone seen this? If so, do you know how I might correct it? It's trivial... but surprisingly frustrating! I've attached my Emby server logs (there's only one user in the system). -- Set up details: * Emby is running on a Windows Server 2016 box accessing media from an NFS share over a 10/100 CAT7 ethernet connection. * NFS share is CentOS 7 with a 7 disk (1 spare) RAID6 array. I changed to this from SAMBA a little while ago due to poor performance. * Client devices access either over WiFi or remotely through reverse-proxy. * Emby runs as a standard non-privileged user using the Emby Portable image. * All was going fine until about 10 days ago * Scrubber issue happens on all clients, remote and local. * I've tested (over WiFi) mounting the NFS share as a drive and dragging-n-dropping a file into VLC, which seems to stream it happily with the scrubber adjusted correctly. * NFS share has a network throughput of about 10 meg a second, so can download 1GB in about 1-2 mins The biggest change I've made was 2 weeks ago which involved changing from installing as a service to installing the portable edition- running as a service was difficult when trying to mount network shares, it involves granting the service 'logon as user' rights and all sorts. -- My apologies for the complexity and I hope you might be able to recommend what I'm doing wrong any help would be greatly appreciated. Thank you again for your superb product. logs.zip

Hi, I have read almost all NFS threads but no one has managed to help me. Do I need to install anything extra on Linux for NFS? I need to make this work until Christmas.

Hello I've been stuck trying to add my library to Emby since installing two days ago. I used to use the app a few years ago without issue on a Fedora install and now it only ever loads locally-stored media. I have an NFS share on 192.168.1.254:/srv/media. Initially I tried mounting it and then pointing Emby to the local mountpoint. When I add 192.168.1.254:/srv/media to my fstab, the directory mounts on boot correctly and members of the :media group (of which the emby user is one) can write to the folder. Then I start emby and the share may as well have never been mounted because Emby sees nothing and processes nothing at all in that folder. So then I remove the share from my fstab and proceed to let Emby handle whatever mounting needs to be done by supplying the Network Path in the Library setup, at which point it complains about every path format I give it. These are the paths that do not work: nfs://192.168.1.254 nfs://192.168.1.254:/srv/media nfs://192.168.1.254/srv/media And all of them throw the "There was an error adding the media path." error Apparently Emby can't access my media on its own unless its on a local block device, so now I'm totally confused. Do i need another piece of software installed on 192.168.1.254 just to get the share to work with Emby? Running multiple "helper apps" across multiple machines on top of NFS is complete overkill. Any insight would be helpful, I feel like I'm wasting my time and would just like a straight answer as to whether Emby supports NFS without extra utilities or setup.

Hi all :-) I'm a new user, trying to setup my Emby + Kodi environment. I've issues in library setup, during the "path substitution" phase, now integrated with library folders. The issue is that Emby "shared network folder" field seems to accept only UNC paths (\\server\share...), so any linux client tries to access the share via Samba instead of using NFS. My NAS exports shares both via SMB and NFS, but since I'm using some RaspberryPi as Kodi front-ends (OSMC distribution), I want to avoid using Samba, since it has an overhead on CPU. The only way I've find to end the library setup is by using UNC paths, but of course all clients try to access the share via Samba. Example, from kodi log: I've already tried to search for a solution on wiki and forum, but I've seen only threads (eg. https://emby.media/community/index.php?/forum/116-linux/)without solutions to get NFS works with Emby. It seems that it was supported without problem in the previous "path substitution" way: https://emby.media/community/index.php?/topic/24109-no-playback-with-beta-add-on/?p=235928 Is there any solution or workaround (even by edit manually some config file...) to pass to clients an NFS path instead of UNC, with the new library setup procedure? Thank you in advance. Bye, Edoardo

Hello, I'm a new user of Emby, i really love it !! it's so easy and powerfull i didn't know why i don't heard about it before. Here is my setup of Emby to explain what i excpected to do with it : Actually i use substitution path for local Kodi and i would know if it's possible to have two path substitution system ? One for local device and one for remote device. I got strong internet connexion and didn't need transcoding to play files on my remote Kodi so it would be really interessant if it's possible to dissociate local acces to files from remoted one. To resume : Local Kodi -> NFS access to NAS with substitution path Remote Kodi -> FTP access to NAS with substitution path Is this possible ? Need a bunch of modifications ? Again thanks for your great works !! PS : Sorry for my poor english, i 'm French i tried to write something understandable.

Hi, I'm trying to get direct play to work for the movies that reside on my NAS via NFS. But Emby is unable to verify the path. The NFS path listed in the log below is exactly the same path that works from the file manager in Kodi. My Emby server is Windows 8.1 and cannot access the NFS share outside of Kodi, but this shouldn't matter because of the path substitution, correct? Is the Kodi client verifying the path or is the Emby server? Setup: Emby Server - Window 8.1 Prof. NAS = WD My Cloud NFS/SMB Kodi = Windows and RPI2 Emby library folder: \\192.168.0.101\media\movies Emby Path Substitution: \\192.168.0.101\media to nfs://192.168.0.101/nfs/media Log: 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Play called. 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : Verifying path: nfs://192.168.0.101/nfs/media/movies/4 Minute Mile 2014 HDRip XviD-EVO/4.minute.mile.2014.hdrip.xvid-evo.avi 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : Failed to find file. 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : Unable to direct play. 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : Direct play failed: 1 times. 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : The add-on settings bitrate is: 100000000, the video bitrate required is: 1130172 21:05:33 T:26124 NOTICE: EMBY PlayUtils -> logMsg : File is direct streaming. 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Playlist start position: 1 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Playlist plugin position: 1 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Playlist size: 2 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Resetting properties playback flag. 21:05:33 T:26124 NOTICE: EMBY PlaybackUtils -> logMsg : Play as a regular item. 21:05:33 T:18164 NOTICE: DVDPlayer: Opening: http://192.168.0.143:8096/emby/Videos/f6637b59b53496deee3f2e371320b107/stream?static=true 21:05:33 T:18164 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED

Currently running Emby Version 3.0.5675.1 on my Windows 8.1 machine, and the Emby for Kodi addon version 1.1.17 on my Amazon Fire TV within my home network. I also like to access my library remotely to stream via my mobile devices. When trying to play from my Video Library while within my network, I receive the message that I am unable to direct play, and whether I want to stream via HTTP or HTTPS. I believe my issue has to do with my path substitution being set up incorrectly. I have my share permissions set up correctly for NFS, but think my syntax is wrong in my Emby Server for path substitution. For example, my current path substitution is set up like: From To "G:\TV" "nfs://192.168.0.10/G/TV/" "H:\Kid Movies" "nfs://192.168.0.10/H/Kid Movies/" It's my understanding that NFS does not require a username/password to access the Windows shares, versus if I were using SMB I would need to configure the setting within the Emby for Kodi add-on with the credentials. The above are a couple of examples, for which I thought were working correctly up until a few days ago when Emby for Kodi or my Emby Server were updated (I was out of town and something auto-updated). Now I receive the HTTP message and 'Warning: Unable to direct play'. I'd like to direct play my library from within my network, while still accessing media outside of my LAN. My examples above include the quotation marks because I am not aware of how Emby will process paths that contain spaces, so that's how I originally entered them. With borrowing from my above examples, what would be the official syntax to use for my NFS shares? For those paths that contain spaces, do I use quotes? Am I able to use the IP Address, or is Emby looking for the server name? For those paths that DO NOT contain 'spaces', would I use: Option A) nfs://192.168.0.10/TV Option B ) nfs://192.168.0.10/TV/ Option C) nfs://ServerName/TV Option D) nfs://ServerName/TV/ Option E) None of the Above (please provide a better suggestion) For those paths that DO contain 'spaces', would I use: Option A) nfs://192.168.0.10/Kid Movies Option B ) nfs://192.168.0.10/Kid Movies/ Option C) "nfs://192.168.0.10/Kid Movies" Option D) "nfs://192.168.0.10/Kid Movies/" Option E) nfs://ServerName/Kid Movies Option F) nfs://ServerName/Kid Movies/ Option G) "nfs://ServerName/Kid Movies" Option H) "nfs://ServerName/Kid Movies/" Option FML) None of the Above (please provide a better suggestion) Lots of play above with IP Address vs Server Name, quotes vs no quotes, slashes vs no slashes.... As you can see, just a little lost looking for some help. Thanks