Update: The invalid IP address would have made for a nice explanation, but alas, it turns out to be not accurate. In fact, there was a silly log display bug that in some cases led to IP addresses being displayed in reverse order, i.e. if one's IP address were 18.104.22.168, the online log would have displayed it as 22.214.171.124. This was solely a display bug, the underlying true IP was accurately captured; it had no effect on any routing decisions, would not have resulted in traffic being blocked or packets dropped. Moreover, the bug solely affected the online log page, the downloadable CSVs always had the IP displayed correctly, The bug has since been fixed.
It remains the case that the IP address changed (within the same network range) between the two sessions, which were roughly 30 minutes apart. It's hard to say what, if anything, this indicates, with possibilites ranging from an expiring DHCP lease, loss of connectivity or connection reset. Normally, data that could not be uploaded because no connection to our servers can be established would remain on-device until such time as connectivity is restored. If a captive portal ( https://en.wikipedia.org/wiki/Captive_portal
) was involved and timed out the participant's network session, the network's DNS would have returned the portal's IP instead of our server's when data upload was attempted, though in that case the participant should have at least seen some SSL errors. Did the participant indicate anything like that? Finally, the player app keeps a client-side technical log, which is accessible by opening the player app, going to the "Tests" tab, and then clicking on "Log" in the upper right-hand corner. If the participant would be willing to provide that log file, it may shed some light on what went wrong during the 1st session.