Battle count is not working correctly

[Tiryoh]

All battle results are numbered 1 when I run the script with option -r.
Perhaps something wrong with splatnet2statink or stat.ink?

I can check the battle results on stat.ink correctly, so there are no problem for uploading.
Only the number of the battles seems to be not correct.

$ ./splatnet2statink.py -M 1200 -r
splatnet2statink v0.0.53
Checking if there are previously-unuploaded battles...
Previously-unuploaded battles detected. Uploading now...
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136566
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136567
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136568
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136570
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136571
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136572
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136573
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136574
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136575
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136576
Battle #1 uploaded to https://stat.ink/@tiryoh/spl2/136577
Waiting for new battles... (checking every 20 minutes)

[mkody]

Well, it's normal since it's only uploading one battle at every checks (I guess? Correct me if I'm wrong).
But it's supposed to not display that counter in monitoring mode.

splatnet2statink/splatnet2statink.py

Lines 817 to 820 in d19c158

	if not ismonitor:
	print "Battle #" + str(i+1) + " uploaded to " + post_battle.headers.get('location') # display url
	else: # monitoring mode
	print "Battle uploaded to " + post_battle.headers.get('location')

[Tiryoh]

@mkody,

Well, it's normal since it's only uploading one battle at every checks (I guess? Correct me if I 'm wrong).

Those 11 battles are recent battles, not real time battles detected in monitoring mode.
(I hadn't run the script for a while, so there were a few un-uploaded battles.)
I ran the script with -r option, so I guess this #19 (comment) was written by this code.

splatnet2statink/splatnet2statink.py

Lines 255 to 263 in d19c158

	# if r_flag, check if there are any battles in splatnet that aren't on stat.ink
	if r_flag:
	print "Checking if there are previously-unuploaded battles..."
	statink_battles = [] # 50 recent battles on stat.ink
	printed = False
	url = 'https://stat.ink/api/v2/user-battle?only=splatnet_number&count=50'
	auth = {'Authorization': 'Bearer ' + API_KEY}
	resp = requests.get(url, headers=auth)
	statink_battles = json.loads(resp.text)

The battle results seems to be uploaded to stat.ink correctly, this is not a serious problem. I just wanted to ask.
As far as I remember, if several un-uploaded battles are detected, the log was written like this:

Battle # 1 uploaded to URL.
Battle # 2 uploaded to URL.
Battle # 3 uploaded to URL.

[frozenpandaman]

Thanks for bringing this up @Tiryoh.

The reason why they're all #1 is because of

splatnet2statink/splatnet2statink.py

Line 273 in d19c158

post_battle(0, [result], s_flag, t_flag, secs, debug)

We should be able to fix this shortly. :)

And you are correct in your response to @mkody's comment – since it's retroactively uploading the battles (not real-time as they come in), i.e. not actually "monitoring mode," we still want to print the battle numbers here.

[Tiryoh]

@frozenpandaman,

Thank you for your explanation.
I think I understand the situation.
Is there anything I can help you with?

[frozenpandaman]

I'm heading to bed right now so I think I'm good (but thank you!) – unless @clovervidia has anything. It shouldn't be too hard of a fix. :)

[clovervidia]

I have a few ideas on fixing this, so I think we have it covered. It's all about the battle numbers and when they should and shouldn't be shown.

[Tiryoh]

I see, I'm looking forward to the update!

[clovervidia]

I changed the way previously unuploaded battles are handled now, and it should print the same as a battle uploaded through monitor mode, just without the results and time. Let me know if there's any further problems.

[frozenpandaman]

Lol I guess that works. Not technically monitoring mode (as discussed above) per my working definition of it but it does fix the issue and makes the print statements cleaner there. 👍

Made a non-issue in b5bcd98. Closing for now.