NFS + Native Apps + Direct mode playback issues

[cmcginty 2]

Running emby in a new docker instance and testing with a single shared media folder. Playback from web browser is fine (wireless), but the same stream from AppleTV (wired) or Android (wireless) is horrendously slow to start, or never starts.

With a second emby server running on a laptop, hosting the same video file directly from the laptop. The playback is generally good. 

Back to the docker server, If I change the AppleTV stream from Auto to 720p 1Mbps, the playback is fine? Trying some other options, 1080p 5Mpbs or above, the issue comes back.

The docker server media is a readonly NFS mount. If the same media is moved from NFS to local storage, the AppleTV direct playback works, however there is still a 2-3 start delay.

So something with my NFS + direct mode + AppleTV is not working (again, web playback is unaffected, even in direct mode)

[cmcginty 2]

This looks suspicious. AppleTV is making a range request for the entire 1.5GB file.

2024-04-27 18:07:26.209 Info Server: http/1.1 GET http://host2:8096/emby/videos/578/original.mp4?DeviceId=F7D03F21-9A3A-4B2D-8D0A-4F497DE2109D&MediaSourceId=c0b2e8235fe16fb998a3ce56686eeffc&PlaySessionId=dd4c4396df0b4acaa40ab28b49e5c918&api_key=x_secret2_x. Accept=*/*, Connection=keep-alive, Host=host3, User-Agent=AppleCoreMedia/1.0.0.21L227 (Apple TV; U; CPU OS 17_4 like Mac OS X; en_us), Accept-Encoding=identity, Accept-Language=en-US,en;q=0.9, Range=bytes=13394-1515126783, X-Playback-Session-Id=52B358DF-8CF6-471C-B833-4D176FA80703

 

 

[Luke 43542]

@cmcginty

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[cmcginty 2]

I found a solution to this after a long debug session.

It was easy to reproduce the delay with curl:

curl -sS -o /dev/null -w 'HTTP: %{http_code}  First byte: %{time_starttransfer}s  Total: %{time_total}s  Speed: %{speed_download} B/s\n' \
  -H 'Range: bytes=395757424-396757423' \
  "http://127.0.0.1:8096/emby/videos/7245/original.mp4?api_key=${API_KEY}"

HTTP: 206  First byte: 6.033222s  Total: 6.033684s  Speed: 165736 B/s

The key issue was found with the command on my NFS server

$ journalctl -k --since today --no-pager | grep 'lockd:'

...
Oct 23 17:43:55 NFS_SERVER kernel: lockd: cannot monitor EMBY_SERVER
...

This shows that something was failing with statd on my NFS server. When I looked, the service was not running on the server. Cofirmed with ...
 

rpcinfo -p localhost | grep -E 'nlockmgr|status'
    100021    1   udp  40992  nlockmgr
    100021    3   udp  40992  nlockmgr
    100021    4   udp  40992  nlockmgr
    100021    1   tcp  36692  nlockmgr
    100021    3   tcp  36692  nlockmgr
    100021    4   tcp  36692  nlockmgr

The solution was to turn on statd ...
 

sudo systemctl start rpc-statd
sudo systemctl enable rpc-statd

This solves the video startup delay, and can be confired with:

rpcinfo -p localhost | grep -E 'nlockmgr|status'
    100021    1   udp  40992  nlockmgr
    100021    3   udp  40992  nlockmgr
    100021    4   udp  40992  nlockmgr
    100021    1   tcp  36692  nlockmgr
    100021    3   tcp  36692  nlockmgr
    100021    4   tcp  36692  nlockmgr
    100024    1   udp  60074  status
    100024    1   tcp  38386  status

 

Edited October 24 by cmcginty

[Luke 43542]

Thanks for following up and sharing.