CS01-HS

With the official EmbySever container, follow the instructions here, substituting Emby where appropriate: Then go to Main -> Flash -> Syslinux Configuration -> Unraid OS and change the line: append initrd=/bzroot to append initrd=/bzroot intel_iommu=igfx_off Hit "Apply" and reboot. At this point hardware encoding should be working but the video output will be garbled. Follow instructions here to resolve that:

I'm in the same boat. External disks work consistently, iPhone not at all. Unfortunately my board has a single integrated USB controller and no free PCIe slot so the "pass a controller" solution doesn't work. I tried VirtualHere (USB over ethernet) but apparently iPhone sync with a Mac host requires a Mac client. That didn't work in my case but may work for others.

Same. Tell me if this makes sense: In "target mode" there are two basic conditions to handle: (1) a large cache write (2) many small or medium cache writes Case (1) has the potential to fill the drive if a high target (say 75%) is specified, so mover must run frequently enough to detect it and free cache space. With frequent mover runs, assuming the age logic is granular (find sorted by age and iterate the files summing size), case (2) will cause very frequent array writes as a handful of files are moved on each run to maintain the target %. Better then to move the old files off in larger chunks, time rounded to the day (e.g. first all files older than 30 days from current date at 12am, then all older than 29, etc.) That was all preface (sorry!) to answer your question: I think it's almost entirely a UI decision. You could handle a target % and complex rules in code by calling your current rules logic in a loop from e.g. i=30 down, find older than i days until target free space is reached. And if it fails to free enough space that's on the user. Your "Or..." which is my preference (your range is good), would be similar but skip over the complex rules logic avoiding failures due to user error. Both proposals are a little hack-y (maybe you have a better idea) but I think until smart caching's built in every solution will be somewhat hack-y. I really appreciate this exchange but please don't let me derail what's obviously a popular plugin to handle my (potentially minority) use case.

I'm all caught up on the thread. Just thinking out loud but maybe an easier method that gets most of the benefits is to use last-modified (as you do in the age setting) and when a user-specified target cache % is exceeded iterated find commands (which should be cheap on an SSD) slice off the oldest files until the target % is restored.

Well that makes things tougher! I wonder if SMB/AFP requests could be intercepted and stored with a timestamp. Thanks for the direction, I'll read up.

Glad I could contribute a little and thanks for a great plugin. All was well with my cache until I added time machine - now my once-sleepy parity disk (and every other disk thanks to turbo write) never rest. Mover Tuner has helped greatly but I'm thinking for my purposes (media and Time Machine) a cache that stays relatively full and evicts based on last access date would be ideal. I'll research to see if that's even possible and how difficult it would be and maybe write something.

I think there's a bug where the script doesn't quote share directories so e.g. a share with the name "Time Machine" will cause this error: May 11 05:42:07 NAS root: find: '/mnt/cache/Time': No such file or directory May 11 05:42:07 NAS root: find: 'Machine/': No such file or directory which I hadn't seen previously (though it's possible I missed it.) It's probably not best practice to include spaces in share names and I've solved it by renaming but thought I'd mention it. Great plugin by the way, thanks.

Since this patch is required whenever the container's reinstalled I wrote a quick script for the User Scripts plugin. #!/bin/bash # Verify it's running running=`docker container ls | grep EmbyServer | wc -l` if [ "${running}" != "0" ]; then docker exec EmbyServer /bin/sh -c "mv /lib/dri/iHD_drv_video.so /lib/dri/iHD_drv_video.so.disabled" 2>/dev/null if [[ $? -eq 0 ]]; then echo "EmbyServer: Detected iHD driver. Disabling and restarting EmbyServer..." docker restart EmbyServer echo "Done." fi fi exit 0

The instructions here enabled hardware decoding on my j5005 board (UHD Graphics 605/Gemini Lake) but encoding produced garbled output. I assumed it had something to do with Unraid or the 4.19 kernel but apparently not - it's solved by forcing Emby to use the container's i965_drv_video.so instead of iHD_drv_video.so. NOTE 1: As of Emby 4.6.* which includes an iHD driver with fixes for Gemini Lake it's no longer necessary to disable iHD, so I've struck through the instructions below. NOTE 2: if you're getting video-related freezes with unRAID 6.9 as I was - adding a dummy HDMI plug to my headless setup and updating Syslinux configuration as below seems to solve it: label Unraid OS menu default kernel /bzimage append initrd=/bzroot intel_iommu=on,igfx_off Here's how to do that: # Launch an EmbyServer shell: docker exec -it EmbyServer /bin/sh # Inside the shell disable iHD_drv_video.so cd lib/dri/ mv iHD_drv_video.so iHD_drv_video.so.disabled # Restart EmbyServer Now both hardware decode and encode should work. NOTE: You must add intel_iommu=igfx_off to your syslinux.cfg (see this post for details) NOTE: I'm using the official EmbyServer release in Community Apps