info.date is the upload time in UTC.
rounds[].start_time originates from the log file. It's basically the time next to the logfile event: " L 12/27/2020 - 20:38:19: World triggered "Round_Start" "
There's some other keywords as well but it's one of them. I'm pretty certain logs.tf assumes the logfile is in UTC therefor the time you see is also in UTC. I guess it could be a local-timezone as well if for some reason the server admin decides to make the logfiles non UTC.
This also means that the rounds[].start_time could be days before info.date as well btw.

I'm not 100% certain but 90% certain that if you were to update a log e.g on a per round basis it keeps the same logid.

I will look into the players[].heal tomorrow a bit more but I believe it should be the healing the person has issued e.g the amount of healing a medic has done.
If I take a look at the log you mentioned in which Kumis has 38634(heal) for some reason almost every shot he makes as a scout looks like this

L 12/27/2020 - 20:39:03: "Kumis<14><[U:1:169048576]><Red>" triggered "damage" against "Dummy<11><[U:1:389475398]><Blue>" (damage "3") (weapon "scattergun") (healing "82")

I don't know what happened there but that's most likely the root cause of why he has such a high healing stat.

Hope this helps a little bit!

If you shoot yourself in a tf2 match it doesn't get added to the log file. Therefor it won't be added towards damage taken or damage dealt.
If you look at the code zoob uploaded some time ago for is 1.0 version of the log parser (which isn't the version currently being used for sure) the only thing that increases damage dealt/taken is the event : ' triggered "damage" '. So if you were to configure a server to log the events when you shoot yourself as "(player 1) triggered "damage" against (player 1)". It would be taken into account.

I'm pretty sure that's just because you're requesting too many json files one after the other and at some point (to avoid inappropriate usage of the api) it doesn't except any more requests for a couple of seconds. Pretty much every api does that.
Usually in the header of the content you're requesting there's a "retry-after" which specifies how many (milliseconds I believe) you have to wait until you can make another request. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429)
If I remember correctly logs.tf doesn't use that header though... You'd need to check.
One simple fix for the issue would be to catch that specific error and halt the program for a second and then call the function with the same URL again.
There's a lot of issues with that approach but I'm not too versed with http requests in Java so sadly I can't help you anymore beyond that. There's probably more information on how to handle 429 responses in java somewhere on the internet.

Didn't they try to make medic more fun with introducing the speedbuff thing that we decided to remove for at least this season?

