You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead?
If you want to make use of that hour you have with the whole team, you may want to consider running a retrospective. You can introduce the retrospective with simple honesty on your part: tell them that you don't feel the previous meetings have been productive and that you want to try something different to help everyone to benefit from the hour they have together.
In retros where I work, we will have three columns on a whiteboard, usually putting a smiley, meh, and sad face at the top, e.g. :), :|, and :(. Then the team members get to put anything on the board that they would like to talk about with the whole group.
In the happy column, you can celebrate successes (like congratulating Alice and Bob on the release of a project they worked on together), and you can declare victory with new processes you're trying (like the new bug tracker is much better than the old one).
In the meh column, you put things that aren't exactly happy or sad for the week. Maybe you purchased licenses for the new version of your IDE, and somebody hasn't seen any advantages of the new IDE -- they could put that on the board to figure out if everyone else feels like the upgrade was worthless or if other people have found ways that it is actually superior to the previous version.
In the sad column, you put things that haven't gone well for the week. Identifying the pain points for the week is probably the biggest benefit of a retrospective in my opinion. The whole team gets to discuss solutions to a real problem. On teams that all work on a single codebase for instance, someone might say that the FooBar class is unmaintainable and has been the cause of hours of debugging. Suddenly you find out that everyone else on the team has also lost multiple hours this week to FooBar, but nobody spent any time to clean it up. In that case, the team may collectively decide it makes sense for someone to spend time refactoring that code next week.
After everyone writes their proposed topics on the board, I like to briefly go over each topic and have its author give a 10-30 second explanation of the topic. This section of the meeting is easy to derail, so you'll have to be careful to keep people on topic -- e.g. someone will say that X has been a problem, and someone else starts talking about a solution to the problem; solutions shouldn't be discussed until after voting. In introducing the topics, you may find ways to group together multiple, closely related topics.
After the introductions, everyone gets three votes that they can distribute among the topics however they see fit. Finally, the votes are tallied, and whichever topics have the greatest number of votes is what the team discusses. For each topic, determine if there is an action that needs to be taken. Celebrating a success usually doesn't have an action item, but refactoring specific code can be assigned to one person. The action items should usually be completable by one person, but sometimes they are "whole-team" action items such as being mindful of having good commit messages.
Most retros tend to focus on topics in the sad column, and virtually no retros discuss everything that's written on the board. The meeting tends to finish whenever time is up. Immediately after the meeting, see that the action items are assigned to specific people; do this in whichever way makes sense for your organization.
I've had great success with retrospectives. They are a great way to build cohesion in a team, and they're a great way to reflect on the previous week and to refine your process. I think that if you try these out with your team, they will be much more engaged for your meetings.
Best Answer
By the time we do our team meetings, we already know what we've been doing all week and what we'll be doing next week. And we have a reasonable overview of the long-term plan.
What we do in our team meetings is talk about what is bugging us. Anything that happened in the last week which slowed us down significantly, things that we'd like to change in the future, particularly process problems.
The round-table format is similar to yours but we come out of it with a load of tasks for various people. And we're very keen to keep it light-hearted. People are expected to be able to be totally open and are discouraged from taking things personally.
And we deliberately time this meeting to be the last half of a Friday morning and go from there to the pub for lunch (non-mandatory), which doesn't necessarily last only an hour.
I would suggest from experience that managers (ie. anyone above team leader / project manager) shouldn't be in these meetings. It only discourages people from being totally honest. Team leaders / project managers can relay messages upwards in different meetings.