WordPress › Support » [Plugin: podPress] Download numbers hit a wall!

besweeet
Member
Posted 1 year ago #

http://twiiphone.com

I was using an older version of PodPress for about 2 months before I decided to update it. A few days after I updated to the latest version (updated last week), I noticed that my download numbers have taken a HUGGGEEEEE hit. I'm not getting nearly as many downloads as before the update. Here's a graph showing the sudden issue: http://twitpic.com/4kcv59

I'm using WP permalinks and the full stats setting. I WAS using third party stats, and it seems as though that that feature has been disabled for some odd reason.

Any ideas on how to enable 3rd party statistics? I searched, and couldn't find a thing.
ntm
Member
Posted 1 year ago #
Thanks for the report!

I'm not sure that the 3rd party statistics have something to do with that. But I will try to find out more about that.

You can reactivate the option by creating a new folder in the plugin folder of your blog. Call it podpress_options.

Edit the podpress_options-sample.php and add the following line of code:
```
if ( ! defined( 'PODPRESS_ACTIVATE_3RD_PARTY_STATS' ) ) { define( 'PODPRESS_ACTIVATE_3RD_PARTY_STATS', TRUE ); }
```
so that the last lines of the file look like these lines:
```
// If you set this constant to TRUE then [...]
if ( ! defined('PODPRESS_DEACTIVATE_PREMIUM') ) { define('PODPRESS_DEACTIVATE_PREMIUM', FALSE); }
if ( ! defined( 'PODPRESS_ACTIVATE_3RD_PARTY_STATS' ) ) { define( 'PODPRESS_ACTIVATE_3RD_PARTY_STATS', TRUE ); }
?>
```
Edit the .php file with an text editor like Notepad (not with MS Word).
Rename the file to podpress_options.php and upload it into wp-content/plugins/podpress_options/.

It would be great if you could tell me whether re-activating these options makes really a difference.

Regards,
Tim
besweeet
Member
Posted 1 year ago #

Thanks, got it to work again, although I had to use podporess_config-sample.php instead of podpress_options-sample.php, as it didn't exist.

I'll report back later today to see if it made any changes. If it doesn't, then I have no idea what would be causing the sudden download drop.
ntm
Member
Posted 1 year ago #

Sorry. podpress_config-sample.php is the right file. The file that I have meant.
ntm
Member
Posted 1 year ago #

I'm very curious whether this changes the rate of the downloads in your statistics. It would be nice if you could tell me which of 3rd party options you have used and you are using now. blubrry or podtrac?
besweeet
Member
Posted 1 year ago #

Blubrry.

I actually just noticed that, for every one download, the download number goes up by 3...
ntm
Member
Posted 1 year ago #

I actually just noticed that, for every one download, the download number goes up by 3...

Have you turned the 3rd-party stats option off again? I have tried to download and to play the last episode just some minutes ago and the number of downloads went up only by one for each download attempt.
I was also not able to reproduce that wrong counting behaviour. But I guess the reason is that I do not have blubrry keyword. I guess that you have one.?

It would be great if you could confirm or not confirm that this behaviour (counting each download 3 times) occurs only when the 3rd-party blubrry statistics feature is active.

Are the numbers in your blubrry statistics equal to (or approximately the same as) the podPress numbers?
besweeet
Member
Posted 1 year ago #

Enabling statistics hasn't really brought my downloads back. But, I did disable it, and the download number is still going up by 3 for every one download that *I* make.
ntm
Member
Posted 1 year ago #

How do you download the episode? Please, tell me which device or browser you are using to download the file. Does this error occur if you click on Download or if you click on the Play button?

I did disable it, and the download number is still going up by 3 for every one download that *I* make.

So you are sure that this behavior is the same regardless of the 3rd party statistic setting?
besweeet
Member
Posted 1 year ago #

I clicked on the play button for the HTML5 player under Chrome.
ntm
Member
Posted 1 year ago #

Thanks. The problem seems to be only related to the Chrome browser and the HTML5 player. I have had tested only with Firefox and Safari before and the Safari browser does not influence the download numbers as Chrome.
Further it is save to say that this problem is not related to the 3rd party statistic setting.

I will think about a solution. But to workaround this problem you can deactivate the HTML5 support in the player settings of podPress and the Flash player will appear again in Chrome, Safari and IE9.
ntm
Member
Posted 1 year ago #

besweet,

you might want to try the current Development Version. That version contains bug fixes which should correct not only this problem with the HTML5 player and the podPress stats.

Before you install this version make a backup of your data base.

Regards,
Tim
besweeet
Member
Posted 1 year ago #

I've just installed beta 8.

I'm still clueless as to what happened to my downloads...

http://img4.imageshack.us/img4/9440/unledpb.jpg
besweeet
Member
Posted 1 year ago #

So the HTML5 player isn't working... Downloading it directly works fine. Any ideas?
ntm
Member
Posted 1 year ago #

