There may be an error in data transmission

[wershner]

I tried to find that I transferred a 6M file, but there may be a phenomenon that the data saved after the completion of the scan progress bar is 0K or 16/32K, and no error was reported during the scanning process, but it is still considered to be an effective transmission and cannot be used stably.

[sz3]

Were you able to save the file from the initial decode? Or did something else happen?

I'm not 100% sure I understand the scenario you're describing, but I can say that successive attempts (after initial decode) to on the same "file" will be treated as no-ops. That is, since the file is marked as done, progress is automatically ignored (the progress bar still updates though...). Closing+restarting the app will reset things into a clean state.

[RunpuWei]

I meet the same problem too.

[sz3]

Some questions:

1. does the specific file fail every time, or does it seem random?
2. do other files fail to transfer, or is it just one specific file?

[RunpuWei]

It looks like it's random, at least I haven't found a pattern yet, and it works for all the files, which are 15MB in size

[RunpuWei]

Although I did not find the exact error, I did not transfer 0MB files after the following operations:

1. Encode using cimbar_js.html instead of cimbar.asmjs or cimbar.wasm;

2. Open the Android app first and then start scanning, rather than open the Android app and start scanning at the same time;

3. Turn the brightness of the computer running the ’cimbar_js.html‘ to maximum, rather than keeping the display at a level that is comfortable for the human eye;

4. Use 4C mode encoding instead of B mode;

5. After saving the file, wait a few seconds before exiting the Android app;

6. Do not move your computer or mobile phone while scanning

[sz3]

3. Turn the brightness of the computer running the ’cimbar_js.html‘ to maximum, rather than keeping the display at a level that is comfortable for the human eye;

I'd recommend against this, just because you might hurt your eyes. Software is much easier to fix than eyes...

But I appreciate the troubleshooting! I'm not sure if any of those stand out as the most likely culprit -- (1) shouldn't make any difference in theory, and (3) and (6) mostly will effect the speed of the transfer. (4) does decrease the fountain chunk size, but not to an extent that I'd expect anything to break. Maybe it's incidental though -- perhaps a file will fail with mode 4C, but succeed with B, or vice versa?

(2) probably isn't anything, but (5) is interesting.

I'd say I suspect either something with the app saving code, or an interaction with the fountain codes (reassembling the file). I'll see what I can discover.

[sz3]

Ok, so I've been beating on the fountain code reassembly logic and haven't been able to reproduce any issue there. Which is good, but does point the finger at the way the final file save works.

That is, the failure might be as simple as: decode completes in the temp directory, but the final (local) copy step fails. A very simple change would be to add some indication to the UI as to when the copy step completes. (that way at least we can tell -- by omission -- if something is going wrong before then when this happens)

(5) above might be a relevant piece of advice, if the failure trigger is "quit in the middle of the copy step"

[RunpuWei]

Just now I encountered the 0MB BUG again, but this time I seem to have located the problem, if you switch encoding mode after selecting the file, the file will become 0MB at last.

[sz3]

Just now I encountered the 0MB BUG again, but this time I seem to have located the problem, if you switch encoding mode after selecting the file, the file will become 0MB at last.

I haven't been able to reproduce this via switching encoding mode. 🤔

I'm still suspicious of a "heisenbug" in the app-side java save code. I'm hoping to get a new CFC patch release out soon with some minor tweaks, we can see if it helps.