Jump to content

CS01-HS

Members
 View Profile  See their activity

  • Posts

    479

  • Joined

  • Last visited

 Content Type 

Posts posted by CS01-HS

    UPS Recommendation

    in Hardware

    Posted

    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.

    New Emby Docker

    in Docker Containers

    Posted

    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.

    New Emby Docker

    in Docker Containers

    Posted

    40 minutes ago, StevenD said:

    @CS01-HS

     

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

    New Emby Docker

    in Docker Containers

    Posted · Edited by CS01-HS
    Updated Post Arguments, more robust

    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:

    1299097911_ScreenShot2021-02-17at12_14_52PM.thumb.png.1c3cf2523d8bf3f188fc9168f759966e.png

     

    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:

    1324138336_ScreenShot2021-02-17at12_25_48PM.thumb.png.1f85e64891ba0c6469a7125ac0f37665.png

     

    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

    [Plugin] NUT v2 - Network UPS Tools

    in Plugin Support

    Posted · Edited by CS01-HS

    13 hours ago, JimmyGerms said:

    Thanks for the tutorial. It helped me get to where I needed to go!

     

    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.

    [Plugin] NUT v2 - Network UPS Tools

    in Plugin Support

    Posted

    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)

    Time Machine incredibly slow 10GB in 24 hours Unraid 6.8.3

    in General Support

    Posted

    Wow that's comprehensive.

     

    1 hour ago, theruck said:

    conclusion: AFP protocol performs much better than SMB protocol on a MAC. And yes i did all the recomended tweaks on MAC side.

     

    It's unfortunate Apple chose to deprecate it.

     

    I was surprised to see in your tests with small files that Windows wasn't much better than Mac. I assumed Mac was the biggest culprit but this suggests it's SMB itself or unraid's implementation. I guess to narrow that down you could benchmark a non-unRAID SMB share.

    New Time Machine Settings / Cache?

    in General Support

    Posted

    On 1/20/2021 at 6:09 AM, theruck said:

    there are plenty of recomendations out there for SMB tunings. none of them seems to work for me. my sparsebundle performance over SMB is so terrible that it is unusable for timemachine.

     

    I haven't tested enough to gauge the relative effectiveness of each of these tweaks (some may even be inadvisable) but overall my Time Machine backups are working "reasonably" in 6.9.0-RC2

     

    In Samba extra configuration: 

    [global]
   #Fix for 6.9.0-rc2 Mac client search
   spotlight backend = tracker
   # speed tweak
   nt acl support = No
   # tweaks from https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
   min protocol = SMB2
   fruit:metadata = stream
   fruit:model = MacSamba
   fruit:posix_rename = yes 
   fruit:veto_appledouble = no
   fruit:wipe_intentionally_left_blank_rfork = yes 
   fruit:delete_empty_adfiles = yes  

#Custom
include = /boot/config/smb-custom.conf

     

    Where smb-custom.conf looks like this: 

    [Time Machine]
path = /mnt/fast/Time-Machine
comment =
browseable = no
writeable = no
read list =
write list = backups
valid users = backups
vfs objects = catia fruit streams_xattr
fruit:time machine = yes
fruit:time machine max size = 552000M
case sensitive = auto
preserve case = yes
short preserve case = yes
spotlight = yes

     

    And fast is a cache-only NOCOW BTRFS RAID 5 pool to which this custom conf allows direct access (bypassing shfs.)

    More details on that here: 

     

     

    Finally, I wiped my previous sparsebundle and started fresh in Big Sur to take advantage of the new APFS formatting.

     

    NOTE: The user "backups" in smb-custom.conf is one I created just for time machine (for security reasons from an older guide.)

    Docker container ignoring permissions?

    in General Support

    Posted

    This is worse than I thought. 

    I created a directory in the unraid console owned by root and not readable, writable or executable by anyone else: 

    mkdir /mnt/user/Download/TV/y
chmod go-wxr /mnt/user/Download/TV/y
    drwx------ 1 root   root     20 Jan 11 18:49 y/

    And apparently any user in my sonarr container (not set as privileged) can write to and delete from it freely.

    This can't be intended behavior, can it?

    Docker container ignoring permissions?

    in General Support

    Posted · Edited by CS01-HS

    18 minutes ago, itimpi said:

    Have you checked the permissions on the containing directory?   I think that ‘wx’ permissions allows deleting files within the directory.

    Thanks. A slight variation on your suggestion, I re-ran the test but with x as directory (rather than file) - same problem:

      

    docker exec -u 99 -it EmbyServer sh
    / $ mkdir /media/TV/x
/ $ chmod go-wx /media/TV/x
/ $ ls -l /media/TV/ | grep 'x'
drwxr--r--    1 99       root             0 Jan 11 12:09 x

    So directory x should only be writable by nobody

    Let's see if that's true: 

    docker exec -u 1006 -it sonarr sh
    $ whoami
abc
$ grep abc /etc/passwd
abc:x:1006:100::/config:/bin/false
$ ls -l /tv/ | grep x
drwxr--r-- 1 99 root      0 Jan 11 07:09 x
    $ echo 'dodeedododeedo' > /tv/x/file.txt
$ ls -l /tv/x/file.txt
-rw-r--r-- 1 abc users 15 Jan 11 07:17 /tv/x/file.txt
$

    Nope!

    Docker container ignoring permissions?

    in General Support

    Posted · Edited by CS01-HS

    I created an unRAID user limited (id 1006) which I'm trying to use to limit write permission in docker containers that support PUID.

     

    Can anyone explain the following behavior?

     

    Launch EmbyServer shell with user nobody 

    # docker exec -u 99 -it EmbyServer sh

    Create a file writable only by nobody 

    / $ touch /media/TV/x
/ $ chmod go-w /media/TV/x
/ $ ls -l /media/TV/x
-rw-r--r--    1 99       root             0 Jan 11 11:35 /media/TV/x

     

    Launch sonarr shell with user limited 

    # docker exec -u 1006 -it sonarr sh

    Confirm I'm limited (id 1006): 

    $ whoami
abc
$ grep abc /etc/passwd
abc:x:1006:100::/config:/bin/false

    Check permissions on the newly-created file:

    (NOTE: /media/TV in EmbyServer and /tv in sonarr map to the same host path.) 

    $ ls -l /tv/x   
-rw-r--r-- 1 99 root 0 Jan 11 06:35 /tv/x

    So the file should not be writable by current user abc - and yet: 

    $ rm /tv/x
$ ls -l /tv/x
ls: cannot access '/tv/x': No such file or directory

    abc can delete it.

     

    What's going on?

    [Support]: Intel iGPU Utilization Stats into InfluxDB for use with Grafana - intel-gpu-telegfraf

    in Docker Containers

    Posted

    On 12/6/2020 at 8:47 AM, CS01-HS said:

    I managed to cause the same error (and freeze my server) playing around with intel_gpu_top in the intel-gpu-tools container so my problem's at a lower level, your container's fine.

    After several freezes (which caused unclean shutdowns) in Handbrake using the hardware encoder and also with monitoring, and random corrupted encodes, I got my machine stable with the following changes:

    1. Added intel_iommu=on,igfx_off to syslinux config (this may be optional)
    2. Added a dummy HDMI plug to my headless server (j5005)

    It's been stable now for several days despite continuous hardware encoding in Handbrake with no corruption.

×
×
  • Create New...