Counts from batch 59:

+------+----+------+
| kind | k  | coun |
+------+----+------+
| spt  |  9 | 2077 |
| spt  | 11 |   19 |
| spt  | 14 | 1046 |
| spt  | 16 |   91 |
| spt  | 18 |    7 |
| tpt  |  6 |  366 |
| tpt  |  7 |   22 |
| stpt | 10 |   96 |
| stpt | 12 |    2 |
+------+----+------+

There were a lot of STPT(8) (4-pairs), so much to even count. I do not think we need to save them due to how common they are.
SPT(9) and (14) are also common, and we could drop them, but I will leave that be until it becomes a problem.

Batch 60: 1000000000000 .. 1573000000000000 -1
Count: 800
Scan beginning with new App.

---

# Copyright Tomas Brada, ask on forum about reuse or citation.
# where k = 17
589492143270716899: 0 24 54 114 120 192 204 210 222 234 240 252 324 330 390 420 444
# last = 15465280 # count = 1

# Copyright Tomas Brada, ask on forum about reuse or citation.
# where k = 24
528050771271601307: 0 14 20 86 92 114 140 144 174 182 186 204 212 230 234 242 272 276 302 324 330 396 402 416
587950582712698157: 0 2 24 36 42 66 96 110 120 122 176 194 222 240 294 296 306 320 350 374 380 392 414 416
# last = 15463727 # count = 2

Fine!

More details here
https://boinc.progger.info/odlk/forum_thread.php?id=49&postid=5201#5201

Counts from Batch 60:

+------+----+---------+
| kind | k  | coun    |
+------+----+---------+
| spt  |  9 | 1404293 |
| spt  | 11 |   15194 |
| spt  | 13 |     167 |
| spt  | 14 |  273655 |
| spt  | 16 |   15383 |
| spt  | 18 |     907 |
| spt  | 20 |      43 |
| spt  | 22 |       1 |
| tpt  |  6 |  109349 |
| tpt  |  7 |    3863 |
| tpt  |  8 |     133 |
| tpt  |  9 |       4 |
| stpt | 10 |   18250 |
| stpt | 12 |     961 |
+------+----+---------+

There is a lot ofSPT(9). I will disable them for the next batch.

Batch 61: 1573000000000000 .. 5503000000000000 -1
Count: 2000
Disable SPT(9). Continue bottom with new App.

---

I tried to see the results on the link
https://boinc.tbrada.eu/spt_list.php?k=14

A message was issued

An error occurred.
Sorry, the page you are looking for is currently unavailable.
Please try again later.
If you are the system administrator of this resource then you should check the error log for details.
Faithfully yours, nginx.

I tried to see the results on the link
https://boinc.tbrada.eu/spt_list.php?k=14
An error message was issued

This is because there are a lot of records and the system was bussy with backups at the noment. You can try again now.
I need to look into it and make it faster.
You can, later, use the &i= parameter to only see records since the "last" entry.

Link
https://boinc.tbrada.eu/spt_list.php?k=14&i=100000
downloaded 297559 tuples.

Maybe you need to divide large result files into blocks, for example, 100,000 records in one block (?)

I have 297559 14-tuples in the project database, starting from here

8021749: 0 4 10 22 40 42 52 72 82 84 102 114 120 124
20065943: 0 18 20 44 60 66 80 84 98 104 120 144 146 164
62550557: 0 6 14 20 24 26 32 54 60 62 66 72 80 86
102979507: 0 10 12 24 36 46 54 112 120 130 142 154 156 166
110608391: 0 6 32 48 50 60 78 80 98 108 110 126 152 158
136450033: 0 16 30 40 46 48 96 118 166 168 174 184 198 214
162607649: 0 12 14 24 42 50 72 80 102 110 128 138 140 152
353656453: 0 16 24 30 36 64 90 94 120 148 154 160 168 184
. . . . . . 

I found here two solutions made up of cousins

888895528231807: 0 4 6 10 42 46 66 70 90 94 126 130 132 136
1346390969722159: 0 4 30 34 144 148 204 208 264 268 378 382 408 412

Are these the first two solutions from the start of primes??

Are these the first two solutions from the start of primes??

Yes.
But there is something I need to clarify about truncated tuples <16.
Adding:
SPT are duplicated in the database as k2=k-2 for ease of browsing. Like this #3880. Because the project originally searched for SPT >= 16, the duplication only goes down to 16. So while that is the first cousin 14-tuple, there might be 16-tuples.

I unfolded both tuples

[888895528231807, 888895528231811, 888895528231813, 888895528231817, 888895528231849, 888895528231853, 888895528231873, 888895528231877, 888895528231897, 888895528231901, 888895528231933, 888895528231937, 888895528231939, 888895528231943]

[1346390969722159, 1346390969722163, 1346390969722189, 1346390969722193, 1346390969722303, 1346390969722307, 1346390969722363, 1346390969722367, 1346390969722423, 1346390969722427, 1346390969722537, 1346390969722541, 1346390969722567, 1346390969722571]

These tuples are not contained in symmetric 16-tuples.
The question is only about the first elements of tuples: 888895528231807 and 1346390969722159.

