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

And I am using the most current version of Podpress.

Actually, looks like this is a quirk with Google Chrome! I just downloaded an mp3 with Firefox and it works fine. That is a very strange quirk. If anyone thinks it could be an issue with the plugin or a setting let me know.

Thanks
Dan

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. https:// ... /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

Thanks so much 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.

Thanks again for the help, I’ll try to answer as much as I can.

1. Do I have a plugin that influences the Permalinks: Not sure… I don’t think so.
2. Has there been a recent mod to the htaccess file: no, I have never done anything to it
3. How is the left click different then right click on the DL link? 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.
4. Do I know how to look into log files? Never done it but I am currently downloading the error_log file from my root folder… nit sure if this is a WP file of not. But is is 870MB for some reason!! THere is another error_log file in the wp_admin folder that is 371MB, I will also download that one. I did not see an access log file anywhere, not sure where that might be.
5. May have something to do with the server. I did open a ticket with my host (Site5) and gave them admin access to my WP site and they obviously have access to my server files and they couldn’t see anything (the guy had never heard of PodPress though so I am not sure how familiar he was with WP). They said it wouldn’t be server issue.
6. Stat Method? Counts only… if I change this will if mess up the stats for my client? They depend on daily tracking of downloads based on the counts.

Can I get your email to send you a link to a screenshot of my active plugins? Are there any files you need from me? I can send you a download link if you want to analyze them.

Thanks!
Dan

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.

Thanks again.

I tested the FULL option for the stats and it had the same results with Chrome. Also.. this could be an issue, when I click “Test the Stat Method” it fails under both FULL and Counts Only. It did that the other day too. But yet it still reports the stats… what’s up with that?

I will email you the screenshot of the active plugins and I will ALSO give you admin access to my site so you can peek around. If you make any changes please let me know if it will affect the site or my client. But that may be a good way for you to get a 1st hand look at the settings.

When I looked at the error log it had a few lines of errors that have been repeating every minute and have been doing so for months… not sure what the error means but I will send them to you. I still don’t know where the Access log would be, I only have error_logs.

Thanks!
Dan

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.

This problem is connected to the Bad Behavior plugin (v2.1.14).
One possible workaround for this problem is to define a whitelist entry in the whitelist.ini of the Bad Behavior plugin for the podPress statistics URL scheme.
The folder /wp-content/plugins/bad-behavior/bad-behavior should contain a text file with the file name wishlist.ini. To resolve this specific problem the file needs to contain only this:

[url]
url[] = "/podpress_trac"

If the blog is in a sub folder e.g. https://example.com/blog/ then the entry in the whitelist file should be url[] = "/blog/podpress_trac".

You should also look into the wishlist-sample.ini file in the main folder of the Bad Behavior plugin for more information.

Thanks Tim! That did the trick, all issues resolved. Thanks for the incredible service and the great plugin!

Dan

This is looking like a bug in Google Chrome. I’ll be contacting you privately to obtain further information.

@error, NTM figured it out, it wasn’t a Chrome issue at all, it was a conflict with another plugin. No need to take action.