Lev

Members
  • Content count

    241
  • Joined

  • Last visited

  • Days Won

    3

Lev last won the day on November 5 2017

Lev had the most liked content!

Community Reputation

48 Good

About Lev

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • Personal Text
    Supermicro X9, 128GB ECC DDR3 @ 1600Mhz, 90TB (2x 6TB WD, 8x 8TB WD), 1x LSI9308 Cache: 2TB Crucial SSD

Recent Profile Visitors

435 profile views
  1. Update got it working. It was as I thought "something painfully simple"... It works as you'd expect. What caught me up was having a existing queue in NZBget. I now know that each of those items in the queue, are set to the paths configured in NZBget at the time they are added to the queue. So with my existing queue, it wasn't until it got caught up to when I made the path changes changes that I saw log messages of those new downloads trying to hit my container path mapping for /InterDir/ (nzbget.conf) that was mapped to /tmp (unRAID Docker container path settings for NZBget container) Thanks @neilt0 this thread continues to deliver over 4 years later since your OP! @trurl thanks for helping me keep my sanity that what I was doing was doing all along was correct.
  2. So far I've killed one SSD every 1.5 years, and the cheap ones die. It's not the cost, like you said they are cheap, but ugh I'd rather be spending my time on so many other projects than replacing them. RAM maybe my answer.
  3. Yes, I was thinking the same thing, but so far have failed miserably in my attempts to try it. I've tried multiple different ways mounting /tmp or tmpfs, that part works, best I can tell. I'm able to successful from the bash shell within the NZBget container see the mapped mount point and even create and edit files, and see them back on host. A+, I'm solid here. Where the trouble lies is getting the app NZBget to use that mount point. I've edited the appropriate /InterDir in the 'Paths' section of settings. I've double checked the nzbget.conf file to ensure it matches, but no matter what, NZB get ignores it and falls back to $MainDir/intermediate I've yet to enable debug logging for NZBget, but that's where I'll look next. I expect it must be some permission problem with the mount and tmpfs as a device type. All I know is it shouldn't be this painful, I must be missing something painful simple.
  4. Maybe I'm asking in the wrong way, or I'm missing something cause here's what I'm observing having tested this for the last hour and getting a bit frustrated that I searched and foudn your thread Article cache based on what I'm observing keeps all of these individual of a RAR in RAM, like you have in your example here, all of these guys are in RAM. Only once all of the pieces of a RAR have been downloaded, it moved out of the article cache (RAM) and written to disk (/InterDir) as you show in your written into the complete single RAR file, just like you explained here: What I'm trying to do is keep all those completed RAR files in RAM rather than written to the /InterDir disk, therefore I'm trying to make InterDir be a ramdisk. I think this is the next logical step beyond what you were doing in 2013 (glad you're still here!) using temp (tmp). You're right that article cache solves the problem you were curious about, however based on my tests it does not also apply to keeping the completed RAR's in memory as well. I'm still observing those written to /InterDir, until they are all downloaded and finally unpacked and moved to /DestDir. Does this align with what you know? Expect to be called crazy for wanting this, as it means gigabytes of RAR's stored in memory that could easily be lost and have to redownload again in the event of a server reboot.
  5. I like this old thread, shows how far things have progressed such that we have so much RAM to ask the question... what if we never want to write the RAR file to SSD or Disk, we want it to remain in RAM, such that the only thing ever written to SSD or Disk is the final contents of the RAR?
  6. I would like to buy a new 9400-16i

    Nice! thanks for reporting back! It'll help others in the future who are curious about if anyone has tried the card.
  7. Still have more of these chassis for sale! Since I'm in the holiday spirit (and I want to free up rack space!), price reduced between now and Dec 25th, 2017 to $350.00, local pickup preferred.
  8. [-rc15e, 16b, 17b] IPMI Issues

    No issues here on a X9 motherboard. I have another X9 and X8, but have yet to upgrade them.
  9. Rails, Fan Wall, and since we live in wonderful California, no sales tax!
  10. Sparklyballs' Repo- Sparkly Stuff In Here

    @gmac13 @richardsim7 Answer found to how to bring back up the file transfer status window in Krusader once you've clicked away.
  11. Krusader Transfer Window

    If you know of a better place to post it, let me know. I'll post a link back to it from the Sparky-Repo thread. I found this thread by searching to see a answer existed. If someone ever takes over the Sparky Krusader to update it, this was one of two possible solutions to the problem, the one I posted is the easiest and requires no changes to the container. The other solution (assuming it works) that I first started going down the path of trying to build wmctrl inside the container. Seems like wmctrl would make it possible to add a button inside the container on the Krusader GUI and Menu, but it requires some additional work.
  12. Krusader Transfer Window

    @tillkrueger @jenskolson @trurl @unrateable @jonathanm @1812 @Squid since all of you were active in this thread. I found a way to get the file transfer back. Bring up the Guacamole left panel menu (CTRL ALT SHIFT) Input Method = On Screen Keyboard In the On Screen Keyboard, use ALT (it'll stay on, 'pressed') then TAB, select it using TAB, then ALT again (to turn off) A tip I found too, is that anytime doing a copy or move, always best to use the 'queue' button in the pop-up confirmation dialog so that multiple transfers are sequentially handled. It's easy to get to the queue, I found using this it often mitigates much of my need to see the file transfer progress window. The 'Queue Manager' is easy to get back on the screen by using the top menu, Tools > Queue Manager
  13. This is probably the 4th time this has happened after upgrading to the latest release. Maybe it's happened more, and I just wasn't paying attention. After applying a new unRAID rc, upon the first reboot, it fails to detect the NIC. Only br0 and loopback are present when I login at the local terminal and do ifconfig. Doing a power-down and cold boot fixes it, and every reboot from then forward is fine with no issues. Seem to only be the reboot after the upgrade. Sadly I didn't get a diagnostics. I will next time. Otherwise everything else works great.

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.