to not increment when call bar(0)

[luewh]

I have to check the progress each periode of time then update the bar with pregression difference, but this value could be 0, so it updated 1 while it doesn't need.
I can add a condition to check if it is 0 but it would be logical to not increment when call bar(0).

[rsalmei]

Yes, it makes sense. Also, it would be on par with the manual mode bar, which does accept 0. (float) as input.
I'll do it on the next release.

[chet-manley]

I have a similar request, but using a negative integer instead of 0. Manual mode does not fit my needs, because I know the total, but I see you use run.count += max(1, int(count)) when updating using bar(int) (which is what causes OP's issue).

My use case is simple. I'm downloading hundreds of thousands/millions of logs from OpenSearch, 10k at a time, and I know the total I will be receiving. Occasionally, a request fails, and I need to re-download some number of logs. I need to set the progress back to the last known good state and re-process the logs during redownload. If bar(-int) were accepted, this would be an easy task, but as far as I can tell, there is no way to reverse the progress without manual mode, where I would lose automatic percentage calculation, ETA, etc.

[rsalmei]

Humm, shouldn't you wait to forward the progress until you've successfully received the logs? It would work better because the user should see what is actually accomplished at each given moment.
Anyway, with manual mode you can do this since you send the absolute percentage each time. You can make abrupt jumps, go backward, etc.

[chet-manley]

For a bit more context, the logs are downloaded in 24hr batches. So let's say you have a single batch of ~373k logs out of ~1.7m total, and for each 10k that is processed (transformed to JSON and written to file), the progress moves forward 10k. 220k logs into the operation, a request fails, so the file is unlinked and the batch restarts from the beginning. Or perhaps the batch completes, but received too few logs due to a concurrent re-index that started during the operation. The progress bar now needs to be reduced to the count after the previous batch to properly indicate the current state of the operation, and I would like to keep the automatic percentage calculation, ETA, etc afforded by not using manual mode.

I originally tried to use two progress bars, one for the aggregate total, updated when each batch completed, and one for each batch total, but realized two bars cannot be run at the same time. Perhaps each bar could run in its own thread with its own state? I haven't had time to look through the code thoroughly to see if this is feasible or not.

[rsalmei]

Yep, I see. Thanks for the thorough explanation.
I reckon I could indeed make the two modes operate with similar flexibility, i.e. since manual mode can go backward (by receiving a smaller absolute percentage), the auto mode could also go (but by receiving a negative relative count).
I'll make it happen 👍