TheDragon

I'm running 0.9.16.6.1993-5089475 Looks like this does affect the version I'm running. Guess will have to wait for the next major release before trying again. Thanks for posting this mr-hexen

I'm running 0.9.16.6.1993-5089475

Just tried this and it doesn't work. If you try and open any media that requires transcoding it fails to play. As soon as you remove /transcode as the directory specified in plex it works again. Do you have any other ideas about how to get this working again?

I don't think that is accurate. There are really only two reasons to care about where the transcode directory is located: [*]To transcode to ram [*]To make sure transcoding doesn't happen in the docker.img Since: [*]the option to transcode to ram hasn't worked since Plex 0.9.14 [*]and as of Plex 0.9.16.3, the default transcode location is in the /config directory rather than /tmp there is no longer a need for 99.9% of people to specify a transcode directory. Pretty sure that's why LS.IO removed it. For the 0.1% of people that still have a need, they could always do it manually: https://lime-technology.com/forum/index.php?topic=40937.msg419495#msg419495 Regarding the link you gave for the '0.1%' that doesn't actually work - I tested it yesterday. That's why I brought it up in this thread.

I understand where you're coming from - I had Plex setup this way for several years and never had any problems. I wish the ease of setting to transcode in RAM had been maintained for those that wish to. Unfortunately I've been unable to get it to work since the changes were made by plex. Initially I thought it was the container, but I'm now sure it is plex and not the container

So does that mean that there is no way to set the transcode directory to memory (i.e. /tmp)? I have been debating switching from ESXi to bare metal, and that is something I'd love to keep since it reduces wear on my SSDs... It's forced by plex not by us. We just adapted our config lonix would it be possible to reinstate this mapping? From what I can see this hasn't been forced by plex - as there is still a setting within plex to set a custom location for transcoding. However without this mapping I am no longer able to use the setting within Plex itself to use unRAID root file system which is in the RAM. I have a large quantity of RAM (as in sure some others do too) and this change has essentially crippled the transcoding feature for me unless I'm misunderstanding something, if you can still tell Plex to transcode to a custom location, just add the appropriate mapping back in yourself (something like /transcode mapped to /tmp/plex) Like any other container, you can always add as many paths as your system requires without any changes from the template authors That's how I thought it worked too, but despite setting a mapping myself of /transcode/:/tmp/ and then setting it to /transcode/ in plex but it doesn't work anymore for some reason. If I try to transcode something it just doesn't play. I had it working perfectly prior to the recent change which is why I thought something had changed in the container itself. If I remove the custom location entirely in plex, transcoding works - albeit very slowly as my disk isn't very quick. When I had it running in RAM it was very quick which is why I'm so keen to try and get it working again, how it was before Transcoding to RAM has not worked since Plex version 0.9.14, which was released last November. This was a change that Plex made, and it affected all Dockers / plugins / installs. There isn't anything LS.IO can do to bring it back. Here is a post describing how to set your transcode directory manually, with a caveat that you should avoid transcoding to RAM: https://lime-technology.com/forum/index.php?topic=40937.msg419495#msg419495 That makes sense! Thanks for the explanation and taking the time to reply, I'll have to see if I can find a faster HDD to use instead.

So does that mean that there is no way to set the transcode directory to memory (i.e. /tmp)? I have been debating switching from ESXi to bare metal, and that is something I'd love to keep since it reduces wear on my SSDs... It's forced by plex not by us. We just adapted our config lonix would it be possible to reinstate this mapping? From what I can see this hasn't been forced by plex - as there is still a setting within plex to set a custom location for transcoding. However without this mapping I am no longer able to use the setting within Plex itself to use unRAID root file system which is in the RAM. I have a large quantity of RAM (as in sure some others do too) and this change has essentially crippled the transcoding feature for me unless I'm misunderstanding something, if you can still tell Plex to transcode to a custom location, just add the appropriate mapping back in yourself (something like /transcode mapped to /tmp/plex) Like any other container, you can always add as many paths as your system requires without any changes from the template authors That's how I thought it worked too, but despite setting a mapping myself of /transcode/:/tmp/ and then setting it to /transcode/ in plex but it doesn't work anymore for some reason. If I try to transcode something it just doesn't play. I had it working perfectly prior to the recent change which is why I thought something had changed in the container itself. If I remove the custom location entirely in plex, transcoding works - albeit very slowly as my disk isn't very quick. When I had it running in RAM it was very quick which is why I'm so keen to try and get it working again, how it was before

