gounlimited.to | BANNED FROM WJ
- Thread starter GO Unlimited
- Start date
- Status
GO Unlimited
Active Member
GO Unlimited
Active Member
Bounce credited! Thanks for giving us some of your time.
GO Unlimited
Active Member
Nope. The greatest thing is coming this Monday.
GO Unlimited
Active Member
Dear Partners,
Couple of users reported a bug that 90% of users may not face, but we must bring it into everyone attention.
What is the bug exactly?
This bug isn't related to web upload, but only URL Upload and Clone Upload. After cloning or URL Uploading a file the system will generate you a link of the file URL or the new clone URL, right? This link is right, but if you checked this link IMMEDIATELY you may see a message says that this file doesn't exist or it has been deleted. However, the link is fine, and so as the file, but you only need to wait for few minutes to be able to stream the file because there is a short delay on the database which causing this error. Once the file starts working after few minutes it will work fine permanently and you won't face this error again because it's related to the preparting time that the DB is taking in the beginning only but once the file is prepared and started to work then there is nothing to worry about. As mentioned, this bug is not related to the web upload, but only URL and Clone, and it happens in the morning only and not all the day, since the morning is the peak upload time.
You can share the link/embed code on your website and they won't face this bug because it's related to the uploader account only and not the front end of the website. It's within the panel bug and not external one.
What's the reason of this bug?
We work on multiple databases and not a single one, let we say we have:
- Original DB (Not connected to the internet, for internal use)
- DB 1
- DB 2
- DB 3, etc.
Once you upload a file using URL or Clone, the system register your file on the original DB, and when you check your file to test it, DB 1, or DB 2, or whatever Mirror DB that respond to your request may not have an idea about this file because it didn't update itself yet with the original DB, so the original DB have the file code but the mirror databases didn't yet have it registered. Mirror DB's must update themselves with the original DB every 0.6 seconds, so you shouldn't face such error ever, but due to the load that mirror DB's have, they're optimized to delay the update up to 10 minutes in some cases in order to reduce the load they're facing so they can process everything smoothly, but the bad part in this case that during these 1-10 minutes delay the recently uploaded file using URL or Clone may not show the proper page you're expecting, but after the update after these few minutes the file code will be registered on all mirror DB's and the bug is resolved.
As I said, it's not a common thing, but very rare but just in case someone face it this explanation should give him an idea about what he is facing.
What's the solution we're working on?
We will follow the same logic we followed with the WebUpload (which is why it doesn't have this bug), which is using a totally different machine to register the files codes and cache them into a dedicated cache system and deliver them to the partner/user/wather end from there so even if the check their files immediately after the URL/Clone upload they don't face such simple error.
P.S:
The mentioned bug doesn't affect the watcher/visitor end, but only the uploader/user, and regardless that it is super simple bug, it may cause some confusing, which is why we're working on it urgently.
ETA:
This week.
Couple of users reported a bug that 90% of users may not face, but we must bring it into everyone attention.
What is the bug exactly?
This bug isn't related to web upload, but only URL Upload and Clone Upload. After cloning or URL Uploading a file the system will generate you a link of the file URL or the new clone URL, right? This link is right, but if you checked this link IMMEDIATELY you may see a message says that this file doesn't exist or it has been deleted. However, the link is fine, and so as the file, but you only need to wait for few minutes to be able to stream the file because there is a short delay on the database which causing this error. Once the file starts working after few minutes it will work fine permanently and you won't face this error again because it's related to the preparting time that the DB is taking in the beginning only but once the file is prepared and started to work then there is nothing to worry about. As mentioned, this bug is not related to the web upload, but only URL and Clone, and it happens in the morning only and not all the day, since the morning is the peak upload time.
You can share the link/embed code on your website and they won't face this bug because it's related to the uploader account only and not the front end of the website. It's within the panel bug and not external one.
What's the reason of this bug?
We work on multiple databases and not a single one, let we say we have:
- Original DB (Not connected to the internet, for internal use)
- DB 1
- DB 2
- DB 3, etc.
Once you upload a file using URL or Clone, the system register your file on the original DB, and when you check your file to test it, DB 1, or DB 2, or whatever Mirror DB that respond to your request may not have an idea about this file because it didn't update itself yet with the original DB, so the original DB have the file code but the mirror databases didn't yet have it registered. Mirror DB's must update themselves with the original DB every 0.6 seconds, so you shouldn't face such error ever, but due to the load that mirror DB's have, they're optimized to delay the update up to 10 minutes in some cases in order to reduce the load they're facing so they can process everything smoothly, but the bad part in this case that during these 1-10 minutes delay the recently uploaded file using URL or Clone may not show the proper page you're expecting, but after the update after these few minutes the file code will be registered on all mirror DB's and the bug is resolved.
As I said, it's not a common thing, but very rare but just in case someone face it this explanation should give him an idea about what he is facing.
What's the solution we're working on?
We will follow the same logic we followed with the WebUpload (which is why it doesn't have this bug), which is using a totally different machine to register the files codes and cache them into a dedicated cache system and deliver them to the partner/user/wather end from there so even if the check their files immediately after the URL/Clone upload they don't face such simple error.
P.S:
The mentioned bug doesn't affect the watcher/visitor end, but only the uploader/user, and regardless that it is super simple bug, it may cause some confusing, which is why we're working on it urgently.
ETA:
This week.
GO Unlimited
Active Member
Don't worry. With minimal ads mode views are not counted on the user end, but they're in the backend, so your files shouldn't expire due to this, since the system is properly counting these views in the backend but not recording them on your stats since you disabled the affiliate program.
It's smart though that you thought about this, but we got your back so don't worry.
GO Unlimited
Active Member
Couple of users have been provided with the RDP, in order to test it.
Everything seems smooth and reliable so far, and the upload speed is excellent.
We will try to connect the new servers we ordered for the RDP into our server collection as soon as possible, maybe this week or the next one, still not sure. Once the RDP and the Uploader Server are connected on the same cable we will start offering the RDP service with extremely high uploading speed into GO Unlimited since both of the RDP and the Uploader Server are connected on the same exact networks locally (LAN) and externally as well.
That's besides that we don't want to go live before we make sure that the hosting staff we have is enough to handle the unlimited Windows issues, and support the customers with their issues, because between many online services, RDP may be one of the hardest. And of course no one can work on RDP's support, management, installation, etc except Indians. I don't know what's the relationship between Indians and Microsoft, but they're doing great job on it.
GO Unlimited
Active Member
I understand. Will get it ready for you and all partners ASAP.
Sorry my bad is a country, i thought you were from this country..
Last edited:
Wow! Thank you for the amazing news!!
Hope in one day you go and visit all of them.
- Status