to your first question:
If you activate the Podtrac support on the General Settings page of podPress then the URL scheme of the media file in the feed or on the blog pages will not change. But the it will definitely have an effect.
As you can observe, podPress masks the URLs of media files which were added with podPress. The URLs will get an URL scheme like "http://www.example.com/podpress_trac/feed/123/0/mypodcastepisode.mp3". If one open such an URL in a browser or feed reader or else then podPress will notice the URL scheme and return the original URL (e.g. http://www.example.com/wp-content/uploads/podcasts/mypodcastepisode.mp3) and redirect the browser or feed reader etc. to the media file.
When you activate the Podtrac support then podPress will return the original URL of the media file in combination with the Podtrac URL e.g. "http://www.podtrac.com/pts/redirect.mp3?http://www.example.com/wp-content/uploads/podcasts/mypodcastepisode.mp3". This means that the request gets redirect to the Podtrac page, where the request gets processed once more.
I hope that this is still the correct Podtrac URL. So far I could not find contrary information.
to the second question:
The Flash players on the website are using partially them same way to request the media file and the HTML5 players (in browsers like Chrome or Safari) working a little bit different but in the end the request gets redirected with the Podtrac URL in front of the original media file URL.
In other words: Yes, Podtrac should count when someone plays the file on the blog page.
to the third question:
Since iTunes is something like a feed reader, the counter should work for downloads via iTunes too.
However, another show in our category feeds does not:
I don't know why it would be any different. Do you?
I'm not sure what is happening with the media file URLs in this feed. Because the URLs are all URLs like "http://feedproxy.google.com/~r/Macreach/~5/ncLPt6ue4oA/MacReach_43.mp3". It seems that the URLs get once more redirected with this feed proxy service.
to much redirects could lead to problems. The iTunes server which gathers the information about the podcast from the feed and offers also a player on the iTunes page of the podcast can handle only 5 redirects (see http://www.apple.com/itunes/podcasts/specs.html#tracking).
I noticed a Podtrac error on the validated feed. Any ideas?
Use of unknown namespace: http://www.podtrac.com/player2.0/tips.php#rss the message?
This is only a notice and no error message. The feed is valid but the validator does not know the name space for the Podtrac XML name space. But that is no surprise to me because everyone may create its own XML name space and as long as one respects the common XML rules the feed will be valid. But only feed readers which can interpret the custom name space can retrieve the information from the custom elements. Otherwise the software would probably ignore the custom elements.
For more information about the Podtrac namespace follow this URL http://player.podtrac.com/tips#rss
btw: podPress does not use these custom podtrac feed elements. It uses only elements from the iTunes namespace a.k.a. iTunes RSS tags http://www.apple.com/itunes/podcasts/specs.html#rss