Ziggeo uploads failing across multiple plugins

Hi, is anyone else experiencing ziggeo uploads failing? We are seeing a number of different issues with our current plugin (Ziggeo Recorder and Player Plugin | Bubble) and the bubble plugin. This happens for both ourselves and our clients. Here are some screenshots:
ziggeo screenshot 2
ziggeo screenshot 3
ziggeo screenshot

Is anyone else experiencing this type of stuff? It doesn’t always happen, but it happens the vast majority of the time for videos above 1 gig. I have an email out to @bane and will post updates.

Hi Jacob,

I see the new ticket in our system. I will say that it should work just fine and seeing the screenshots it looks like these are test accounts - not your own account - due to the watermark.

Can you try with your own API token to be safe it works fine?

  • Note: I am going to go through more details from our earlier discussions, just wanted to help out first with what seems to be most likely cause. Will follow up with more details afterwards.

Thank you for the responsiveness, Bane. Got the test account error resolved; something wiped out our API tokens (not sure if it was a bubble update or what, but I don’t believe we did anything on our end). Pluggin update largely resolved the issues. Our users still struggle with uploading large files, but we upgraded our internet to 70Mbps upload / second and started using ethernet which resolved the issue for us, so now we workaround by having them drop their videos into Google Drive for us to upload for them. It’s not optimal, so hoping there’s something in the works to improve the “verification failed” issue for large uploads. Our users often upload straight from their Iphones and there’s not a great ethernet solution for that without purchasing pricey equipment. Could intermittent internet be an issue for uploads? -Jacob

Glad to hear that it is working fine for you now Jacob. Now in terms of the internet, that is true, connection can play a significant role. Unfortunately there is only as much as we can do about the same.

Now our system is built with the detection that if something went wrong so that it re-uploads the data. This has been part of our service for a very long time now (even in v1). While useful it would not be able to detect if your device sends us damaged data.

I am guessing that this is what is happening in your case, where the upload gets interrupted in such way that it seems to always be working fine, yet some packages end up being damaged in the process. This would also make sense for long uploads as there is higher chance of something going off. I am intentionally saying long because 1GB for one connection can be few seconds and for another it could be few hours. Also with phones, even if you are using WiFi you can loose the connection as you move around.

Our r38 (not yet released officially, just as developer revision) has a different way of uploading files. This is something that our team was playing around with and while we can not do much about connection quality this should help the uploaded data being uploaded in a safer manner. So by using this you should be able to go around the need for re-uploads.

Now to change this in the plugin you are using, you would go into header section where you added the application token and change the revision to r38. Keep in mind that this is our revision that we are constantly changing so until it is officially released some errors can slip our screening and show up within it.

For that reason I would not suggest using it just yet, however if you wanted, you could use it to test things out.

Hope this helps :slight_smile:

Cool, stoked to check out r38. Won’t turn it on yet since we’re a live business. Seems like what YouTube and Vimeo use gets around interrupted connections & excited to try r38. Looking forward to the update. Thank you, Bane. Will keep you posted if our issues persist; we’ll give guidance to our users on large uploads to use ethernet.

This topic was automatically closed after 14 days. New replies are no longer allowed.