unfortunately I am not a big friend with terminal & logs. No idea how to open the app in terminal on windows and where to find logs. The file is still not uploaded but looking at my ATN account, I already paid for it - how many ANT transactions is normal for such a small file? I have a lot of them.
edit: so it failed after 37 minutes 
edit 2: I successfully downloaded my first 2 files from Autonomi!
Your download seems to be working well. Iām not sure about the upload. I havenāt encountered any failures yet through the GUI with files of that size. Iāll work on better error handling over the weekend to hopefully prevent false failures from sneaking through to the GUI level. If you try uploading the same file again, does it go through on the second time? You wonāt be charged again for the chunks that successfully uploaded. It could be it threw errors during the process, but it actually successfully completed. If you upload it again, it may be good. In other words, it doesnāt hurt to mash the button a couple times 
The latest release has a random private wallet key generated on startup now. This will be much safer, no longer will you need to worry about a bot scraping your tokens. NOTE: I still think it is much better to use a key from a proper vetted wallet like MetaMask. The key is random, but random is only as good as your entropy source, and I trust the random number generator on my CPU about as much as I trust the NSA. That said, I am super paranoid, so you know, take that statement with a grain of salt 
I could not find a way to restart uploading the errored file, so I just simply paid for another upload and finally, it went through! I changed nothing on my end - same machine, same internet connection, I just tried to upload the waves.mp4 for the fourth time and it succeeded.
is it normal for such a small file to have like 30+ ANT transfers?
hmmmm - each chunk is a max of 4 MB - you pay 3 nodes per chunk => 40MB => 10 chunks x 3 nodes == 30 payments (possibly + datamap chunk => 33 payments)
[but should be 1 multi-output transfer ā¦ so many recipients but one bundled payment ā¦ at least thatās how the ant client does it]
Repeated tries to upload a failed file have long resulted in repeated payments, but I thought that was fixed recently. Maybe it only applies to ant-cli - @chriso can you clarify? Thanks.
oooooh - right - didnāt think about that 
with the current network issues itās possible that retries hit hard+create additional TXs and it would probably be cheaper for users to wait for the storm on mainnet to settle (especially when trying to upload large files ā¦) ā¦
I believe this is fixed. When I was doing upload testing on alpha net with the colony_uploader, I had it upload some files multiple times and I didnāt incur any ANT or ETH gas costs when doing so. Iāll try again on main net when I get off work.
Maybe thereās a difference between a repeat upload after success and after a failed upload.
ah, good point. Iāll look at that as well.
Iāve spent the day fixing some UI related issues that have been bothering me and making enhancements from user feedback. I think these updates make it a lot more intuitive:
Iām working on fixing an occasional issue with scratchpads pulling in an old version from the network. The MaidSafe folks made a patch to the libs to enable me to walk through all scratchpad versions found and pick the right one myself. This will greatly improve reliability.
Another issue that came up is related to running the AppImage binaries on Arch linux. This is a Tauri bundler issue. Iām trying to see if there is something I can do to fix this. If anyone has encountered this when bundling their Tauri apps, let me know how you fixed this!
@Anselme is this the same issue weāve seen with Pointers? If it might be, can you provide the same support for Pointers that you have Scratchpads? Thereās a long time issue about this on github but Autonomi have not acknowledged that there is a problem with Pointers not updating.
@Zettawatt is there a back channel operating here? Iāve not seen anything about this myself. Can you share what you have been given or are you sworn to secrecy?
No secrecy, just happened to be on discord instead of the forum. Basically I had this error pop up when the network was flakey:
ERROR autonomi::client::data_types::scratchpad: Got multiple conflicting scratchpads for Key(b"\xea\xb9\x8eY\xdc\x8ew\x01\x0c\xf95\x96?\x07sb\x92A\x9b\x91\x03\xd7\xb1/K\xc2\xa6\xafR\xc5\xbdw") with the latest version, returning the first one
and the first scratchpad was corrupted. So I asked that when this error occurs, they return all of the scratchpads so I had the ability to grab the right one myself.
I donāt know if this is a similar thing to what youāre seeing with pointers.
Here is the copied response from @Anselme:
Hey @zettawatt, so with the current API scratchpad fork resolution is managed by "with the latest version, returning the first one" which is indeed not good for scratchpads. Although you could get all the scratchpads via a manual get_record call, that would be too low level and make it a pain for you to do. So Iāve fixed the issue with this PR here: feat: user side fork resolution for scratchpads by grumbach Ā· Pull Request #3104 Ā· maidsafe/autonomi Ā· GitHub Now forks should return an error: ScratchpadError::Fork(Vec<Scratchpad>) . As this will need to wait for the next release to be out there in the public, and I donāt want to keep you waiting, you could use the branch with the fix in the meantime (until the next release). You can replace your autonomi dependency with the following in the meantime:
[dependencies]
autonomi = { git = "https://github.com/grumbach/autonomi.git", branch = "user_side_scratch_fork_resolution" }
GitHub
feat: user side fork resolution for scratchpads by grumbach Ā· Pullā¦
Iām very interested to see if this also relates to Pointers which seems likely.
Iām on Discord but didnāt see that so thanks for sharing.
It was in the impossible futures channel, not sure if that one is globally visible or not.
Iāve seen pointers throw a similar error about conflicts and returning the first one. I think youāre right, probably a similar mechanism since these are both mutable types.
Yep, thatās called a secret backchannel 
Like the āalpha network will be available to everyoneā response from Rusty, thatās only true if people are told it exists and how to access it. Iāve seen nothing about that since so it remains exclusive.
As it turned out I donāt need it, but others might have.
I choose lack of competence over conspiracy, but the effect is the same on the project - potentially undermining the creation of useful apps for want of better comms. 
Weāll get there in the end but it could be made less difficult and much quicker.
Sorry about that, I didnāt realize this was not a normal channel that everyone could see or I would have posted it elsewhere. If it makes you feel better, there isnāt much excitement in there
I think the team is simply overwhelmed. Lots of moving parts and not enough people to keep eyes on everything.
On errors specifically, I asked if the MaidSafe devs could hold a call, or produce a document at a minimum, where they go through a lot of these errors that we see, explain what they mean, and how to properly triage them on the application side. I was told they are working on a document for this now, so hopefully weāll get that soon.
I donāt know about you, but Iām pretty much flying blind here on a lot of these errors. If I see the error once, I try to go figure out what to do with it, but since many are so transient, sometimes I may never see it again, so I donāt know if my error handling code will work or not. Or after an update, if the error even exists anymore. It would be awesome to have some kind of error injection system on the local network that we could tap into for testing.
It could relate to this: Separate owner address mutables by traktion Ā· Pull Request #3073 Ā· maidsafe/autonomi Ā· GitHub
The counter check requires the prior version to be fetched by the ant node, but if it canāt be retrieved due to an error, it returns None (which is the same as no existing pointer). The logic the assumes the pointer doesnāt exist and tries to persist it, which presumably would then silently fail or some such.
It struck me as dangerous either way. It looks like an error should be propagated instead. However, there hasnāt been a follow on conversation yet.
Pointer requests donāt fail, at least in this case. Instead they donāt update so you get back the earlier version. Itās a long term issue, so maybe different from the issue @zettawatt saw, idk.
I donāt see, not all developers getting access to the alpha network as explained by being overwhelmed. But it doesnāt matter why, the point is that it has become an exclusive resource when it was said to be open to everyone.
They can explain if they want, but what matters is to make I accessible if that was the intention. Or say, no it wasnāt meant to be that in t first place.
