Jump to content
Covecube Inc.

gamechld

Members
  • Content Count

    6
  • Joined

  • Last visited

  • Days Won

    2
  1. Issue resolved by updating DrivePool. My version was fairly out of date, and using the latest public stable build fixed everything.
  2. Done! Thanks for looking into it! I'll do some hardware testing this weekend and try and rule out some things.
  3. I have actually been having this issue for quite some time (months), but instead of investigating a solution I stopped doing edits over SMB and instead remote connected to the server and did my file changes directly from the server. I wasn't sure if the problem was with Drivepool or my hardware. I just ran the StabeBit Troubleshooter, so you should be receiving some info from me with the dumps and whatnot. Some of the BSOD's referenced bad pool headers, but some did reference cove.fs. I'll try and run some memory tests as well to see if my memory is in good order. But yeah, its instant crashes for me. If I navigate to a network path for a drivepool share, and do a cut/paste or delete stuff, instant BSOD. Seems the problem has been exacerbated lately where I can't even view the folder anymore over SMB without it crashing.
  4. Confirmed it. Last night I replaced my library paths from mapped drive letter to UNC paths. Plex's partial scanning capability is functioning properly. Much thanks. This is much better. With the mapped drive letter, Plex doesn't receive a flag that the contents of a folder changed, so no partial scans, which means I had to run frequent WHOLE LIBRARY scans to ensure content was added to Plex in a timely manner, which is just not a good method. So cheers! Thanks for saving me days of copy time, as well as an OS format and other such nonsense!
  5. Oh I hadn't realized that mapped drives would function differently than network shares. Just to be clear, you mean sharing the folder then telling Plex the UNC path instead of the mapped drive letter? [e.g. \\Server\Movies] Thanks a bunch for your help. If this allows fast scan to work again, you've saved me many hours of copying!
  6. I am currently in the process of moving my storage drives to a new separate 24-bay enclosure. My original plan was to have Drivepool running in that storage box, and map the pool as a network drive to my new machine that I am building. However, I've realized that mapped drives have some limitations for my particular scenario. It would work, but it would be BETTER if the drives appeared as physical drives to the new machine instead of mapped. (Plex Media Server has a partial scan feature that can run a mini scan based on seeing if the contents of a folder changed. Works on normal drives, but not mapped network drives). So I did some research into iSCSI as a solution. I've seen posts that say I should have no trouble adding iSCSI disks to a pool. At the same time, what I've learned about creating an iSCSI Target using Windows Server requires VHD's. Which I take to mean I will need to make a drive sized VHD on each physical drive, add those to the VHD target, then connect to the target from my new machine and add those iscsi connected drives to Drivepool running on the new machine. Am I correct with that course of action? If I am correct, I will need to do this drive by drive in order to preserve my data. Basically my plan is: 1) Empty a drive from old pool. 2) Create VHD on empty drive that is the size of the whole drive. 3) Add VHD to iSCSI Target. 4) Connect to Target using new machine as Initiator, and add drive to new Pool on new machine. 5) Empty another drive from old pool onto the NEW pool and repeat the process. END RESULT: -All drives reside in large enclosure -All drives mapped to new machine via iSCSI -New Drivepool running on New machine see's all drives as physically attached Does that sound like a correct plan, or am I needlessly complicating things? I assume the following: A. I cannot add a drive with existing data to iSCSI Target, because it needs VHD's, which is not how the drives are currently setup. B. I cannot make a single VHD for the Target from the pool itself because a pool sized VHD is impossible; cannot have a VHD be bigger than the individual drives in the pool. I would love to hear anyone's thoughts!
×
×
  • Create New...