CS01-HS

Strange problem where after every reboot (or maybe array stop/start) my attached USB's partition is visible as an SMB share despite having sharing disabled at the disk and partition level. Enabling then disabling sharing in the partition's settings fixes it. Anyone else seeing this?

Because the lowest allowed value there is 2! Disabling restrictive validation solved it though, thank you.

Thanks for the work on this. No rush at all but I wanted to suggest a (simple?) fix before I forget. My use case is weekly backups to the array which are then backed up to a versioned system. So I only need one backup on the array at a time. The problem is the lowest number allowed for Number of days to keep backups is 7 (inclusive) which ends up keeping two. To allow the value I want (1) I run it with this patch with no apparent problems for several months: root@NAS:~# diff /usr/local/emhttp/plugins/vmbackup/include/javascript/vmbackup.js.orig /usr/local/emhttp/plugins/vmbackup/include/javascript/vmbackup.js 1195c1195 < change_attr("#number_of_days_to_keep_backups", "pattern", "^(0|([7-9]|[1-8][0-9]|9[0-9]|1[0-7][0-9]|180))$"); --- > change_attr("#number_of_days_to_keep_backups", "pattern", "^(0|([1-9]|[1-8][0-9]|9[0-9]|1[0-7][0-9]|180))$"); root@NAS:~#

With 6.9 on my Asrock j5005 (UHD 605) I'd get occasional lockups not with Emby, as far as I could tell, but with Handbrake GPU encoding and the intel-gpu-telegraf docker. Installing an HDMI dummy plug seems to have fixed it - it hasn't happened since. I don't know if that's specific to my board or more general. NOTE: I'm using the new modprobe method to load the driver.

I don't know enough about the plugin to know if that's the best solution but you can overwrite the rules file on boot by saving your custom version on the flash drive (I created the directory /boot/extras/ for custom scripts) then adding something like the following to your /boot/config/go file: # Custom autofan cp /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan.orig cp /boot/extras/autofan /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan

@BurntOC I've only used that procedure once and with a different plugin. I hope I didn't lead you astray.

If like me you upgraded to 6.9 before installing the latest version I think you'd be fine - v0.2.1 works for me. I'm pretty sure there's a way to install specific versions manually with the webGUI but I can't remember how. Edit: I remembered - go to plugins -> Install Plugin then paste the following in the URL field: https://raw.githubusercontent.com/jtok/unraid.vmbackup/v0.2.1/vmbackup.plg

For what it's worth I've been running 6.9-RC2 since it was released and although the latest version of the plugin prevents me from installing it, the version prior has worked consistently in my weekly runs.

Thanks, thought maybe I missed something. I should also mention I set an autostart delay (to give it time to establish the connection.)

Using this container (which I've renamed vpn) I create a new network with the following command and route all related containers through it: docker network create container:vpn It's straightforward and (from what I can tell) works reliably, no issues with the latest update. Many seem to use proxies instead - are there advantages to that method?

For anyone following my earlier instructions I've switched to using /dev/shm/ as the transcode directory. I think there may be a timing issue where the container tries to access the tmpfs before it's created which obviously caused problems. Referencing a permanent directory (/dev/shm/) avoids that. So far so good.

I haven't tested enough to confirm it's related but some time after installing the GUI plugin my syslog server started logging to syslog-127.0.0.1.log rather than syslog-<my unraid server's IP>. After uninstalling it it's back to normal. Strange.

Thanks but I meant a console command (I'm trying to script something.)

hdparm seems to work but is there a better way (that might update the WebGUI's activity "LED") ?

Makes sense. I thought maybe I misunderstood AVR or my unit had a substandard implementation. Thanks. Sorry OP for the tangent.

My Cyberpower's AVR only kicks in when voltage drops down from 120V to 104V. That rarely happens so why's it important the drop's supplemented by circuitry rather than battery? The more common case (total power loss) is handled by battery entirely.

Same. In my case multiple simultaneous transcodes maxed out the RAM drive.

I've never seen a file that size. Mine are few MB each. The large size suggests it's being continuously written to in which case my script deleting it may cause whatever's writing it to fail...

Emby doesn't intelligently manage temporary transcoding files and can fill your drive in some scenarios. This is especially a problem if you're transcoding to a RAM drive with limited space as described here (the specified command is added to template's Extra Parameters.) Update: I've switched from tmpfs (outlined here) to /dev/shm I solved this with a helper script stored on a share accessible to the Emby container and called from within it. Create it as transcoding-temp-fix.sh and run chmod a+x on it. Here's the script: #!/bin/sh # User Settings TRANSCODE_DIR="/transcode/transcoding-temp" PERCENT_LIMIT=70 BATCH_SIZE=10 if [ -d "${TRANSCODE_DIR}" ]; then percent_full=`df "${TRANSCODE_DIR}" | awk '{print $5}' | tr -dc '0-9'` echo "Directory limit: ${PERCENT_LIMIT}%" echo "Directory utilization: ${percent_full}%" while [ $percent_full -gt $PERCENT_LIMIT ]; do echo "(${percent_full}%) exceeds limit (${PERCENT_LIMIT}%), deleting oldest (${BATCH_SIZE}) files" # DEBUG: Uncomment to print list of deleted files #ls ${TRANSCODE_DIR}/*.ts -1t | tail -${BATCH_SIZE} | xargs ls -lh ls ${TRANSCODE_DIR}/*.ts -1t | tail -${BATCH_SIZE} | xargs rm percent_full=`df "${TRANSCODE_DIR}" | awk '{print $5}' | tr -dc '0-9'` done else echo "${TRANSCODE_DIR} (TRANSCODE_DIR): directory doesn't exist" fi This assumes you're mounting the RAM drive at /transcode (as described in the linked post) which you've set as the Transcoding temporary path in Emby: The script deletes the oldest ts files in batches of 10 (BATCH_SIZE) until it reaches a safe usage percent (PERCENT_LIMIT). I call it every 30s with the following entry in the template's Post Arguments && docker exec EmbyServer sh -c 'watch -n30 "/system-share/transcoding-temp-fix.sh" 2>/dev/null > /transcode/transcoding-temp-fix.log &' NOTE: The full host path to the script is /mnt/cache/system/emby/transcoding-temp-fix.sh where system-share is a mapped path variable I've added to the template: Its execution can be monitored with the following command from the unraid console: docker exec EmbyServer sh -c 'tail -f /transcode/transcoding-temp-fix.log' It works well so far with standard transcoding but I don't use batch conversions or live TV so YMMV. NOTE: I'm piping results to rm so use at your own risk (and feel free to post improvements.) You may want to test the commands individually before running the full script.

Any plans to include iHD for QSV in addition to i965? Otherwise does anyone know of a docker that will convert to HEVC with hardware support for encode AND decode? Handbrake works but no HW decode support.

I removed the Trim plugin (on RC2) but now Fix Common problems is warning me that it's not installed - should I ignore it?

Anyone encoding h265 with quick sync mind sharing their settings? Mine (defaults except for 192kbps audio) practically doubled the size of the h264s it converted.

Glad it was helpful. Actually I've updated it with misc reliability tweaks and a shift from battery level-based shutdown to timer-based shutdown. I was holding off until I had a few natural power outage/shutdowns to test with but I'm reasonably confident it's an improvement.

Are you sure it's random? If e.g. it's reset on startup you can save the good version to your boot drive and copy it over in config/go (which I'm pretty sure runs after plugins are installed)

Extract a Single File(s) From a Large Tarball