So does that mean that there is no way to set the transcode directory to memory (i.e. /tmp)? I have been debating switching from ESXi to bare metal, and that is something I'd love to keep since it reduces wear on my SSDs... It's forced by plex not by us. We just adapted our config lonix would it be possible to reinstate this mapping? From what I can see this hasn't been forced by plex - as there is still a setting within plex to set a custom location for transcoding. However without this mapping I am no longer able to use the setting within Plex itself to use unRAID root file system which is in the RAM. I have a large quantity of RAM (as in sure some others do too) and this change has essentially crippled the transcoding feature for me

Quick question... Can this plugin be used after bunker has already created hashes and used the file extended attributes?

I can make that an option in bunker to send notifications when corruption is detected. That would be immense! Can you also share with us what flags you're using on your setup?

Maybe a nail and a lick of paint!!

Hit the nail on the head I think! +1

Yes it does, I've got mine flashed with the LSI IT firmware... No problems getting smart info Sent from my Nexus 5 using Tapatalk

Wonder if anyone knows the answer to this - I've just realised my router is running dnsmasq too.. Is it a problem to be running two instances on the same network? Sent from my Nexus 7 using Tapatalk

No worries! Crossed the same bridge myself the other day, glad to be able to finally help someone else on these forums ;-) Sent from my Nexus 7 using Tapatalk

Try changing to this APPEND ip=dhcp boot=NFS=192.168.1.111:/mnt/USER/Nas/tftp/images/openELEC disk=NFS=192.168.1.111:/mnt/USER/Nas/tftp/images/openELEC/storage overlay Since you've not exported the whole cache drive via NFS, I think this should do the trick! Hope this helps :-) Sent from my Nexus 7 using Tapatalk

That is great to hear. Let's have a look below at /mnt/cache/tftp/menus/CentOS.menu... LABEL 2 MENU LABEL CentOS 6.4(64-bit) KERNEL images/CentOS/x86_64/vmlinuz APPEND initrd=images/CentOS/x86_64/initrd.img ramdisk_size=100000 ip=dhcp METHOD=nfs:192.168.1.2:/mnt/user/tftp/images/CentOS/x86_65/install.img repo=http://mirror.centos.org/centos/6.4/os/x86_64/ lang=us keymap=us ip=dhcp ksdevice=eth0 noipv6 TEXT HELP Install CentOS 6.4(64-bit) ENDTEXT 1. Copy initrd.img and install.img to the following folder: /mnt/user/tftp/images/CentOS/x86_64/ 2. Correct the IP Address of your unRAID and fix the typo I made (I will fix later tonight). You will see I have x86_65 and not x86_64 for the install.img. 3. Again I created a share in unRAID and told it to use only the cache drive. I also have it shared using NFS. Because of this, you have a "share" which to unRAID is /mnt/user/tftp. That is why you will see a lot of menus using /mnt/user/tftp instead of /mnt/cache/tftp. Thanks grumpy, I'd already spotted the typo though forgot to mention it in my original post - thanks for drawing it to the attention of others following in my footsteps! I've managed to get it working now, it seems the error I was getting was because there are no files at the repo address in the menu file. I replaced repo=http://mirror.centos.org/centos/6.4/os/x86_64/ with repo=http://mirror.centos.org/centos/6/os/x86_64/ and it all worked! Not sure if there is an advantage/disadvantage to just going with 6 rather than 6.5, as it seems both were viable options. Hopefully now I've got one going I should be able to work out the rest. Thanks so much for providing this guide! Has been a job on my 'to do' list for a while, and your guide has made it a relatively painless experience!