Thank you for testing the beta version!

So the HTML5 player isn't working... Any ideas?

Yes, probably. Do you use the both settings in the "Location of the Media Files" section of the general settings page of podPress? (Are both fields fill out?)

I'm still clueless as to what happened to my downloads...

I have also no idea. But the counting mechanism in podPress has not changed from 8.8.9.x to 8.8.10.2.
ntm
Member
Posted 1 year ago #

Please, upgrade to 8.8.10.3 beta 9 (which is the Development Version now). The problem with the HTML 5 should be fixed.
besweeet
Member
Posted 1 year ago #

Fixed :).

What's the oldest version that I should try that has a different counting system? Graphs don't lie :(.
ntm
Member
Posted 1 year ago #

What's the oldest version that I should try that has a different counting system?

One part of the counting mechanism has been modified for version 8.8.5 or 8.8.6. But that was only a minor improvement and no modification of the method. So it is save say that the counting mechanism has not changed since 8.8.
Independent of that, it is recommended to downgrade from 8.8.10.x to a version prior to 8.8.10. Because the organisation of the postmeta information of podPress has changed with 8.8.10 (see the changelog). You would need to adjust these datasets manually if you would downgrade. Otherwise no podPress attachements would appear in posts an feeds.

The most significant change since 8.8 which influences the download numbers is probably the the way modern browsers like Chrome and Safari handle the pre-loading of media files in cases when the media files are embedded with HTML5 tags (<audio>, <video>) and the integration of HTML5 support into podPress.
If a listener goes to a blog with podPress 8.8.10 - 8.8.10.2 while he/she uses e.g. Chrome and the option "Use HTML5 tags:" is checked then a click on the play button would be counted multiple times because Chrome requests the file multiple times if the files was not played before in the same session. (Safari request the file in the same situation only one time.)
If a podcaster would also activate "show HTML5 players always on page load" then the numbers would be even higher. Because the desktop versions of Safari and Chrome would pre-download (buffer) all media files which are embedded with HTML5 tags on page load. In the statistics it would look like someone clicked multiple times on all the players of the recent podcast episodes. I have read tweets of podcasters which have mentioned this effect basically.
But I have understood the problems after you have reported the problem you have encountered. (Thanks again for reporting the problems here!)

in conclusion: with 8.8.10.2 the numbers would be higher depending on your settings and the number of users which are using Chrome, Safari or IE9.

These problems will be fixed in 8.8.10.3 (also in the current beta version). podPress 8.8.10.3 uses the also new Javascript event "onplaying" to trigger the counter and that event happens only if someone really clicks on the play button of the HTML5 player of the browser.

But I have no explanation for the obvious sharp bend in your statistic. Also I could not reproduce this problem in my own blog. That is why I'm not sure whether it is really a problem of podPress or not. As I have written above the counting mechanism has not change in a long time and the one thing which may have influenced the numbers since 8.8.10 is fixed now.

Maybe control the raw data. Are there a lot of downloads from in a row from the same IPs? Have you blocked the search engines some how in that time when you have installed 8.8.10. the first time? or did you modified other settings of podPress or your blog?

Regards,
Tim
besweeet
Member
Posted 1 year ago #

Big problem... My feed isn't being validated: http://www.feedvalidator.org/check.cgi?url=http%3A%2F%2Ftwiiphone.com%2F%3Ffeed%3Dpodcast#l4692
ntm
Member
Posted 1 year ago #

The validator show 3 problems.
One of them is the email tag is empty. That is something you can fix easily.
One of them will be resolved by the podPress 8.8.10.3 beta 10 (Development Version).
But it is possible that the problem `line 4637, column 3: Invalid character in a URI: \""http://altfarm.mediaplex.com/ad/js/6549-105872-12428-1? (2 occurrences) [help]

]]></content:encoded>will not go away with the upgrade. This message points to a post which has a section with Javascript inside the post content. The problem seems to be that this section is surrounded by<![CDATA[and]]>. That is okay for you blog page. But in the feed the post content is placed in<content:encoded><![CDATA[and]]></content:encoded>` and if there is a further CDATA section inside the content of the post then the feed will be not valid.
So remove the CDATA section elements of the Javascript snippet or maybe the whole section. If this code is inserted by a plugin then try to find out whether or not it has an option to avoid placing the snippet in the post content in feeds.

podPress does not modify what is in the <content:encoded><![CDATA[ and ]]></content:encoded> section.

Regards,
Tim
besweeet
Member
Posted 1 year ago #

I've been making my posts the same way for over a year, and I've never had an issue with validating a feed until just now, and it just happens to have been after I updated to the beta. Is downgrading to the previous release as simple as extracting the files?
besweeet
Member
Posted 1 year ago #

Also, I've been on beta 10 since the beginning of the day.

For whatever reason, it wouldn't pick up the email address, so I had to edit podPress_config via MySQL and manually insert the email address in between the empty quotes. Was immediately valid after making that change.

Unfortunately, ALL of my PodPress settings were reset when making that one little MySQL change.

But I did notice that the MySQL database was over 150MB in size (which explained the long edit and download time).
ntm
Member
Posted 1 year ago #

Is downgrading to the previous release as simple as extracting the files?

No, it is not (see the explanation above.)

For whatever reason, it wouldn't pick up the email address, so I had to edit podPress_config via MySQL and manually insert the email address in between the empty quotes.

podPress uses for the feed with the slug name podcast the email value which you have inserted in the podPress Feeds section for this specific feed. podPress uses for the podPress Feeds no alternative value e.g. like the email address of the blog owner. If you leave that field on the Feed/iTunes Settings page empty then there will be no email address in the feed. That works this way since 8.8.8 and there was no change since that version.
I have tested this function on multiple server platforms and with different browser. It works also in the recent beta version.
It is highly unlikely that you "[...]had to edit podPress_config via MySQL[...]". I would not have recommended this approach, too. Editing this serialized array is not a good idea. Because the structure of that array can be wrong afterwards which leads to the situation that the plugin uses default values instead.

But just to be sure that there is a bug or not, I would like to ask you to open the Feed/iTunes Settings page, go to the podPress Feeds section and modify the "Owner E-mail address" of the feed with the slug name podcast. Save the settings and control whether the new value is still in place after saving the setting (or if it switches back to the value which you have manually inserted via the db interface).
If there is a bug, I will fix it.

Regards,
Tim
ntm
Member
Posted 1 year ago #

But I did notice that the MySQL database was over 150MB in size (which explained the long edit and download time).

If you are using the statistic logging method "Full" (or Full+ which is not recommended) then the wp_podpress_stats table grows with every download.
Displaying the stats in the line below the podcast player is a nice thing and was helping me to see the miscounting. But to produce each number the plugin makes a few db queries which can slow down the page loading depending on the performance of your server the number of page requests and the size of the db table.
You might try deactivating these numbers.
besweeet
Member
Posted 1 year ago #

The email address for my primary feed, which was the one that was causing validation issues, was coming from the owner of the blog, which has been set since day one. Changing it to something wouldn't fix it, so going the manual route was my only [simple] option.
robbiegod
Member
Posted 1 year ago #

will podpress work with podcasts that are on iTunes?
ntm
Member
Posted 1 year ago #

@robbiegod: It is possible to register feeds which are produced by podPress in the iTunes. Please start a new thread if you have more question.

@besweeet:
The email address for the values of <managingEditor>, <webMaster> and <itunes:email> (all are channel elements) of the feed http://twiiphone.com/?feed=podcast are coming solely from the setting "Owner E-mail address" of the podPress Feed with slug "podcast".
It is right that this value came from the blog owners setting (which you can change via the general settings of the blog) in older podPress version. But this definitely different since 8.8.8. It is possible that during the upgrade from a pre-8.8.8 version the value of the email address was not taken over properly. Maybe it was simply empty since that upgrade.

It is right that the value is stored in the podPress_config array in the db. But you should be able to change that setting via the podPress Feeds section on the Feed/iTunes Settings page without any problem.

But question to you is: Are you able to modify the modify the "Owner E-mail address" setting of the podcast feed via the Feed/iTunes Settings page?
What is in that field when you open this page?
Are you able to save a different value via this setting? Or stays the value the same no matter what you trying to save as the new value?
Please make this test and tell me which browser you have used.

(Which feed do you mean with "my primary feed"? Maybe post the URL.)
ntm
Member
Posted 1 year ago #

You may try 8.8.10.3 beta 11.
besweeet
Member
Posted 1 year ago #

My primary feed is pulling in the email address from the general settings. My second feed (called "iTunes") has actual text fields for that information. While everything is fine now, my feed never had problems until I tried the beta version, where it wouldn't pull in the email address from the general settings.

I'll just stick with beta 10. Don't want to experiment with anything else. Might switch to PowerPress.
ntm
Member
Posted 1 year ago #

I'm still not sure what your primary feed is.

Have you done the little test with the feed which has the name "iTunes"?

I really trying to improve podPress and to fix bugs. But sometimes I need help from the people who report problems. Some problems are limited to very specific conditions and the more I know about the conditions the better I can find and fix the problem.
For instance: Which is your primary feed? (Please, post the URL of this feed.)
If you do the little test then please tell me the browser you have used during the test.

If you continue to use podPress then you should upgrade to beta 11. Beta 10 has a bug in the Popup player function and with the HTML5 counting mechanism. Both problems are limited to beta 10. In other words beta 11 has less bugs than beta 10. (Furthermore I can assure you that I have nothing changed in the parts of the plugin which are producing the feeds. The feeds are going to stay valid with beta 11.)

However, thank you for your help so far and the reports.