`-c 0` opens 8 progress bars

[Anonymous3-a]

Not actually sure if this should be here or the cfc repo. Putting it here for now.

Actually, it opens the progress bars one after another. I'm guessing it's every read, and it can only fit 8 max? No idea what's going on here.

[sz3]

This is the right repo.

I'm not sure exactly what's going on, but here's a bit of context:

• The extra progress bars is a bug/artifact of having a mismatched fountain header. I believe there's a cutoff to limit concurrent "transfers" (which is what it's getting confused about) to 8 somewhere, which is why it stops there.

• Usually I've seen this when I'm experimenting with a new cimbar config and botch the params (ex: misaligned fountain sizes vs overall capacity)

• I'm not sure why it's happening with -c 0 on the sender.

Some other thoughts:

• a few of the settings for cimbar_send are only useful if you're also tweaking the decoder side. The color/ecc settings in particular are basically overrides for experimentation purposes. -c 3 in mode 4C corresponds to the original "8C" mode, but I've deprecated that (if you roll a custom CFC build you can do -c 3 with an 8-color mode B...)
  • that said, I think different color settings should work (at decreased speed) against a "mode B" decoder. So if you're doing cimbar_send -c 0 -m B we'd expect the CFC decoder in mode B to (maybe) make some progress with the symbols, while being confused about the lack of colors. In those circumstances triggering the progress bar glitch is a "bug", though maybe a minor one.
  • I'd expect the -c 0 and -c 1 settings to be useless with mode 4C
• besides all this, there's probably a nicer way to surface the fountain size mismatch situation than extra progress bars... 🙃 (the UI code in CFC displays stats from the "fountain_decoder_sink" class in this repo)

[Anonymous3-a]

Alright, thanks for the info. I'll stay away from the bug for now.