Hi grumpy, thanks for another brilliant guide. :-) Have got Clonezilla working, but am stumped on CentOS. Could you possibly share a little more about how you had your server configured - in terms of share/file/folder structure? For example in the CentOS menu file you kindly provided I believe it references an NFS share - what is this share used for? As I'm able to get the installer to start but it says it's unable to find to installation files - finding it a little confusing since I thought the installer was already running! I'm guessing this NFS share plays a role that isn't required for Clonezilla, as I see no mention of it in the corresponding menu file. Any hints would be much appreciated! Sent from my Nexus 7 using Tapatalk

Thanks for sharing jack0w. Looks like your server is also immune to influence from the md_sync_window. I really need to add 384 back into the FULLAUTO routine so I can see if there's any improvement over stock. I was skipping it based upon the assumption that higher values are faster, but so many results have proven that assumption wrong. -Paul I'll happily re-test once you put up the next version! Thanks for creating and updating this for the good of the community, I appreciate it, and I'm sure plenty of others do too

I love this idea, if it were stored in the superblock.dat you could have a warning when it's older then a configurable time, or even automatically kick one off after a specifed number of days. if emhttp touched a file on the flash drive when a parity check/sync finished, it could be used as a timestamp semaphore also. Probably simpler then updating the superblock. Easy enough to test and get the date stamp of the file for displaying. Really keen on this idea too! +1

Thanks for creating this, I've been following this thread with interest Just in case it proves useful to you, here is my output after running the FULLAUTO option. All my drives are 3TB WD Reds, except 1 which is a Hitachi 3TB. They are all connected to a M1015: Tunables Report from unRAID Tunables Tester v2.2 by Pauven NOTE: Use the smallest set of values that produce good results. Larger values increase server memory use, and may cause stability issues with unRAID, especially if you have any add-ons or plug-ins installed. Test | num_stripes | write_limit | sync_window | Speed --- FULLY AUTOMATIC TEST PASS 1 (Rough - 20 Sample Points @ 3min Duration)--- 1 | 1408 | 768 | 512 | 118.5 MB/s 2 | 1536 | 768 | 640 | 118.5 MB/s 3 | 1664 | 768 | 768 | 120.3 MB/s 4 | 1920 | 896 | 896 | 118.5 MB/s 5 | 2176 | 1024 | 1024 | 120.3 MB/s 6 | 2560 | 1152 | 1152 | 118.5 MB/s 7 | 2816 | 1280 | 1280 | 118.6 MB/s 8 | 3072 | 1408 | 1408 | 120.3 MB/s 9 | 3328 | 1536 | 1536 | 118.5 MB/s 10 | 3584 | 1664 | 1664 | 120.3 MB/s 11 | 3968 | 1792 | 1792 | 118.5 MB/s 12 | 4224 | 1920 | 1920 | 118.6 MB/s 13 | 4480 | 2048 | 2048 | 120.3 MB/s 14 | 4736 | 2176 | 2176 | 118.6 MB/s 15 | 5120 | 2304 | 2304 | 118.6 MB/s 16 | 5376 | 2432 | 2432 | 120.3 MB/s 17 | 5632 | 2560 | 2560 | 118.6 MB/s 18 | 5888 | 2688 | 2688 | 120.3 MB/s 19 | 6144 | 2816 | 2816 | 118.5 MB/s 20 | 6528 | 2944 | 2944 | 118.6 MB/s --- Targeting Fastest Result of md_sync_window 768 bytes for Final Pass --- --- FULLY AUTOMATIC TEST PASS 2 (Final - 16 Sample Points @ 4min Duration)--- 21 | 1568 | 768 | 648 | 120.3 MB/s 22 | 1576 | 768 | 656 | 119.0 MB/s 23 | 1584 | 768 | 664 | 119.0 MB/s 24 | 1600 | 768 | 672 | 119.0 MB/s 25 | 1608 | 768 | 680 | 119.0 MB/s 26 | 1616 | 768 | 688 | 120.1 MB/s 27 | 1624 | 768 | 696 | 120.3 MB/s 28 | 1632 | 768 | 704 | 119.0 MB/s 29 | 1640 | 768 | 712 | 119.0 MB/s 30 | 1648 | 768 | 720 | 119.0 MB/s 31 | 1656 | 768 | 728 | 119.0 MB/s 32 | 1664 | 768 | 736 | 120.3 MB/s 33 | 1680 | 768 | 744 | 119.0 MB/s 34 | 1688 | 768 | 752 | 119.0 MB/s 35 | 1696 | 768 | 760 | 119.0 MB/s 36 | 1704 | 768 | 768 | 119.0 MB/s Completed: 2 Hrs 7 Min 32 Sec. Best Bang for the Buck: Test 1 with a speed of 118.5 MB/s Tunable (md_num_stripes): 1408 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 126MB of RAM on your hardware. Unthrottled values for your server came from Test 21 with a speed of 120.3 MB/s Tunable (md_num_stripes): 1568 Tunable (md_write_limit): 768 Tunable (md_sync_window): 648 These settings will consume 140MB of RAM on your hardware. This is 25MB more than your current utilization of 115MB. NOTE: Adding additional drives will increase memory consumption. In unRAID, go to Settings > Disk Settings to set your chosen parameter values.

