• I noticed this problem a while ago but it never really bothered me much until the feature was added to display the total downloads next to the actual download link on the post itself. Because of that, I decided to look into why the numbers were so small and while checking out the mysql database tables, I found that there were duplicate entries in the podpress_statcounts table. After checking the media names column I found that all of my media file names contain parentheses () in them. It seems that because of this, there were two rows created for each podcast media file. One row with a media name containing the normal parentheses () and another row with the parentheses replaced with URL encoded values of %28 and %29 instead of the ( and ) from the first row. Since I have Full Stats enabled, I also checked the podpress_stats table and found that this problem did not happen there. That table only contains entries with the normal () and no URL encoded parenthesis values.

    This issue seemed to start at least of few updates ago. I didn’t always update when there was a new version, so I’m not sure of the exact version number, but I believe it was when enhanced stats features were added.

    Here is a small portion of the most recent rows from the podpress_statcounts table:

    "postID","media","total","feed","web","play"
    126,"Ketonom%20-%20Moon%20Phase%2004%20%28320k%29.mp3",6,0,2,4
    126,"Ketonom%20-%20Moon%20Phase%2004%20%28192k%29.mp3",22,0,2,20
    126,"Ketonom%20-%20Moon%20Phase%2004%20(192k).mp3",1983,9,1486,488
    126,"Ketonom%20-%20Moon%20Phase%2004%20(320k).mp3",1740,3,1567,170
    132,"TFCM04%20-%20Ketonom%20(320k).mp3",214,7,191,16
    132,"TFCM04%20-%20Ketonom%20%28320k%29.mp3",2,0,0,2

    Of course, these additional rows also show up when viewing the podpress stats from the wordpress administrator panel as well.

    Edit:
    I should also note that postID 132 was created just recently while I was on podPress version 8.8.10.9 (I think). I just upgraded to 8.8.10.12 right before posting this.

    https://www.ads-software.com/extend/plugins/podpress/

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter Ketonom

    (@ketonom)

    Update:
    I kept digging through the podpress_stats table just to be absolultely certain I didn’t miss anything, and I actually did end up finding rows with a media name containing URL encoded parentheses. I suppose this would explain why these rows are also showing up in the podpress_statcounts table. This issue seems to be occurring over many different languages, browsers, and operating systems according to the stats stored in that table.

    Plugin Author ntm

    (@ntm)

    Thanks for this very precise report!
    I will look into this matter and report back.

    Thanks,
    Tim

    Plugin Author ntm

    (@ntm)

    I’m sorry that this takes so long. I have not much time to work on podPress but thanks to you report I could already identify the problem and work out a solution.
    Since version 8.8.10 podPress supports the HTML5 <audio> and <video> elements and if “Use HTML5 tags:” is active then Chrome, Safari and IE9 will show the player of the browser instead of the Flash player like the 1PixelOut player for mp3 files. (Firefox and Opera will show the own player for ogg and ogv files instead of the Flash player.)
    It was necessary to implement for these players a different method to trigger the download counter of podPress unfortunately I have made a mistake and this method encodes special characters in the filenames differently before the counter stores the click in the db. That is why you have found two versions of the file in your db table.
    For instance the filenames of your episodes contain round brackets e.g. Ketonom%20-%20Moon%20Phase%2004%20(192k).mp3. While the default method encodes only whitespaces as %20, the method behind the HTML5 players encodes also the round brackets. For instance ( becomes %28 and ) becomes %29.
    Another but related problem is that podPress displays only the results of one of these methods and ignores the other db entries.

    There exist other reports related to this problem. I have had trouble to imagine what the cause of the problem could be. But thanks to your report I know now what is wrong and have already started to fix the problem.
    I cannot tell exactly when an upgrade will be available. But I hope that I can finish the modification in the next two weeks.
    The upgrade will merge the duplicate entries in the wp_podpress_statcounts table (stat method: Counts Only) and will probably rename the entries in wp_podpress_stats (stat method:Full/Full+).

    Regards,
    Tim

    Plugin Author ntm

    (@ntm)

    As I have written, I was hoping to finish the work on the next podPress version until the end of this week. But I know now that I have very much (more than I have expected) to do for my day job and that the next podPress version not be ready in the next two weeks.

    Thread Starter Ketonom

    (@ketonom)

    That’s alright. I am just glad that you found the cause of the problem and are able to work on a solution. Take as long as you need to finish it.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘[Plugin: podPress] Duplicate download statistic rows in mysql database’ is closed to new replies.