I finally got around to looking at a few things about the Manhattan that I didn't see addressed in other reviews.
My main interest in this receiver was the blind scanning because I got tired of having to do the manual method involving a few steps to figure out Symbol Rates and try them with my DVB-S2 receivers in order to try to find new DVB-S2 signals. Contrary to the denials in some of the Manhattan threads, this receiver at this point is DEFINITELY is not for the hard-core FTA'er but rather for the one who just wants to scan in a group of channels such as the internationals or religious on Galaxy 19 and do the occasional rescan for new channels.
The blind scan function of the receiver is awful. On a fairly light use Ku-band satellite (SatMex 6 Ku), there are 17 known lockable (DVB-S/DVB-S2) signals and the receiver found 14. That is not too bad (82% found) but it's missing a few of the ones with video services.
Where this thing really was poor was a high density, mixed DVB-S/DVB-S2 bird like SatMex 5 C-band. Out of 48 known lockable (DVB-S/DVB-S2) signals, the Manhattan blind scan only found 18 for a found percentage of 38%.
I then tried the dull Galaxy 19 Ku-band sat (dull as in every transponder with a video or audio signal is transponder-wide MCPC) and Manhattan found every single one of the easily lockable signals.
Based on how many have commented about how they like the speed of the blind scan feature, I feel the receiver might have been designed for speed rather than accuracy. I certainly believe that there could be an improvement to the blind scan function at some point since it should be a firmware-based fix and that it will make scans much slower for the benefit of accuracy. That should make the blind scan function more acceptable to a hard-core FTA'er who wants to know with almost a 100% blind scan found percentage EVERYTHING that is out there to be watched or listened to.
Blind scan seems to be best when you have wide signals or narrower signals that have lots of spacing between them. Narrower signals located fairly close together or whose symbol rates are below 3000 seem to be the ones most missed.
Signals with tons of audio services are disappointing with the Manhattan. It's great that the Manhattan will play a lot of those audio signals that my other receivers can't handle due to audio format used or lack of a video carrier with each audio service, but the disappointment comes with the partial memory-writing of those audio channels. On a 100 channel service using one audio service per program, only 60 audio channels were written to memory. If you are looking for a particular audio service that you know exists, you'll have to analyze the transport stream or find the info elsewhere in order to manually define the channel you want if it was not written to memory.
I don't understand why the Manhattan has is a service ID issue with many signals - a few video channels that have good service ID's scan in as "ch-x" with "x" being a number. Almost all of the audio services I looked at also scan in with that generic type of service ID rather than their actual service ID that can be seen in transport analysis of a signal. In the case of the audio, the number in the generic SID seems to correspond to the program number so you have some starting point trying to match up what you've transport analyzed compared to whatever the Manhattan has written to its memory.
Audio services with like 6 or 9 audio channels were written to memory completely (so the partial memory-writing issue seems to be with much larger audio channel signals) but the generic SID issue also occurred.
I did find there might be a 20 channel audio limitation when all the audio carriers are defined for just one program (rather than one audio service per program).
Tuner sensitivity - definitely the best of any receiver I have. I used FSTV as my example since it's only a signal I've previously been able to lock on my 8 or 10 foot dishes and not my 1.2m ku dish. FSTV locked on my Manhattan with a 14% quality on the 1.2m. That's great as it actually locked and surprisingly FSTV played with very little breakup considering how low of quality signal there was. Wondering if it was worth the extra expense over the Openbox S10 to have a sensitive tuner, I found the Openbox's tuner was just as sensitive. No problems locking the FSTV signal using the 1.2m dish, same 14% signal quality, and same fairly stable playback as the Manhattan.
I like the Manhattan's auto-power off mode feature - when a signal goes away such as a news or sports feed and you're not paying attention in order to turn off the box or change to another signal, after some amount of time the Manhattan will turn off the box automatically.
I also like how the Manhattan seems to remember your settings when you tune away or tune back to a signal. Example: When a video service has secondary audio and you hit the AUDIO button on the manhattan to listen to the secondary audio. When you turn off the Manhattan or flip to another channel/satellite and eventually come back to the signal with secondary audio, the secondary audio is still the active audio channel until you hit AUDIO and go back to the primary audio channel of that service.
I did find some weird service where the video was not encrypted yet the "SCRAMBLED" graphic of the OSD popped up over the video. I suspect the audio may be encrypted causing the "SCRAMBLED" OSD graphic and I'll be checking on that through transport stream analysis soon to find out if the audio is encrypted or not.
[edit] Even my desktop PC clock is not actually accurate, unless I automatically synch it daily with a time server. I guess it might be MORE accurate to say that the Manhattan clock is more suitable for use in PVR operations than the Solomend 800 clock. Certainly the Manhattan does not contain a battery backed RTC chip. [/edit] 