If I remember correctly, that is because unMENU adds a -d ATA parameter to the smartctl command. The driver for the motherboard interface doesn't care if it's asked to behave as an ATA (parallel) drive, but the LSI driver objects. If the -d ATA parameter is removed from the command line, the driver for both interfaces will respond as required. Try typing this command at the command prompt: smartctl -a -d ata /dev/sdX (where X is the last letter of your drive identifier - a, b, c etc) You will find that you get a SMART report for drives on the motherboard interface, but you will get an error for drives on the M1015 interface. Makes perfect sense why it wasn't playing ball to start with now.. I even managed to find your post earlier in this thread once I knew to search for '-d ATA' ! I've managed to find out how, and add a custom parameter in unMENU for the drive connected to my M1015, and now have temperatures showing for both. Many thanks for your help! In case anyone finds this post in future, I found how to do this here - http://lime-technology.com/forum/index.php?topic=9337.msg141761#msg141761 How to accomplish the same in SimpleFeatures is another matter, but I will take that question to the appropriate sub-forum, assuming searching comes up with nothing Thanks again!

Should work no problem with P10. What version of unRAID and unMenu are you running? I'm using unRAID 5.0-rc10 and unMENU Version 1.5 Revision: 246 Since my post just now, I've also noticed that simplefeatures doesn't show the temperature for either drive when spundown - though not sure if that's relevant. I'm in the middle of pre-clearing a new drive at the moment, so I'm not able reboot and try without simplefeatures running at the moment.. guessing this may well be the next step in troubleshooting this? Thanks for taking the time to assist.

Quick question - I have two identical 3TB WD Red Drives, one as parity drive connected to onboard SATA controller, and the other as a data drive connected to M1015. In unMENU I can see the drive temperature for the one connected to onboard while spundown, but not for the one connected to the M1015. I flashed the M1015 using the P10 firmware. a) I'm not sure if this is expected behaviour or not? b) Am wondering if perhaps I need to use a more recent firmware. Any input would be much appreciated

Hi there hope this isn't too sillier question!! I'm on the verge of embarking on my first unRAID build and I'm trying to choose a PSU. Since I have some Amazon vouchers I was hoping to purchase from them. I see that the 'SeaSonic X Series X650 Gold 650W' is recommended on the first page of this thread, however this one doesn't seem to be available, all I can find is the Seasonic X-660 660W - http://www.amazon.co.uk/Seasonic-X-660-Watt-Power-Supply/dp/B004DRZI4Y/ Is this a typo on page 1? Or, in the event this is a different PSU, would this be suitable for an unRAID server? Thanks in advance for any advice offered!