Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

30 Good

About Joseph

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. +1 for limit share size. 6.8 has an option for Time Machine, but it's help info is unclear if it is for any kind of user share or exclusively for TM.
  2. Noob here, so consider the source! 😬 I went thru a gauntlet of things that I tried (and mostly failed) in an attempt to migrate from the plug-in version of EMBY to the docker container. Another user posted some steps and I documented things that I thought worked, but mostly didn't. It starts around page 142 or 143. In the end, after updating unRIAD to 6.4 the process somehow became much simpler and magically worked. I wish I knew why, but on page 144 what seemed to have worked, at least back then anyway, was to make sure to set the mappings properly for the content/appdata/etc. Hope this helps... don't forget: backup, Backup, BACKUP!!!
  3. @johnnie.black Thanks for the quick reply! I'll set all values to default then... fwiw, I'm running 20 drives in the array (incl. dual parity), also raid 1 cache on my production box and a few devices outside the array, so it sounds like I might be pushing it? Lemmie know. Thanks!!
  4. Hey unRAIDers!! So, it's now, 2020; can anyone offer any advice as to whether or not the tunables script is to be trusted on unRAID v6.8.3? I was able to get the update from the link that @Squid provided working via cli (sort of) with errors; thanks to the post from @Marshalleq (example below): /usr/local/sbin/mdcmd: line 11: echo: write error: Invalid argument Test 1 - md_sync_window=384 - Completed in 601.464 seconds = 96.6 MB/s The final "Best Bang for the Buck" results show the following... On my production box (Supermicro [I suspect either] AOC-USAS-L8i, [or] AOC-USASLP-L8i) Current in disk.cfg | New Setting ----------------------------------------------- md_num_stripes="4096" | md_num_stripes="1536" md_write_limit="" | md_write_limit="768" md_sync_window="" | md_sync_window="640" Not Saved. Exiting. and my backup box (2 Dell H310s): Current in disk.cfg | New Setting ----------------------------------------------- md_num_stripes="4096" | md_num_stripes="1280" md_write_limit="" | md_write_limit="768" md_sync_window="" | md_sync_window="384" Type SAVE (uppercase) to modify disk.cfg Not Saved. Exiting. Any input, thoughts, etc. are much appreciated!! I feel like this is a message in a bottle, but I hope someone will respond soon. Thanks in advance!
  5. +1 for Emby; I don't do transcoding either and it works just fine when using Emby Theatre on my HTPC. Don't have much issue with it other than the occasional/rare docker crash where you just need to restart it. I also have a Plex subscription, but I don't use it for streaming video. I like the look/feel/metadata usage of Plex for audio; Emby for video.
  6. Joseph

    Share Your Banners

    Cool! I know at some point after v6.5 or so, the banner format has changed so this one might be limited in its ability to scale. Anyways, I hope it works out.
  7. Joseph

    Share Your Banners

    Take a look and see if these will work (my blank templates are offline at the moment, so the size may not be correct)
  8. Joseph

    Share Your Banners

    Sure... I’ll be happy to take a stab at it tomorrow; if I can distract the Mrs. for a few minutes I’ll start on it tonight
  9. True, if it's generic and wasn't specific to an actual change in the array.
  10. That's kinda what I was thinking. But like you said, developer time might be better spent on other more important issues.
  11. Perhaps it would know the file system is no longer the same as it once was and/or the power on hours from SMART have changed since it was last shut down? IDK
  12. So my first assumption was correct: starting unRAID at Step 3 would have killed the contents forever. My concern for raising this as an issue is, unRAID would have known something was wrong if it was a different disk and alerted the user. But because it was the same drive, it thought all was well. Perhaps that's by design, but some kind of warning would have been nice. IDK. LOL @jonathanm...TRUE! It doesn't make sense and I hope no one would ever try it -- especially on a production box. But since this was on a test box, had I have lost the contents, it would not have really mattered. FWIW, I needed an extra 4TB of space on a mac and didn't have any drives laying around large enough to complete the project. (whatever data I had on that drive, has been restored since I ensured unRAID understood that drive was 'lost' and it rebuilt the contents from parity.) My apologies to everyone if I've wasted time on a non-issue, but it seemed like a way to improve the product to "save the user from themselves" for those of us who suffer from 1D10T errors.
  13. Ok, thank you. I was concerned based on the 'new contents' of the physical disk, it would have destroyed the virtual contents held by parity and the data that used to be on the disk would then be forever lost... which is why I thought it might need to be reported as a 'bug', annoyance, or whatever. It would still be nice if there was some way that unRAID could somehow recognize when a disk has drastically changed prior to startup to warn the user. But thank you again for looking into it.
  14. Thanks Squid for the info. So, to make sure I understand... in my case, even though the drive was returned to unRAID but partitioned as OS X Journaled, had I started the array in step 3, unRAID would have continued to 'work' and once a parity check was done, it would have restored the partition of that drive back to XFS and rebuild the contents of that drive from parity?