• Content Count

  • Joined

  • Last visited

Posts posted by CS01-HS

  1. 37 minutes ago, limetech said:

    Do not use hdparm directly to spindown devices.


    Do not use because (a) it won't be reflected in the GUI or (b) it may cause more serious problems like data corruption?


    If (b) does it apply to only array disks or pool disks as well?

  2. 2 hours ago, Roman Melnik said:

    The same
    I have created an issue in bug tracker: https://github.com/JTok/unraid.vmbackup/issues/25

    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:


  3. 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?

  4. On 2/17/2021 at 12:46 PM, CS01-HS said:

    Emby doesn't intelligently manage temporary transcoding files and can fill your drive in some scenarios.


    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.

  5. 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- rather than syslog-<my unraid server's IP>. After uninstalling it it's back to normal. Strange.

  6. 1 hour ago, Hoopster said:

    The most important consideration is a UPS that supports Automatic Voltage Regulation (AVR). 


    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.

  7. 5 minutes ago, ken-ji said:

    Odd. I've never seen any transcoding files - I'm transcoding to RAM vi a mounted directory under /tmp - unless I look while someones actively playing something. So I've never this issue.


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

  8. 40 minutes ago, StevenD said:



    Thanks!  Funny enough, I couldnt figure out why my cache drive was almost full this morning. I found a 445GB .ts file in the Emby appdata/transocde dir.


    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...

  9. 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:

    # User Settings
    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'`
        echo "${TRANSCODE_DIR} (TRANSCODE_DIR): directory doesn't exist"


    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 >> /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.

    • Like 1
  10. On 1/8/2021 at 12:33 AM, JimmyGerms said:

    NUT will reset ups.delay.shutdown and ups.delay.start to their default values of 20 and 30 blowing the whole setup randomly.


    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)