Only if the downlink had some application payload, like you showed earlier.
The downlinks shown in your screenshot of TTN Console’s gateway Traffic have a total length for the full LoRaWAN packet of 22 bytes. If that would have the MAC commands in FOpts, then I’d expect 12 bytes for the LoRaWAN overhead (FPort is not needed when there’s no FRMPayload) and 2 × 5 bytes for the 0340020071 033500FF01 LinkADRReq MAC commands that you saw earlier. So, a total packet size of 22 bytes for the downlink indeed seems to indicate two LinkADRReq’s like you saw earlier, without any application payload. Those 22 bytes could also be an application payload of 9 bytes, without any LinkADRReq. But in that case, LMIC.dataLen should be 9.
So, it seems TTN has created its own downlink, just for ADR. Normally, it would only do that if the device has set its ADRACKReq bit (after 64 uplinks without receiving a downlink), in which case TTN must send a LinkADRReq within the next 32 uplinks. In this case, with the low uplink counter, apparently TTN is repeating the ADR downlink as it knows it’s still awaiting the LinkADRAns from the device.
Without any application payload
LMIC.dataLen will be zero indeed. To possibly see that log, just schedule a new downlink with some (dummy) payload (using “replace” to be sure), allowing TTN to piggyback on that. Also, please check if there is any LinkADRAns in the uplinks. I guess you won’t see that log, and won’t see that LinkADRAns as the device has not received the downlink.
Aside: just for the sake of completeness: LMIC may also reject downlinks, if the downlink counter is not higher than the last value it knows. But seeing that your uplink counters started at zero again, I assume you restarted the device (and have the frame counter security disabled?), so LMIC will have its last known downlink counter reset to zero too. As a result it would accept the high downlink counter of 344 just fine. At some point using ABP is going to bite you, for all these details that can be out of sync. However, OTAA needs downlinks too, so I’d focus on the downlinks now.
Did you also set
LMIC_ENABLE_arbitrary_clock_error to allow for values larger than 0.4 / 100? And did you try with, say, 20% or even 100%, just to go wild?
Just to be sure: that’s the logs on the gateway, right? The screenshot of TTN Console only tells you if TTN has delegated it to the gateway. A gateway may reject it if it arrives at the gateway too late to be transmitted.
Aside: please don’t post text (like text from the online packet decoder results, and code) as images. See also How do I format my forum post? [HowTo]