I think what 24 (#7) would be the most likely reason of how the account got compromised either that or they somehow got access to the current-login cookie for the steam web browser. Basically a cookie (can be) a really long "password" which you send to the server and the server looks it up, finds you and sends you a response of some sorts. That's how all "keep me logged in" things work in web browsers. (Tom Scott recently made a really good video partly talking about this).
While incognito mode doesn't, usually, start with any cookies stored and also doesn't /shouldn't keep any cookies saved and also cross-site-access to cookies and the likes should absolutely not be possible web browsers aren't perfect and JavaScript is scary. There have been numerous exploits over the years that could intern accomplish the above mentioned
That being said I can't really imagine a "random" tf2 item scammer to have the skill required for this but what do I know.
I feel like with an exploit potentially this powerful you could do a whole lot more than to just scam some unusuals...

Also sorry for some possible inaccuracies I am also not an expert on this just wanted to give some context on how this stuff works.

EDIT: By trying to keep things short and simple I braced over a lot of details especially on what cookies can do. I only talked about them in this specific use-case, as in them being used as an authentication token, since this is what would have mattered the most.
I also talked about some really weird exploit stuff since the person who has made this thread said that they didn't log into anything. So the only possible attack I could think about was some sort of cookie-theft unless Valve messed something up majorly.
Also while yes JavaScript isn't a bad language or necessarily evil since it allows most if not all websites to function how we expect them to, from a security stand-point it's still kinda "eh" and I still believe the web would be better of without it. But that's besides the point.

tldr; javascript bad

I don't want to be that annoying guy but I think you should be using logs.tf API for this. Most definitely if you want to continue working on this.
This way you can get the last 10000 logs from a player in a JSON format (which is the limit):
http://logs.tf/api/v1/log?player=<Steam64ID>&limit=10000
And this way you can get the information from each log:
http://logs.tf/api/v1/log/<logid>;
More on this here: logs.tf

I've been working on a project for a year now which uses that api and some other stuff to return the ticks of certain events that happen in game (e.g. killstreaks, airshots etc,) so one can easily record a frag movie or something of the sorts. It's pretty much finished I've just been too scared to release it ^^"

If you have any questions about this stuff I'd be glad to help!

This probably means that exactly the same logfile has already been uploaded to logs.tf
The number you see after the message "Log already exists" is the logid for that log.
If what I'm saying is correct it would mean that this: https://logs.tf/2738782 is the log you're trying to upload.
Also are you trying to upload it with the API or via the website?

If you want to rule out if it's the servers you're playing on you could just create a local server(e.g training against bots) and see if the problem persists.
The thing eek suggested might be related to the Windows Power Plan. If you plug a laptop into the wall it will usually change the power plan from balanced or energy saving into high performance mode.
You could try going into the control panel and make sure that your power plan is set to high performance (control panel -> Power Options)

The german version kinda sucks

http://puu.sh/Gu4vt.jpg

I'd assume mostly because people want demo to have this kind of upgrade/ want demo to be a stronger class.

Personally I think it should be banned in it's current state since it is technically a straight upgrade. But I would much rather just have a fix for it instead of it being outright banned.

If we do want this fixed shouldn't we also report this to Valve as a "bug" or something? I very much doubt that anyone from Valve would every read this random thread. And if we do report it we might at least get a fix this decade.

I have to agree with CaptainZidgel. I don't really notice any difference in smoothness. I feel like the only reasons why one would perceive one of the videos as being smoother than the other is that in the first video: A: Motion Blur is being used. B: It's a lot darker (and it some weird filter is applied) C: That the mouse movement is a little bit smoother.

As far as I know there's no way in tf2 to do things like: Issue command 1 and then issue command 2 except for on some servers. Therefore the only way to accomplish that would be to hit a key two times. First time switches to spy second time back to soldier. In tf2 console commands no matter how you put them all of them get executed "at the same time".
This might also not properly work if you only put the script into the soldier.cfg I'm not certain on that though.
You could make it so your soldier.cfg is something like this : bind "c" "join_class spy" and in the spy.cfg you have bind "c" "join_class soldier". But this is most definitely not as fast as to just do what ekh0 suggested.

Use whatever you think is the best
https://drive.google.com/open?id=1s2AYEwRNohe6rYjIWrQChuGwRWC2L5uK

https://www.donaldscreamices.co.uk/image/cache/catalog/smarties-800x800.png

The first one crashes your game because when the command scopedin is used it then triggers scopedout and that triggers scopedin again and that forms a loop and the game crashes. Some other stuff causes some problems as well though so I'd just create a toggle like JarateKing has so I'll just edit his script(just change xhUnscoped,xhScoped to the values you want like JarateKing has already mentioned):

alias xhUnscoped "cl_crosshair_file crosshair1" 
alias xhScoped "cl_crosshair_file crosshair2"
alias scopedToggle "scopedToggleOn"
alias scopedToggleOn "xhScoped; alias scopedToggle scopedToggleOff"
alias scopedToggleOff "xhUnscoped; alias scopedToggle scopedToggleOn"
alias +attackswitch "scopedToggle;+attack2"
alias -attackswitch "-attack2"

bind mouse1 "+attack; spec_next; scopedToggleOff";
bind mouse2 "+attackswitch";
bind space "+jump; spec_mode; scopedToggleOff";

Anyways the reason why it didn't work before is because if you bind +attack2 to a key and before that you call an alias it basically keeps zooming in and out forever and if you use it after +attack2 the alias behind it triggers twice. That's why he also made a +jumpup command which I didn't use because it doesn't really matter if your crosshair gets changed to the none scoped in version twice or not. If you still wanted to use it it'd look like this:

alias xhUnscoped "cl_crosshair_file crosshair1"
alias xhScoped "cl_crosshair_file crosshair2"
alias scopedToggle "scopedToggleOn"
alias scopedToggleOn "xhScoped; alias scopedToggle scopedToggleOff"
alias scopedToggleOff "xhUnscoped; alias scopedToggle scopedToggleOn"
alias +attackswitch "scopedToggle;+attack2"
alias -attackswitch "-attack2"
alias +jumpup "+jump; +moveup"
alias -jumpup "-jump; -moveup"

bind mouse1 "+attack; spec_next; scopedToggleOff";
bind mouse2 "+attackswitch";
bind space "+jumpup; spec_mode; scopedToggleOff";