Jump to content

HotDogSandwich

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by HotDogSandwich

  1. He means the importing of titles to the library.

     

    This will get better when they get an advanced pinning engine done, but for now the indexing is really slow, so remember to turn off auto update in plex and disable prefetch while indexing if you want to save bandwidth

     

    Now I understand, I'll disable prefetch when I do my initial index. If I turn it back on after the initial library load, will it work okay to be auto scan for new titles?

  2. It might be necessary to adjust the prefetching depending on whether you are importing or watching content.  From what I understand of prefetching, it's saying that anytime more than 1MB (the prefetch trigger) is downloaded, it will continue to download another 100MB (the prefetch forward) from that same file with the assumption that will will need that part too. This is a good assumption when you are playing the whole file, and it certainly seemed to smooth out many of the playback issues I encountered when I first started using CloudDrive with Plex. However, if you are importing a ton of media to your Plex library, it might be overkill to download that extra data (especially set at 100MB forward), and it will probably end up slowing down the import process quite a bit. At the moment, I am experimenting with reducing or disabling prefetch during import and turning it back up when I'm done. 

     

    What do you mean by importing?

  3. To be honest, those settings look good, for the most part.

     

    I'd reduce the threads to 10/10, so you're not overusing the API rates.   And I'd set to "Prefetch forward" to 100MB.  

     

    Otherwise, I'd say use it and see how it goes. 

     

    Thanks - I'll try those modifications and see if there is any improvement.

     

     

    Side question - currently I'm using a dedicated 240gb SSD as my cache drive, thinking that an SSD will perform better for my use case. Would I be better off having a larger non-ssd drive, like say a 4tb spinning drive, or is the smaller SSD route sufficient? 

  4. Seems like this topic is discussed a lot, so I'd like to see if we can agree on some recommended settings for Plex and post them here.

     

    So the question is... assuming a 1000/1000 gigabit connection, what CloudDrive settings are ideal to achieve reliable library scanning, as well as the ability to stream/transcode multiple (5-10) simultaneous streams.

     

    I'll start with the settings I'm currently using, but please chime in as necessary and I can update the thread as we go. Thanks for your input!

     

    Create Drive Settings:

     

    ER4lPA1.jpg

     

    I/O Performance Settings

     

    M13bI3w.jpg

  5.  

    1. It should "automatically resolve" after a few hours (or 24, depending on Google).  

      Unfortunately, the best option is to create a new drive and use that instead. That will completely avoid the issue altogether. But it isn't a great solution. 

    2. Yes, you can just upgrade in place.  Backwards compatibility with provider changes is maintained so that there is no issue with upgrading. 

       

      As for why a public beta hasn't been pushed, is there are a lot of changes, and some big issues that have come up, in quick succession.  We're also hoping to get something closer to a release candidate out, and have been running internal testing.  

       

      Unfortunately, because of how complicated the software is, I can't just give an estimate when we'll have a new public build out.  The sooner the better, as both Alex and I are getting antsy about this.  But we don't want to just push out a release that may cause a bunch of issues either. 

     

     

     

    That said, if you want to try the later builds, always ask.  Either PM me, contact me via the support site (https://stablebit.com/Contact) or ask on the forums.  

     

    The general rule of thumb for the internal beta builds is to check the change logs.  The builds that are specifically numbered in the log (for instance .682, .680, .667, .642) are "more stable" and the rest are "in flux" as Alex (the Developer) is actively changing code in the unnumbered ones (for testing).   You'd want to grab the second numbered build, as this is much more likely be stable, as it's been a bit more tested. 

     

    In this case, the 1.0.0.680 build is the one you'd want to grab by this rule. 

     

     

    Thanks. I installed .682 and the issue went away, however my "to upload" went from 102gb to 0gb in about 10 seconds, so I'm not confident that something didn't get screwed up.

     

    At this point, I think it's safest to destroy and rebuild, which I'm not too thrilled about since I've uploaded 1.7tb already.

  6. I have two questions regarding this problem which I'm also facing in v 1.0.0.463 beta.
     
    1. How do I identify which chucks I need to delete to resume uploading?

     

     

    Better yet: 1.0.0.467

    http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.0.0.467_x64_BETA.exe

     

     

    This should handle the error properly now (essentially by deleting and reuploading it automatically). 

     

     

    2. I just downloaded v 1.0.0.463 beta, which is what I'm currently using. Why is it that version 1.0.0.467 referenced here was available back in February, but the currently available version is 1.0.0.463? If I install 467 on top of my current install will it fix the problem?
     
    This is a deal breaker for me if this problem can't be fixed.
×
×
  • Create New...