Progress bar (tqdm) issue in kek_lr when number of epochs exceed 1 (Jupyter notebook)

[roma-goodok]

Hi,
If the value of parameter n_steps (in kek_lr) is passed in such a way that the number of epochs exceeds 1
progress bar has starting to glitch and make new extra lines
(for example, n_steps = 1400 while number of batches in the epoch is 717 - see below)

>>> keker.kek_lr(final_lr=0.1, logdir="logdir_lr", n_steps=1400)

```Epoch 1/2: 100% 717/717 [03:17<00:00,  3.64it/s, loss=0.1435]
Epoch 2/2:   0% 0/717 [00:00<?, ?it/s]
Epoch 2/2:   0% 0/717 [00:00<?, ?it/s, loss=0.2583]
Epoch 2/2:   0% **1/**717 [00:00<09:51,  1.21it/s, loss=0.2583]
Epoch 2/2:   0% **1**/717 [00:01<09:51,  1.21it/s, loss=0.2422]
Epoch 2/2:   0% 2/717 [00:01<07:54,  1.51it/s, loss=0.2422]
Epoch 2/2:   0% 2/717 [00:01<07:54,  1.51it/s, loss=0.2315]
Epoch 2/2:   0% 3/717 [00:01<06:31,  1.82it/s, loss=0.2315]
Epoch 2/2:   0% 3/717 [00:01<06:31,  1.82it/s, loss=0.2271]

versions:
kekas 0.1.17
tqdm 4.30.0
jupyter-client 5.2.4

P.S pure python script output looks good:

Warning: unknown JFIF revision number 0.00
Epoch 1/2:  12% 83/717 [00:22<02:46,  3.81it/s, loss=0.7120]Corrupt JPEG data: 399 extraneous bytes before marker 0xd9
Epoch 1/2:  17% 121/717 [00:32<02:36,  3.80it/s, loss=0.6896]Corrupt JPEG data: 128 extraneous bytes before marker 0xd9
Epoch 1/2:  17% 122/717 [00:32<02:36,  3.80it/s, loss=0.6943]Corrupt JPEG data: 226 extraneous bytes before marker 0xd9
Epoch 1/2:  20% 146/717 [00:38<02:29,  3.81it/s, loss=0.6542]Corrupt JPEG data: 254 extraneous bytes before marker 0xd9
Epoch 1/2:  29% 209/717 [00:55<02:13,  3.81it/s, loss=0.5616]Corrupt JPEG data: 239 extraneous bytes before marker 0xd9
Epoch 1/2:  58% 415/717 [01:49<01:19,  3.79it/s, loss=0.3014]Warning: unknown JFIF revision number 0.00
Epoch 1/2:  59% 422/717 [01:51<01:17,  3.79it/s, loss=0.2748]Corrupt JPEG data: 162 extraneous bytes before marker 0xd9
Epoch 1/2:  60% 429/717 [01:53<01:16,  3.79it/s, loss=0.2928]Corrupt JPEG data: 65 extraneous bytes before marker 0xd9
Epoch 1/2:  65% 469/717 [02:04<01:05,  3.78it/s, loss=0.2795]Corrupt JPEG data: 99 extraneous bytes before marker 0xd9
Epoch 1/2:  68% 491/717 [02:09<00:59,  3.78it/s, loss=0.2552]Corrupt JPEG data: 1403 extraneous bytes before marker 0xd9
Epoch 1/2:  72% 514/717 [02:15<00:53,  3.78it/s, loss=0.2325]Corrupt JPEG data: 2230 extraneous bytes before marker 0xd9
Epoch 1/2:  84% 604/717 [02:39<00:29,  3.78it/s, loss=0.2118]Corrupt JPEG data: 1153 extraneous bytes before marker 0xd9
Epoch 1/2: 100% 717/717 [03:09<00:00,  3.79it/s, loss=0.175Corrupt JPEG data: 399 extraneous bytes before marker 0xd9
Epoch 2/2:   0% 3/717 [00:01<06:18,  1.88it/s, loss=0.0926] Corrupt JPEG data: 128 extraneous bytes before marker 0xd9
Epoch 2/2:   6% 46/717 [00:12<02:57,  3.79it/s, loss=0.1687]Corrupt JPEG data: 239 extraneous bytes before marker 0xd9
Epoch 2/2:  12% 87/717 [00:23<02:46,  3.78it/s, loss=0.1583] Corrupt JPEG data: 1403 extraneous bytes before marker 0xd9
Epoch 2/2:  36% 260/717 [01:09<02:00,  3.78it/s, loss=0.2722]Corrupt JPEG data: 2230 extraneous bytes before marker 0xd9
Epoch 2/2:  53% 379/717 [01:40<01:29,  3.77it/s, loss=1.4624]Corrupt JPEG data: 1153 extraneous bytes before marker 0xd9

[belskikh]

thanks, I will fix it in the next release