adjust monoBN for SG-5113BBBK2972

[jbrzusto]

• was at Guelph Lake Nov. 20 2014 to Jan 30 2015, boot sessions 505-515
• next appearance at OldCut
• the appearances at Komoka in the following table are bogus.

Somehow, the receiver bootnum got reset.

sqlite3 /SG/receiver_map.sqlite

select * from bootnumMap where Serno="SG-5113BBBK2972";
2014|motus|komoka|SG-5113BBBK2972|16|17
2015|Motus|Komoka|SG-5113BBBK2972|16|17
2014|guglielmo|old_cut|SG-5113BBBK2972|23|32
2014|motus|old_cut|SG-5113BBBK2972|18|247
2015|Motus|OldCut|SG-5113BBBK2972|16|294
2016|Motus|OldCut|SG-5113BBBK2972|292|346
2014|motus|guelph_lake|SG-5113BBBK2972|508|515

The Guelph Lake monoBN should be moved to a negative number interval to they don't interfere with the Old Cut boot numbers.

[jbrzusto]

This was due to improper assignment of serial number and boot count to records recovered from a failed micro SD card. The records clearly belong to Guelph Lake (by their GPS fixes), but were given names with OldCut, 5113BBBK2972, and weird boot counts.

Fix this!

[jbrzusto]

The issue above is now closed, but the same receiver has some repo/db file count mismatches and needs to be rsynced against the older server to grab some randomly missing files.