Thanks Gerald.

Yes … but checking through the bad.adi is a separate, optional user activity after the import is done, which I suspect hardly ever gets done.  I’m suggesting it might be nice to know what’s going on under the covers while the import is happening. 

Personally I don’t think detected-and-skipped duplicate QSOs even qualify as “errors”: I’d quite like to know if there are any genuine errors in the ADIF (meaning data record/field formatting or content errors such as 160 or 99 or missing etc.), but at present any genuine errors may be buried under an unsightly pile of dupes.

If we were shown live counts of errors and dupes racking up during the import, it would also be clearer to the user that both are being identified and handled.

For bonus marks, I’d quite like to know if there are any ‘new ones’ in the import – perhaps sounding the same audio cues as are defined for new ones arriving on DXcluster (since I think the cluster feed is suspended during the import), and showing the counts e.g. “1 new DXCC, 3 new band-mode slots, 2 new IOTAs …” [I realise there are lots of ways to define ‘new ones’, hence it may be quite complicated to specify the requirement properly for Bob, but since the import function updates the statistics already, I’m naively suggesting giving us the option to notify us when it updates the stats].