Unable to read activity file

[marcelvb]

I just got ttwatch (version e9a0a07) to download data from my TomTom Runner (version 1.8.46). The watch memory was full and as I'm a Linux user, this is the (only) way to go.

What I get now is this:

$ sudo ttwatch --get-activities 
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file
Unable to read activity file

Any ideas?

[ryanbinns]

Are you comfortable running gdb? If so, can you put a breakpoint at the ttwatch_read_whole_file function and tell me where it returns? There are four lines it could return from, and which one will tell us what the error is.

[marcelvb]

Are you comfortable running |gdb|? If so, can you put a breakpoint at the |ttwatch_read_whole_file| function and tell me where it returns? There are four lines it could return from, and which one will tell us what the error is.

I have gdb but I have no idea how to use it. If you can give me some brief instructions, I might manage to do it.

[ryanbinns]

Ok. I'll have a go.

1. Start gdb by running gdb ttwatch.
2. Once gdb starts, set the breakpoint using break ttwatch_read_whole_file and press enter (every gdb command is run by pressing enter, just like the shell).
3. Start the program running using run --get_activities
4. Program execution will stop at the beginning of the function. When it stops, it should show the line number, and the line of code that it is stopped at.
5. Step through the code by repeatedly typing n (short for next) until the line number that is printed out says 667 (the last line of the function). The previous line number will be the one we're interested in. The second-last line number should be either 637, 638, 665 or 666.
6. Once you've found where the function is exiting, you can quit (using the quit command). It will ask you for confirmation since the program is still running, but that's fine. You can quit anyway.

Hopefully that all makes sense...

[ryanbinns]

One other thing. When you get to line 667, type print result to get the error code that is going to be returned from the function. That will be useful too.

[marcelvb]

Good instructions! It works, but debugging the while loop is kinda tedious ;-) Seems like there are many files and most go fine. But just when I wanted to call it a day I think I got to a file that failed:

Thread 1 "ttwatch" hit Breakpoint 1, ttwatch_read_whole_file (watch=0x67e490, id=9502747, data=0x7fffffffdda0, length=0x0) at /home/marcel/code/tomtomrunner/ttwatch/src/libttwatch.cpp:631
631 {
(gdb) 
635     int result = TTWATCH_NoData;
(gdb) 
637     RETURN_ERROR(ttwatch_open_file(watch, id, true, &file));
(gdb) 
667 }
(gdb) print result
$1 = 15
(gdb) 

Does that help?

[ryanbinns]

Glad it worked, but yeah, while loops are tedious. I tend to set an extra breakpoint just below the loop and use c (for continue) to run to the end of the loop. I wanted to keep it simple though.

It looks there is a fault with opening the file on the watch. Can you run ttwatch --get-activities --packets to enable the debugging information and attach the output? It will be a lot of data, but should be helpful.

[marcelvb]

Here's the output with --packets: ttwatch.log.tar.gz

[ryanbinns]

It looks like a timeout. It seems the watch is taking longer than expected to delete each file. There's a 10 second timeout already, but it might take longer for large files or when there are lots of them. I have modified the packet dump to include timestamps so we can verify this. Are you able to download and build, then try with --packets again?

According to that log, one activity file was downloaded and then deleted, but the delete took too long and timed out, so the program tried to start the processing the next file. The watch wasn't ready yet though, so it timed out with that command too (although it did eventually complete the command successfully). Every command after that failed because the watch and program were out of sync.

[marcelvb]

That sounds like a plausible theory. I do see a pause and I think I see it in the log too. Have a look. ttwatch2.log.tar.gz

[ryanbinns]

Yep, the watch took 14 seconds to delete the file, but the timeout was only 10s, so it all went pear-shaped. I've changed the timeout to 20s, which should solve the problem. Have a go and see.

[marcelvb]

Looks like it is working! Just one more thing: the watch' storage seems empty, but it still shows the last 10 activities. Is that as designed?

[ryanbinns]

Excellent! Yes, the watch retains a summary of the last few activities to show history you can compare against and also to support the race function. It's only a summary though, roughly 30 bytes each from memory.