I have been encountering the same issue as reported in the several previous posts - after upgrading to 2.1.7 and running fine for just a while, I am not able anymore to correctly sync any of 6 wallets on 4 machines (also tried connecting through my 4G internet provider to get a brand new IP address thus eliminate possible banning issues, but the result was the same).
There are 2 issues I noticed:
1 - the wallet "decides" it has synced  (changes its status to In Sync) the moment it encounters a new connection with a lower startingheight than it's own, or lower than the previous higher height connections it found (I am using the getpeerinfo command from the Console). The wallet then (syncs to) and starts staking at that lower block height (if the total number of connections at that time is >= 3). Then only if it gets a new connection with a higher than it's own block height, it goes to Syncing mode but no blocks get further downloaded (see issue 2 below).
2 - the wallet remains in the state "Syncing" no matter how many connections with a higher startingheight it has. Then later on as soon as it gets accidentally a new connection to a node with a lower startingheight (than it's own or the previously found higher height connections) , it goes to issue 1 above. If the total number of connections at that time is >= 3, it even starts staking at that lower block height.

Right now I have re-loaded the blockchain from the newest bootstrap, up to block 1455297, and trying to sync from there on. I have snapshots of both issues, if needed.

Isn't the protocol originally supposed to choose the highest blockchain? Why does it decide to have synced and starts staking only when it finds a connection with a block height lower than the previously found? Was there any "hot-fix" change made to the basic-level consensus protocol so that the 2.1.6 -> 2.1.7 transition gets propagated faster?

To everyone that is still experiencing issues, please follow these steps:

1. Shutdown your wallet.
2. Uninstall the SolarCoin wallet.
3. Verify that the clock is set correctly on your computer.
4. Make a copy of your wallet.dat and save it in a safe, temporary, location.
5. Delete EVERYTHING in the application data directory (C:\Users\{your name}\AppData\Roaming\SolarCoin\).
6. Delete EVERYTHING in the program directory (C:\Program Files (x86)\SolarCoin\).
7. Download and Install the 2.1.7 wallet from: http://solarcoin.org/downloads/
    (Respond 'No' to importing a wallet.)
8. Run File->Reload Blockchain, then wait for the wallet to restart and fully sync with the network.
   (This should happen automatically after the install. You will need to provide a password for the new wallet.)
9. When the wallet is fully synced, shutdown the wallet again.

10. Copy your saved wallet.dat back to the application data directory.
11. Startup your wallet.
12. Run File->Rescan Wallet (Your wallet will restart and take a while to fully come back up.)

This is a sledgehammer approach, but removes all possible variables.

Notes:
  Executing steps 1 - 9 with a fresh (empty) wallet will make the process go much faster, as there are no transactions in the empty wallet to scan for.
  The installed solarcoin.conf file should only have one addnode for the master-node server. If you use a custom conf file, please wait to reintroduce it until you are fully in sync.

Thanks for you patience,
Steve


EDIT: I just ran through these steps, and everything synced up fine. Please follow the steps exactly. Thanks.

Did your solarcoin.conf have just the master-node?

Give me five minutes. I'm rebuilding the bootstrap.zip now so it is as current as possible.

Tried sending slr to bittrex and although the wallet is supposedly up and running it doesnt seem to be showing.

Anyone know whats up?

Please hold off sending any SLR until the syncing issues are resolved. Thanks!

Following the steps to the letter, just doin the wallet rescan now, confirmed the masternode in the conf file
EDIT: All done, in sync for now..........

Also, I just got In Sync & Stacking. At block 1455297!!! Then it started syncing again, with much fewer block left to sync - it now shows 1455649 as the total number of blocks it is targeting to sync up to. And yes, the wallet started receiving blocks and syncing up to that target. Here is what getpeerinfo is showing for the several connections that just came in:
{
"addr" : "92.135.75.153:17445",
"services" : "00000003",
"lastsend" : 1478972794,
"lastrecv" : 1478972758,
"conntime" : 1478971893,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1456003,
"banscore" : 0
},
{
"addr" : "40.112.185.197:1280",
"services" : "00000003",
"lastsend" : 1478972331,
"lastrecv" : 1478972065,
"conntime" : 1478972065,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1455934,
"banscore" : 0
},
{
"addr" : "37.112.117.122:63750",
"services" : "00000003",
"lastsend" : 1478972110,
"lastrecv" : 1478972107,
"conntime" : 1478972107,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1455297,
"banscore" : 0
},
{
"addr" : "125.193.49.2:56917",
"services" : "00000003",
"lastsend" : 1478972250,
"lastrecv" : 1478972785,
"conntime" : 1478972164,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1456006,
"banscore" : 0
},
{
"addr" : "24.186.0.49:20986",
"services" : "00000003",
"lastsend" : 1478972252,
"lastrecv" : 1478972250,
"conntime" : 1478972249,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1454513,
"banscore" : 0
},
{
"addr" : "81.247.156.211:18188",
"services" : "00000003",
"lastsend" : 1478972769,
"lastrecv" : 1478972770,
"conntime" : 1478972560,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : false,
"startingheight" : 1439173,
"banscore" : 0
},
{
"addr" : "195.154.185.5:57135",
"services" : "00000003",
"lastsend" : 1478972723,
"lastrecv" : 1478972790,
"conntime" : 1478972716,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1456015,
"banscore" : 0
},
{
"addr" : "174.57.202.216:49976",
"services" : "00000003",
"lastsend" : 1478972759,
"lastrecv" : 1478972759,
"conntime" : 1478972757,
"version" : 70005,
"subver" : "/Satoshi:2.1.7/",
"inbound" : true,
"startingheight" : 1455649,
"banscore" : 0
}
]

Now it is in sync & stacking at block 1455675. I have disabled staking (obviously why).


I am re-confirming my observations:

All, I am going to issue a new wallet, version 2.1.7.1, soon which has the following changes:

1. Increase the number of required connected nodes to 4 before allowing your node to stake.  This will alleviate some of the mini forking, by requiring a stronger pool of nodes before you can submit new blocks.
2. Added 4 new checkpoints to help keep all the nodes on track, and prevent requesting blocks from possible forked nodes.  The new checkpoints are:
            (1000000, uint256("0x96d44ecebaf37bc17044a52ecaf7ba9da16ecbb42936402de3e23c38561a6b20"))
            (1440000, uint256("0xae70181c2b2a0af8eb16916f4037ceaf674f3b040e3609d59193a8c37f44e096"))
            (1450000, uint256("0x65051554822826f1ced143093bba9443c00f4c53138a06df193741cdee3b3ac8"))
            (1456000, uint256("0xd7c13104530a9794dc67a623111e6644b3110f7b18b6f8aa3a92aae8162d9996"))


Note to Joe and Nick, there is no rush to get the exchanges and block explorers updated.  This is primarily for staking nodes.

-Steve

I am fully synced and on the correct fork, any ideas or is it just a case of wait and it will all resolve itself?