Millisecond Forums

+x

 

dantassone9382 - 9/30/2021

Hello,

I recently launched a study where participants complete two sets of two tasks on Inquisit (so they complete four tasks total). They complete the first set of tasks before doing something in Qualtrics, and then they complete the same set of tasks after they are done in Qualtrics.

I ran six participants this week, and one participant is missing data for one of the four tasks that they completed. I have reviewed the participant log and the raw hit log, and I cannot determine what happened to their missing data. There are no relevant error messages. After reviewing similar questions on this forum, I asked the participant to open the "Data" tab in Inquisit and upload any files that have not been uploaded, but they denied seeing any data that needs to be uploaded.

I feel fairly confident that the participant completed the task because participants talk with a Research Assistant over Zoom throughout the study, and I think that this participant spent about as much time on the Inquisit tasks as the other participants.

I appreciate any ideas that you may have. Thank you!

I've looked at the log and the only thing that stands out is an IP address change between the two timepoints (not a minor one either, completely different networks). Moreover, the IP address for the first session comes from a reserved address space ( https://en.wikipedia.org/wiki/Reserved_IP_addresses; from the 240.0.0.0/4 reserved block ), and should not be in use by anyone, as that can cause all sorts of problems. So my guess is a connectivity or filtering issue -- illegal addresses may be filtered and blocked at various points along the network path. The logs show no further contact from the client after launch, there definitely were no data files received for the 1st session.

Adding: Checked and the 240.0.0.0/4 block is still on IANA's reserved list, i.e. it has not been reassigned, and is not globally reachable:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
It is a so-called "Martian address" ( https://whatis.techtarget.com/definition/Martian-address ).

+x

 

Dave - 9/30/2021

I've looked at the log and the only thing that stands out is an IP address change between the two timepoints (not a minor one either, completely different networks). Moreover, the IP address for the first session comes from a reserved address space ( https://en.wikipedia.org/wiki/Reserved_IP_addresses; from the 240.0.0.0/4 reserved block ), and should not be in use by anyone, as that can cause all sorts of problems. So my guess is a connectivity or filtering issue -- illegal addresses may be filtered and blocked at various points along the network path. The logs show no further contact from the client after launch, there definitely were no data files received for the 1st session.

Adding: Checked and the 240.0.0.0/4 block is still on IANA's reserved list, i.e. it has not been reassigned, and is not globally reachable:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
It is a so-called "Martian address" ( https://whatis.techtarget.com/definition/Martian-address ).

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 1.2.3.4, the online log would have displayed it as 4.3.2.1. 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.

+x

 

Dave - 10/1/2021

+x

 

Dave - 9/30/2021

I've looked at the log and the only thing that stands out is an IP address change between the two timepoints (not a minor one either, completely different networks). Moreover, the IP address for the first session comes from a reserved address space ( https://en.wikipedia.org/wiki/Reserved_IP_addresses; from the 240.0.0.0/4 reserved block ), and should not be in use by anyone, as that can cause all sorts of problems. So my guess is a connectivity or filtering issue -- illegal addresses may be filtered and blocked at various points along the network path. The logs show no further contact from the client after launch, there definitely were no data files received for the 1st session.

Adding: Checked and the 240.0.0.0/4 block is still on IANA's reserved list, i.e. it has not been reassigned, and is not globally reachable:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
It is a so-called "Martian address" ( https://whatis.techtarget.com/definition/Martian-address ).

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 1.2.3.4, the online log would have displayed it as 4.3.2.1. 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.

Hi Dave,

Thanks so much for your detailed explanation and follow-up. The participant did not report seeing any SSL errors. I will ask them to pass along the log file, and I will share it with you if they do so.

On Saturday, I encountered a similar issue: a participant completed the two sets of two tasks, and I am missing one of the data files for one of the tasks. If you can see it on your end, I am missing the data file for subjectID 115- the Symmetry Span task. This time, I did receive an error message:

Date/Time     Type     Script Element     Message     Error Code
10/02/2021 - 17:47:13     Error     strooptask_withvoicerecognition.iqx.picture.SymmetryProblem     https://scripts.millisecond.eu/lf74/pod/pod_automatedsymmspan.iqx.picture.SymmetryProblem:Unable to load the picture 'https://scripts.millisecond.eu/lf74/pod/symm19.jpg'. Network Error: Error transferring: 500 -     64

Does this error explain me not receiving any data for this participant's session?

I am also not sure why the message references "strooptask_withvoicerecognition.iqx". This task was included in my experiment months ago, but I have since replaced it. To my knowledge, there is no reference to this Inquisit task in any of my materials that are currently uploaded.

Thank you again for your help with this.

+x

 

dantassone9382 - 10/4/2021

+x

 

Dave - 10/1/2021

+x

 

Dave - 9/30/2021

I've looked at the log and the only thing that stands out is an IP address change between the two timepoints (not a minor one either, completely different networks). Moreover, the IP address for the first session comes from a reserved address space ( https://en.wikipedia.org/wiki/Reserved_IP_addresses; from the 240.0.0.0/4 reserved block ), and should not be in use by anyone, as that can cause all sorts of problems. So my guess is a connectivity or filtering issue -- illegal addresses may be filtered and blocked at various points along the network path. The logs show no further contact from the client after launch, there definitely were no data files received for the 1st session.

Adding: Checked and the 240.0.0.0/4 block is still on IANA's reserved list, i.e. it has not been reassigned, and is not globally reachable:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
It is a so-called "Martian address" ( https://whatis.techtarget.com/definition/Martian-address ).

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 1.2.3.4, the online log would have displayed it as 4.3.2.1. 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.

Hi Dave,

Thanks so much for your detailed explanation and follow-up. The participant did not report seeing any SSL errors. I will ask them to pass along the log file, and I will share it with you if they do so.

On Saturday, I encountered a similar issue: a participant completed the two sets of two tasks, and I am missing one of the data files for one of the tasks. If you can see it on your end, I am missing the data file for subjectID 115- the Symmetry Span task. This time, I did receive an error message:

Date/Time     Type     Script Element     Message     Error Code
10/02/2021 - 17:47:13     Error     strooptask_withvoicerecognition.iqx.picture.SymmetryProblem     https://scripts.millisecond.eu/lf74/pod/pod_automatedsymmspan.iqx.picture.SymmetryProblem:Unable to load the picture 'https://scripts.millisecond.eu/lf74/pod/symm19.jpg'. Network Error: Error transferring: 500 -     64

Does this error explain me not receiving any data for this participant's session?

I am also not sure why the message references "strooptask_withvoicerecognition.iqx". This task was included in my experiment months ago, but I have since replaced it. To my knowledge, there is no reference to this Inquisit task in any of my materials that are currently uploaded.

Thank you again for your help with this.

> Does this error explain me not receiving any data for this participant's session?

Yes. For whatever reason (it's an unspecific network error), one of the images in the SymmSpan failed to load, so the session terminated with that error.

> I am also not sure why the message references "strooptask_withvoicerecognition.iqx". This task was included in my experiment months ago.

This was the script that was originally the start script when the experiment and log were created. Its name is kept as an internal identifier, regardless of whether that script is still part of the procedure or not. It has no effect on anything beyond that.