Next I found the following symmetric 14-tuples of cousins

1939807184636677: 0 4 6 10 42 46 66 70 90 94 126 130 132 136

What can you say about the interval (1346390969722159, 1939807184636677)?
Is this interval already verified?

Counts from Batch 61:

+------+----+--------+
| kind | k  | coun   |
+------+----+--------+
| spt  | 11 |  30362 |
| spt  | 13 |    303 |
| spt  | 14 | 468568 |
| spt  | 15 |      4 |
| spt  | 16 |  24996 |
| spt  | 18 |   1281 |
| spt  | 20 |     52 |
| spt  | 22 |      2 |
| tpt  |  6 | 189448 |
| tpt  |  7 |   6292 |
| tpt  |  8 |    234 |
| tpt  |  9 |      6 |
| tpt  | 10 |      1 |
| stpt | 10 |  29447 |
| stpt | 12 |   1472 |
| stpt | 14 |      3 |
| stpt | 16 |      1 |
+------+----+--------+

There is a lot of SPT(14), might have to disable that as well. But Natalia is looking through the 14-tuples for cousins.
Good news is that we found the first TPT(10) and the first STPT(16) in the project.

What can you say about the interval (1346390969722159, 1939807184636677)? Is this interval already verified?

When you posted this question, It was not. But now all primes up to 5503000000000000 were scanned. Yes. I also checked the db for any failed workunits.

Edit: so I do not forget... extend the deadline

https://boinc.tbrada.eu/spt_list_stpt.php?k=14

# Copyright Tomas Brada, ask on forum about reuse or citation.
# where k = 14
# where kind = stpt
1855418882807417: 0 2 12 14 30 32 72 74 114 116 132 134 144 146
2485390773085247: 0 2 24 26 30 32 42 44 54 56 60 62 84 86
4038284355308309: 0 2 42 44 78 80 120 122 162 164 198 200 240 242
578327198578715939: 0 2 12 14 78 80 150 152 222 224 288 290 300 302
581617276342047269: 0 2 18 20 42 44 60 62 78 80 102 104 120 122
582046460920961717: 0 2 30 32 90 92 102 104 114 116 174 176 204 206
587122058346673007: 0 2 12 14 54 56 72 74 90 92 132 134 144 146
# last = 19491807 # count = 7

https://boinc.tbrada.eu/spt_list_stpt.php?k=16

# Copyright Tomas Brada, ask on forum about reuse or citation.
# where k = 16
# where kind = stpt
2640138520272677: 0 2 12 14 30 32 54 56 90 92 114 116 132 134 144 146
# last = 18801086 # count = 1

Fine!

There is a lot of SPT(14), might have to disable that as well. But Natalia is looking through the 14-tuples for cousins.

I have a problem loading 14-tuples results :(

Tomáš Brada
please see the message
https://boinc.progger.info/odlk/forum_thread.php?id=49&postid=5216#5216

Batch 62: 5503000000000000 .. 21223000000000000 -1
Count: 8000
Bump deadline to 3 days. Continue bottom with new App.

---

Batch 63: 1856513000000000 .. 1865333000000000 -1
Count: 441
Test fix of get_twin_seq_len. Even twin tuples only.

---

Batch 64: 5 .. 21223965000000005 -1
Count: 10801
Recalculate the affected interval with two fixes. Even twin tuples and twin_k6_gaps only.

---

https://boinc.tbrada.eu/spt_list_stpt.php?k=14

# Copyright Tomas Brada, ask on forum about reuse or citation.
# where k = 14
# where kind = stpt
1855418882807417: 0 2 12 14 30 32 72 74 114 116 132 134 144 146
2485390773085247: 0 2 24 26 30 32 42 44 54 56 60 62 84 86
4038284355308309: 0 2 42 44 78 80 120 122 162 164 198 200 240 242
20149877129714999: 0 2 18 20 42 44 60 62 78 80 102 104 120 122
578327198578715939: 0 2 12 14 78 80 150 152 222 224 288 290 300 302
581617276342047269: 0 2 18 20 42 44 60 62 78 80 102 104 120 122
582046460920961717: 0 2 30 32 90 92 102 104 114 116 174 176 204 206
587122058346673007: 0 2 12 14 54 56 72 74 90 92 132 134 144 146
599897416801893137: 0 2 12 14 42 44 72 74 102 104 132 134 144 146
# last = 22388597 # count = 9

The following solutions are missing here

532776053645838599: 0 2 18 20 42 44 60 62 78 80 102 104 120 122
536741135488704191: 0 2 6 8 48 50 108 110 168 170 210 212 216 218
562904248804042889: 0 2 42 44 78 80 120 122 162 164 198 200 240 242
564084788143487981: 0 2 60 62 138 140 168 170 198 200 276 278 336 338
574185979371371531: 0 2 36 38 66 68 108 110 150 152 180 182 216 218

See
https://boinc.progger.info/odlk/forum_thread.php?id=49&postid=5223#5223

The workunits ran out. But pending queue is growing.
That is because I am finally working on asimilation of twin gaps results. And the processing is very slow. I think it will speed up as the number of redundant rows decreases.