Jump to content
  • 0

Google Drive: Cant Upload, 'The requested mime type change is forbidden'


Jonathan

Question

My setup is:  30TB via single google drive cloud drive.  That's broken up into two 15TB NTFS partitions, using 7TB on one and 4TB on the other.  Everything was working fine... but about a week or so ago i started to get thousands of errors: "The requested mime type change is forbidden".  This occurs when uploading.  I have about 40GB sitting in my 'To Upload' and it hasn't moved in a week, even though the upload rate has been over 100mbps, practically constantly.  Any ideas what this error is and how to fix.  I think I have tried everything I can on my end, reauth, etc... Thanks.

Link to comment
Share on other sites

Recommended Posts

  • 0
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.
Link to comment
Share on other sites

  • 0

.682 is working fine for me and its the newest. you can read the changes.txt whenever you see new builds to see if you want to test the new stuff out.

 

their rule though is that you should always be two numbered versions behind according to the changes.txt if you want a guarantee everything works.

 

They are really listening to the community and using our input to improve the product, which has become quite amazing. Personally i cant wait to see the final result they end up with

Link to comment
Share on other sites

  • 0

 

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?

 

 

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.

 

 

 

  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. 

Link to comment
Share on other sites

  • 0

 

  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.

Link to comment
Share on other sites

  • 0

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.

 

If you could grab the logs, just in case. 

 

Also, it may have been an optimization that caused this.  I'm not really sure, but the logs may indicate what happened. 

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

Link to comment
Share on other sites

  • 0

If you could grab the logs, just in case. 

 

Also, it may have been an optimization that caused this.  I'm not really sure, but the logs may indicate what happened. 

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

 

Unfortunately I don't think I can do that because I can't reproduce the error. I've since upgraded to .682 and don't have the issue anymore.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...