[Plugin: podPress] Major download issue, maybe permalinks issue? Help!

Hello Dan,

I can reproduce the problem – at lest with your blog. But so far I have not this problem on my test blogs. Although I will do some further tests. (This is post is something like an update on what I’m doing).

In general I can say that the URLs with the names of folders which not exist e.g. http:// ... /podpress_trac/web/642/0/habits-to-change-your-life1.mp3 are a product of the podPress statistics feature and these URLs don’t contain actual folder names. podPress uses the WP Permalink feature (and some WP filters) to mask the real URLs with a special Permalink scheme. podtrac is no folder. It is signal word for the podPresss stat counter. If someone clicks on such a masked URL (the URLs are only masked temporarily while the stats feature is active) then podPress notices that word and uses the other components of the URL to count. For instance /web/ stands for the download method – via the blog page. /642/ for the ID of the post and the /0/ (or any other number) for the number of the media file of that post. After podPress has processed the URL it leads the request via a HTTP 302 redirection to the real URL.
That redirection is most likely the problem here.
I have downloaded one file via the 2nd way from your blog and I received also only a file which was only a few bytes big. I have opened it with a text editor and could read this error message from your server:

<h1>Error 403</h1>
<p>We're sorry, but we could not fulfill your request for
/podpress_trac/web/561/2/habits-to-change-your-life3.mp3 on this server.</p>
<p>An invalid request was received from your browser. This may be caused by a malfunctioning proxy server or browser privacy software.</p>
<p>Your technical support key is: <strong>5ce1-abba-1756-6707</strong></p>

(an excerpt)

I’m not sure why this happens and why opening the masked URLs in a new tab is different then downloading via “Save link as” and why this does happen in some of my test blogs.

I will do some further test and report back later.

Tim

Dan,

I have tried to reproduce the situation in a test blogs on Linux servers. I have also added the URL of one of your files to a post in my blog.
But I could only reproduce it the problem when I have tried to download a media file from your blog via “Save link as” (Chrome) or when I have used a masked URL of one of your media files.

In conclusion: if you download a media file with Chrome and the “Save link as” method via masked URL from your blog then it does not work.
The error which shows the 403 HTTP error points in the direction that the masked URL could not be resolved and the redirect does not work – maybe a problem with the Permalink settings or a plugin which influences the Permalinks behaviour (maybe a security plugin) or recent modifications in the .htaccess file in the root folder of your blog etc..
But if it is something of the above then it is also not clear why this problem occurs only if one uses a certain method to download the file with Chrome and not with all the ways to download the file. How is the “Save link as” request for this file different compared to the one of the left click on the download link?

Do you know how to take a look into the server log files of your blog? There is maybe a file called accesslog or access.log or something like that. That file contains the requests maybe you can discover a difference between those two download methods.
maybe you can find also an error.log file besides the access.log. Maybe it contains other helpful error messages.

I have looked into these files on the servers of my blogs but I could not see suspicious things. On the other hand the problem did not reproduce the problem with those blogs and servers.

That all is why I think that it may have something to do on the server of your blog.

Eventually it helps to change the stat method of podPress. Which is the method your are using? Full+? Please, try Full and Counts Only.

I will think about this problem and the possible causes. But I need your help.

To know the active plugins in that blog would be interesting. It would great if could send it to podpress at web dot de.

Counts only… if I change this will if mess up the stats for my client?

Counts Only counts always regardless whether you have set the method to Full or Counts Only. (But that does not work vice versa.) That is why it is no problem to switch for a couple of minutes two Full (don’t try Full+). Full will collect the stats in a different db table. They don’t get mixed up with the result of the Counts Only method. But since this seems to be a popular podcast I recommend to switch back to Counts only after the test. (Full stores every download in a separate row in the db table that is why the table gets big if you have a lot of downloads. That might lead to problems.)

If you left click in any browser it opens a new window and plays the mp3. In Chrome you have to go File>Save Page As to download the mp3 file.. but this works every time because it pulls direct form the uploads folder and NOT the masked location.

If you click with the left mouse button on the download link a new tab or window opens and the address bar contains the real, unmasked URL of the media file. But the download link has the masked version of the URL as the href=”” value. That is why I would that counter mechanism and the redirection works if you use this method to download the file.
But if you are using Chrome and you make a right-mouse-button-click on the same link and choose “Save link as” the counter counts but the redirect is not work. That is why we should find out what the difference between those two ways to download the file is.

I will look into this tomorrow afternoon and upload a beta version with some modifications which might help to debug this problem.

I’m also interested to take a look into the log files but they are very big and I’m only interested in the last – lets say – 100 lines. Actually a right-click download should be 2 lines in the access_log. If you would do a right-click download and open the file afterwards then the last couple of lines should contain the data of this download request. The entries in bot log file should have timestamps which should help identify the data of the request.

this could be an issue, when I click “Test the Stat Method” it fails

Yes, this shows that something with the Permalink behaviour is not as it should be for podPress. So far I don’t no what it is. I still guess it could have something to do with a different plugin.
I have logged in to this blog and looked at the plugins page. I will try some of the plugins in my test blog.