It may be a quirk of the way your renderer is functioning...
When a UPnP Control Point (like MC) wants to play a track, it commands the renderer to download that track using an HTTP GET command; and (I think) the MC play counter is measuring how many such GETs have been received for every track.
However I have seen cases of renderers which, depending on the type & manufacturer, and the type of media file, make more than one GET to download a track file. In such cases, the first GET is either a) to check if the file even exists, and/or b) to check for meta data in the file, or c) to check if the server supports byte-range seeks. And the second GET is to actually fetch the media stream. In such cases the MC play counter would register two play counts for each actual play.
Because this depends in a very variable manner on the renderer type & manufacturer, and on the media type, it would be very hard for MC to solve this with an easy rule. Perhaps a new version of MC could be programmed to ignore duplicated GET's for the same track, from the same renderer, within a certain time window. Just an idea...