Weird behavior using -r

[Peri0dic]

After I uploaded all of my exported matches yesterday -r was working as intended and blocking previous battle uploads. But today it has started re-uploading the only 5 turf war matches I played on day 1, while still skipping previously uploaded ranked battles.

[frozenpandaman]

stat.ink's /api/v3/s3s/uuid-list endpoint only returns the most recent 200 battles (of any type) so that's why they're trying to be uploaded again. However, I'm guessing you uploaded those battles to stat.ink over 24 hours ago, and thus it doesn't recognize their UUIDs as duplicate. Hina confirmed that this is intentional – another record will be created after 24 hours. In addition, the script itself doesn't have a way to stop these battles from getting uploaded if they occurred that long ago (200+ battles in the past).

Though something weird may be going on here – you're saying they're getting uploaded when you're using -r? Have you played less than 50 battles total?

[paul-sama]

I got the same issue, after run -r it uploaded my first turf war played at 9/9.
because i don't like Regular Battle, maybe less than 50 battles even include fes battles

[Peri0dic]

I have only played like 5 regular turf war battles and then I just started playing ranked only (like 450 games). I suppose I can avoid this issue by just waiting for -M mode to catch up before closing it so I don’t have to run -r.

[CafeAuLait-CC]

So this issue was introduced after the commit 68a6b99 (#9). It's pretty hard to deal with by s3s, unless stat.ink changes the /api/v3/s3s/uuid-list API and returns 50 battles of each type for example, instead of 200 battles of any type.

[frozenpandaman]

@fetus-hina let me know if you have any thoughts here, bringing this to your attention just in case

[frozenpandaman]

@Peri0dic That's a good point, when I add in the functionality (soon I hope) to check for remaining battles after you exit -M, it should work differently than -r – it specifically should check LatestBattleHistoriesQuery. That'll solve it in your use case (or, as you said, just wait a bit manually before exiting for the time being).

I guess you may still get this issue when running -r alone…

[fetus-hina]

stat.ink does not do such processing.
It simply retrieves the 200 most recent entries in order of registration.

https://github.com/fetus-hina/stat.ink/blob/e3abfda1324beb749e957970c8c1e348dacdf527/actions/api/v3/s3s/UuidListAction.php#L45-L52

Note:
This order is different from your list on stat.ink public web page, which is sorted by playing order,
because this is the order of registration.

[frozenpandaman]

This only happens if you play essentially only TW or ranked and not much of the other mode. For example:

1. Upload your recent results to stat.ink with -r: 50 Anarchy + 50 Turf War. /s3s/uuid-list returns all 100 of those
2. Play & upload 180 Anarchy & 20 TW battles. /s3s/uuid-list returns those 200 totally new results
3. Using -r now, SplatNet 3 returns the most recent 50 Anarchy (all 50 new) + 50 Turf War battles (20 new, 30 old)
4. The 30 TW battles are recognized as unuploaded – and, if they're older than 24 hours – get uploaded again

This could be fixed in two ways, as I see it:

• Change -r to only check the most recent 50 battles of any type (LatestBattleHistoriesQuery), and introduce a new command to check all up-to-150 ({RegularBattle,BankaraBattle,PrivateBattle}HistoriesQuery) for use on first-run only
• stat.ink could remove the 24-hour time restriction when checking for duplicates using UUID, and instead reject all dupes

[fetus-hina]

Stat.ink now (v2.156.0) deployed the feature.

• /api/v3/s3s/uuid-list returns more UUIDs (now returns up to 500 records).
• The 24-hour time restriction is removed.

[frozenpandaman]

Thank you Hina!! The 200->500 change will help reduce occurrence of this error for those using older versions of s3s as well.

[CafeAuLait-CC]

Maybe you could just maintain a cache of 3 ids. One most recent TW battle id that has already been uploaded to stat.ink, one most recent uploaded battle id for Anarchy battle and one most recent uploaded battle for private battle. (Perhaps save them into config.txt)

In this case, every time you fetch the {150} records from SplatNet3, just check wether the cached id exist in the SplatNet3 records. If yes, it means only the battles after the cached id are going to be uploaded. Otherwise, all records from SplatNet3 are fresh and need to be uploaded.

p.s. Maybe use the time stamp of each battle instead of battle ids since there may be duplicates as mentioned in previous issues (#29)?

[frozenpandaman]

@CafeAuLait-CC Having to save a ton more information locally on-disk is not ideal. Battle timestamp is also used to compute the UUID. But stat.ink has changed how it works so now this issue should be resolved.

[CafeAuLait-CC]

Cool. Thank you.