WordPress.org

1. Jazzy CDN
   Member
   Posted 11 months ago #
   

   Well, last week iTunes removed my radio show listing from the iTunes Store after carrying it the last 2 years.

   Is the Podpress Default Upload Directory configuration the culprit? Undocumented changes in iTunes Store operations? and IP address in Japan? ... details follow ...

   The show continues to be broadcast with podcasts uploaded weekly.

   I had been running very old versions of WordPress and Podpress since it always worked ('if it ain't broke, don't fix it'), and I was only using wordpress to support podpress, I wasn't running the show's website on it (that is still an aging basic HTML site).

   However, I started seeing bizarre download activity suddenly one week a few months back - hundreds and hundreds of downloads suddenly going to one ip address within an hour (the first occurrence to an ip number in Japan, other times in other countries). Screwed up my stats royally. Still some suspicious download numbers accumulating.

   At this time (coincidence or related?) iTunes Store failed to update the program's podcast list for the first time. However after 3 weeks of updated shows being MIA, (and a couple of emails to podcasts AT Apple dot com for support) ... the missing shows returned. No explanation given ... just "they're up to date").

   "Victory, the problem is over" - I thought.

   Weird download events continued, I updated WordPress & Podpress to the most recent versions thinking maybe the old versions were somehow less secure and I was getting download-hacked (I had no idea really).

   2 things happened then:

   1) I started getting 1-second durations listed in my RSS feed (never happened before) and failures of the Podpress plug-in to correctly analyse the file size or duration of my podcasts when using the 'Add Media' options; (using auto-detect);

   2) iTunes stopped updating its listings again and after 10 or so missing shows, decided my program should be de-listed from the iTunes Store altogether (current situation).

   This was a weekly podcast running for 2 years on iTunes that a few months back was peaking at #4 out of hundreds if you searched for 'jazz podcasts'.

   iTunes subscribed podcast listeners continue to get the latest shows via their iTunes program – Apple seems to be brokering the RSS feed fine for subscribers.

   The iTunes Store is a separate operation and seems more fussy, fragile, or whatever and can't figure out from the RSS feed that the show continues.

   EMAIL FROM APPLE: The latest email from Podcast support re Apple Store Podcast listing contains this one line of techno-babble:

   "After pinging your podcast repeatedly, our systems continue to show a reset request from your servers, keeping our backend systems from being able to update the podcast."

   Godaddy has been hosting the files for years and for years it just worked. They had an explanation of what the above quote meant, except they haven't changed anything on their end and therefore what was working for 2 years and hasn't changed should therefore still be working (shared vs dedicated server hosting is there understanding, ie: I should move from shared to dedicated).

   UPLOAD DIRECTORY (aka - 'grasping at straws')

   In earlier research I thought I saw something about Podpress having a default "upload directory" and seem to remember reading that if the podcasts were not in that directory various compensations had to occur for functionality to operate normally.

   My podcasts are NOT in the default directory, from what I can tell. Was never a problem - 2 years of weekly updating prove that out. EXCEPT - maybe now it is a problem?

   Can the default upload directory be changed?

   Should I move all my podcasts into the default directory instead? (they're not far away – just one directory level up) ...

   Is it time to start searching for answers in Area 51?

   It would be nice to get back on the iTunes Store ... any ideas appreciated.

   Podpress 8.8.10.13

2. ntm
   Member
   Posted 11 months ago #
   

   That all does not sound very good.
   But I found your feed URL in the thread in the Apple forum and this feed looks fine (and the W3C Feed Validator confirms that). It is valid, reachable and readable. I see absolutely no technical reason why the iTunes Store server could not ping (reach and read) this feed.
   Do you know which URL you have registered as the podcast feed URL at the iTunes Server? Was it exactly this URL?
   Maybe it was a different URL - one which does not work any more.?
   The techno-babble from Apple suggests that the URL was wrong or the server of the blog was not reachable (maybe to busy) during the requests of the iTunes Server which was looking for new episodes.
   Do you use measures like robot.txt to prevent automatic web crawlers from indexing your blog?

   The only things about your RSS feed which are a little bit unusual are that the posts do not contain a text content (= <description> = <itunes:summary>). Maybe it is no longer allowed to leave that empty. I'm not sure about that. But Apple has modified the podcast guidelines recently a little bit (like a bigger itunes:image).

   about the duration
   It is correct that the duration values of the episodes 413-417 are only 0:00:01. That will lead to the situation Roger Wilmut explained in the the Apple forum (The player on the iTunes Store page of the podcast will play only 1 second of the podcast). But that is probably not the problem why the store page did not update. I know at least one other podcast which often forgets to set the duration value but is still in the iTunes Store and that page is up to date (e.g. http://feeds.feedburner.com/kuechenradioorg and http://itunes.apple.com/de/podcast/kuchenradio/id266735123).

   Furthermore the upload directory is maybe an issue in case of the duration detection function. But re-defining that folder or modifying the location settings on the general settings page of podPress is not necessary. The URLs of the media files are obviously correct.

   In case you want to use the drop-down menu to select the media files for each post instead of inserting the full URL each time, it is necessary to point the "URL of the media files directory" and the "Absolute path of the media files directory" to the same folder.

   You also mentioned that the auto detection of the duration works not as good as before. I have modified the this part of the plugin a lot in the last 2 years and it is correct that the auto detection of the duration works only if the media files are in a sub folder of the upload-folder of the blog (by default wp-content/uploads/). Your files are in a different folder. You may try the current Development Version of 8.8.10.14. That version includes an improved mechanism which will make the duration detection for files in sub folder of the blog more reliable.
   If the auto detection is not working then it is always possible to insert the duration value manually.

   All in all I can say that your RSS feed is technically correct. podPress works fine (maybe besides the duration detection). There is no need to move your files. The problem seems to be the feed and not the media files.
   The RSS feed is also currently reachable and since it is no longer in the repository, you can (and are allowed to) register the URL again.

   BTW:
   The current RSS image
   http://jazzboulevard.ca/podcasts/wp-content/plugins/podpress/images/large-channel-image-3.jpg is 600x600 pixels. But it should be only 144px x 144 px small.
   On the other side the iTunes:image should be 1400px x 1400px wide.
   (This is most likely not the reason why your podcast is currently in the iTunes:repository. But you should correct it so that your podcast can be featured in the iTunes Store when it is registered again.)

   Regards,
   Tim

3. Jazzy CDN
   Member
   Posted 11 months ago #
   

   Hi Tim,

   Thanks for the reply.

   Let me add some info culled from some fields within podPress – maybe there's something I'm not understanding in completing this info (when I updated the podPress plugin, I just left everything to defaults since I assumed the info would carry over) (and my problems with iTunes Store preceded upgrading the plugin).

   * GENERAL SETTINGS PAGE *

   URL of the media files directory: http://jazzboulevard.ca/podcasts
   Absolute path of the media files directory: same

   
   * FEED/ITUNES SETTINGS PAGE

   iTunes:FeedID 274055615

   iTunes:New-Feed-Url = Disable Then within that text, it shows the correct RSS feed you found on the iTunes blog - I assume disabled. Although looking now, it's the only place I actually see the correct RSS feed anywhere).

   (further down under PODPRESS FEEDS)

   current Feed URL: http://jazzboulevard.ca/podcasts/feed/podcast (which seems wrong, shouldn't that be the RSS feed?).
   iTunes: New-Feed-Url = disable
   iTunes:New-Feed-Url - the new Feed url = blank

   Now, as I'm looking at it, I'm wondering why the "current Feed URL" is pointing at the folder and not showing instead the actual RSS feed http://jazzboulevard.ca/podcasts/?feed=podcast

   Is there something 'fishy' here or does everything look normal?

4. ntm
   Member
   Posted 11 months ago #
   

   <iTunes:New-Feed-Url> should be disabled in your situation.
   You may activate it if you have a RSS feed which is already registered at the iTunes Store and only in case you want to change that URL. If you have a registered podcast and you have a new feed and you want the iTunes server to pull the information from the new feed then you activate that function and insert the URL of the new feed in the "the new Feed URL" input field.
   You can do that for the default RSS feed of the blog and you can do this for the podPress Feeds.

   It is inconsequent that the input field shows the URL http://jazzboulevard.ca/podcasts/?feed=podcast and the "current Feed URL" value is http://jazzboulevard.ca/podcasts/feed/podcast.
   But the last one is not pointing to a folder. Both URL are URLs of the same podcast feed. The last one is the version of the feed URL in your current Permalink scheme and that is why it is called the "current Feed URL"
   Both URLs are correct and working. http://jazzboulevard.ca/podcasts/?feed=podcast works (or at least it should work) always. The other one works as long you have activated a non-default Permalink scheme (which you obviously have).
   Another example:
   http://jazzboulevard.ca/podcasts/feed/
   is equal to
   http://jazzboulevard.ca/podcasts/?feed=rss2

   or with a post URL

   http://jazzboulevard.ca/podcasts/?p=266 is the same as
   http://jazzboulevard.ca/podcasts/2012/06/29/show-418-june-29-2012-montreal-jazz-festival-spotlight/

   see also http://codex.wordpress.org/Introduction_to_Blogging#Pretty_Permalinks
   and
   http://codex.wordpress.org/Using_Permalinks

   URL of the media files directory: http://jazzboulevard.ca/podcasts
   Absolute path of the media files directory: same

   Is "Absolute path of the media files directory" really the same? Is it an URL?
   It should be the absolute path to this folder. With path I mean something without http:// and without the domain name (here jazzboulevard.ca). It should look like /htdocs/www/.../podcasts/, but the name may include different folder names.
   Click on the question mark it should contain the absolute path for the general upload path of the blog. You may take this and modify it according to the name of the folder with the podcast episodes.

   Is there something 'fishy' here or does everything look normal?

   Well, things are a little bit difficult. But as I have written above the podcast feed is valid now and if you register it at the iTunes Store again, it should definitely work without problems.
   The issue with the picture size and the duration values are things you should fix but in the past they were no reason to reject the podcast.

5. Jazzy CDN
   Member
   Posted 11 months ago #
   

   Tim,

   I don't know if you're on to something with the Absolute Path field but currently both ARE indeed the same:

   URL of the media files directory: http://jazzboulevard.ca/podcasts

   Absolute path of the media files directory: http://jazzboulevard.ca/podcasts

   And now that you bring my attention to it there is a warning message below the latter stating "This directory is not valid or not accessible."

   There is also a suggested url that begins with "home/content/m/o/..." and ends with "...wp-content/uploads"

   I wonder if I should enter this as suggested, or maybe alter the ending to direct to the actual folder containing the podcasts?

   It indicates this interacts with the time/duration calculation (something that has been a problem) and these are longer programs running almost 2 hours each (1:52 generally and about 80Mb).

   I wonder if this is causing some sort of timeout on the iTunes Store pinging before it can get to the actual latest podcasts?

   Any thoughts?

6. ntm
   Member
   Posted 11 months ago #
   

   but currently both ARE indeed the same:

   That is bad and it probably explains why the duration auto detection is not working very well.

   There is also a suggested url that begins with "home/content/m/o/..." and ends with "...wp-content/uploads"

   Yes, take this value and modify it to the absolute path of the folder of your podcast episodes "home/content/m/o/.../podcasts" (replace wp-content/uploads with podcasts).

   But this will only help with the duration detection and maybe the way you can set the Location of a media file on the post editor page. But it has nothing to do with the pinging problem.

   I wonder if this is causing some sort of timeout on the iTunes Store pinging before it can get to the actual latest podcasts?

   No. Definitely not.
   Currently, there is no pinging problem with your RSS feeds. The feeds are valid and reachable.
   Please, try to register the podcast feed again at the iTunes Store. There should be no problem. If that is not possible then please post Apples explanation.

   The explanation which Apple gave you before points to a problem with the URL or the feed you have had registered at the iTunes Store. If there was a problem to reach and read the registered feed and if the URL was one of the URLs I have posted above then the problem is gone now.
   I don't know why it is gone now nor what has caused it in the past. There are a lot of possibilities and the explanation points to problem with the server of your blog or to a problem with the URL you have used in the iTunes Store. However the important thing is that problem seems no longer to exist.

7. Jazzy CDN
   Member
   Posted 11 months ago #
   

   All very interesting (and I'm learning a lot, sadly though, not enough to solve the problem yet).

   So, I altered the absolute path to actually BE the absolute path and immediately saw the drop down menu correctly operating within the plugin to select media, for the first time ... listing all the files in the podcast folder. Nice!

   So, to test-drive this new functionality, I opened a new post and randomly pointed at different mp3s in the ADD MEDIA FILE section, and hit the auto-detect button to see if file sizes and durations would detect properly now.

   Results were poor BUT intermittent. Generally file size calculated right (not always) and duration calculation usually (but not always) failed.

   Sometimes, I'd get a string of question marks for the duration, sometimes an odd symbol and letter ... BUT sometimes ... duration was right - and sometimes BOTH file size AND duration was right.

   In a random sampling of some mp3s from the drop down list, duration calculated correctly on mp3s: 363 380 386 390, however not necessarily file size. But then immediately previous or following mp3s would fail: ie: 379 and 381 didn't calculate duration right, while 380 did.

   But I didn't test every mp3. All but the first are at 96K, the first is at 80K. All have some ID3 tagging, slight variations, and file size is almost identical (except the lower coded one).

   NEW QUESTION: .HTACCESS

   WordPress is installed in a subfolder in the podcasts folder among all the podcasts. It appears WP (I assume) placed a .HTACCESS file in the podcast folder right around the time I updated WordPress and PodPress plugin. I never placed a .HTACCESS file in that folder.

   The contents of that .HTACESS follow:

   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /podcasts/
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /podcasts/index.php [L]
   </IfModule>

   # END WordPress

   I know HTACCESS files can interfere with access to folder contents (and do other 'stuff' as well) ... do you thing the contents of this HTACCESS file is tripping up functionality somehow?

   I have no idea what the programming of that HTACCESS file is doing to anyone trying to reach the podcasts, calculate their duration, or what would happen if the iTunes Store tried pinging that directory.

8. ntm
   Member
   Posted 11 months ago #
   

   WordPress creates the .htaccess file automatically. It contains the necessary rewrite rules which make it possible that you can use pretty URLs like http://jazzboulevard.ca/podcasts/2012/06/29/show-418-june-29-2012-montreal-jazz-festival-spotlight/ instead of http://jazzboulevard.ca/podcasts/?p=266

   These lines are almost the default entries of WP see:
   http://codex.wordpress.org/Using_Permalinks#Where.27s_my_.htaccess_file.3F
   The difference is that your blog is in sub folder of the domain that is why the RewriteBase is /podcasts/ instead of /.
   The file is absolutely how it should be in your case and this file with these lines is not responsible for the past problems with the feed.

   about the duration detection:
   You may use the current Development Version (8.8.10.14 beta 19). Make a backup of your db before you install and activate the new version.

   But since only some of the episode have no correct duration value I suggest that you insert the correct values manually for now. 8.8.10.14 will have an improved duration detection mechanism which will detect the duration more reliable again.

   Have you tried to register the feed in the iTunes Store again?

9. Jazzy CDN
   Member
   Posted 11 months ago #
   

   Ok, good to know the HTACCESS file is unrelated to the iTunes Store pinging problem.

   Armed with your comments, those of Roger and feedback from Godaddy, I'm going to make another approach to iTunes Store.

   As I mentioned above, the iTunes Store stopped updating the show initially for about 3 weeks and then re-started updating again for a couple of weeks before finally packing it in completely.

   Initially I didn't ask podcast support at Apple why it restarted the first time, but recently I did thinking it might shed some light on the current situation.

   The reply back was that they didn't do anything, it was the host (Godaddy) that changed something. However, I know for a (almost pretty sure) fact that Godaddy didn't do anything on my behalf the first time.

   I called them, they said everything is working fine from our end ... and that was the end of it.

   So too now, as far as I can tell, for them it's just business as usual. And of course, the podcasts are serving off their servers, and other podcasting platforms are getting the shows up and listed (one example: podcaster.fm)

   So, I'll see what iTunes Store support replies after I send the current info. I'll update when I have a reply - which can take days.

   More, soon!

10. Jazzy CDN
    Member
    Posted 11 months ago #
    

    PS - re: Status[Resolved]

    ... while I am optimistic about the results, and in a slightly celebratory mood given it being July 4th and all (even if I'm not in the US) ... resolved feels a bit 'rosy' at this point.

    Let's hope, but the show has yet to get re-listed on the iTunes Store, and so far, maybe [Resolved-ish] or [To Be Continued] ... no firm answers yet, only questions, and hope!

    Thanks

Reply

You must log in to post.