It may be that you've encountered one of the logistical limitations of the EventCalendar. Here's the deal..
Events are populated using three different calls to the database: standard events, announcements, and recurring events. After each query, the function dumps the results into this huge array of date objects. The last thing it does before returning it to the template is sort them, and then, if the default view is active, it truncates them down to that number.
We did this because, when the function is not passed an end date, it wouldn't know when to stop adding events. This is especially problematic for recurring events, but it also applies to the other two. If it cut off when it reached the default event display total, then the other queries may never get run even though they have valid upcoming events. So the solution was to allow all of them to add what they want, then sort it all out and cut down the set at the end.
For lack of a better idea for a "forced" end date, we chose 6 months from the start date. Seeing that it's June, six months puts you at the new year, so that all adds up.
What I'm going to do is make the 6 months a global variable that can be configured in your _config.php. Run an update within the next 20 minutes or so, and you'll be able to add
Calendar::set_param('defaultFutureMonths', 12);
Obviously, the higher you make that number, the more processing time you're adding to the controller. Shouldn't be too bad if you don't have many events, though.
The other option for you, if you're using the UpcomingEvents() function is to pass it a third argument for the end date you want.
return $this->UpcomingEvents(
null, // filter
null, // start date, will default to today
"2010-06-01"
);