I self host my podcast. My XML is current and all distributors are working (itunes, spotify, etc). However I went throught the process of submitting my RSS to on Youtube Studio, was able to verify ownership and the thing started processing…5 days ago. Google “community” (which has been radio silent) is no help. Does anyone have even a theory of how to fix this? Yes, I deleted it and went through the process again. Same situation.
Welcome @TruTheaterRadio !
It’s been over a year since I put my shows into YouTube, but I wrote up all the steps I had to go through. Perhaps this helps you find something to try… Loading podcast shows into YouTube
Thank you, but I have done all of these things. I only have 14 episodes and 5 days seem broken. I just deleted and I’m trying again. If this doesn’t work, no one from youtube, google or otherwise will help?
I would definitely not keep deleting everything and starting over… that’s only going to slow you down in the long run.
I recall it took me weeks to get it all working. Even once they approved my feed, it only imported a few episodes per day as it worked to load my back-catalog. (That won’t be an issue for your smaller number of episodes.)
Do you get to a point where it says “now wait for approval” or something like that? (show us a screenshot)
Hi @TruTheaterRadio …did you get YouTube sorted out? If so, could you recap what finally worked, or . . .
also, where/what is your show? A search for “tru theater radio” on podnews doesn’t show me any matches (in any directories.)
Tru Theater is one word “TruTheater” Its sort of a double entendre.
And no, It has been processing for 18 days now and still processing. The only reason I can think of is because I am self hosting from pcloud public folder. All other platforms seem to have no issues. Does YT need some extra line of code or something?
ah, now I see it. I put your RSS feed into Cast Feed Validator — I don’t agree with all of the nits it likes to pick, but it did make a point about caching headers. Here’s a link over to CFV that will kick off a fresh test.
I would say, strictly speaking, one does not need to be providing a caching header. Just feed a valid file (as you are). However, I wouldn’t put it past Google/YouTube to ‘require’ it for them to begin regularly polling your feed. They need to periodically do a HEAD request. That said…
Yours does look to my eyes like the caching (“Expires:” header) is right…
Craigs-iMac211:~ craig$ curl -I https://filedn.com/lmon024IRoRuy3dTE9iFItm/TTR_Feed/Feed/feed.xml
HTTP/1.1 200 OK
Server: CacheHTTPd v1.0
Date: Mon, 07 Apr 2025 20:15:12 +0000
Content-Type: application/xml
Content-Length: 28937
Etag: "d1f44022a141569b333dd3df36ff354f74ff3668"
Expires: Tue, 08 Apr 2025 02:15:09 +0000
Accept-Ranges: bytes
Content-Transfer-Encoding: binary
Connection: keep-alive
Keep-Alive: timeout=30
As a comparison (for whatever it might be worth), here’s the HEAD response for Podtalk. This has a Content-type of text/xml , rather than applicadtion/xml … maybe Google/YT is picky about that?
Craigs-iMac211:~ craig$ curl -I https://podtalk.show/feed/podcast/podtalk/
HTTP/2 200
link: <https://podtalk.show/wp-json/>; rel="https://api.w.org/"
last-modified: Mon, 31 Mar 2025 11:32:53 GMT
etag: "328671d25991a56f15ef9fe1a96253ef"
content-type: text/xml; charset=UTF-8
date: Mon, 07 Apr 2025 20:15:54 GMT
server: Apache
ɕ
Thank you for your response. How do I find/change content-type to text/xml from application/xml
The headers within the HTTP response are determined by whatever software is serving that file. Sometimes you can simply get the right behavior by changing the extension on the filename. (In this case from .xml to .rss)
However that would change your feed URL and require a lot of other work. (There’s a tangential discussion possible here about “301” redirections where the old URL, instead of being a “404” not-found, returns a “301” redirection to the new URL — that’s a service of many podcast hosting providers, but is yet another thing one has to handle when one self-hosts.)
Anyway, that Content-type header is set by whatever is serving your file. What is that software?
…and, as you get farther into the weeds here, it becomes clearer why I tell people never host your own RSS feed. If you know enough to do so, you’ll never bump into me and my advice to never host your own RSS feed.
That said, I’m happy to help you keep chipping at this. It’s just going to be a long road (of learning which may be exactly what you’re after.)
ɕ
-
Anyway, that Content-type header is set by whatever is serving your file. What is that software?
Once you asked that I knew that the application vs text was coming by cloud server. So that answers that question and may not be fixable in the current state. If it is I would love to figure it out. If not then the only hiccup I have so far is bloody YT, which is a small inconvenience. -
long road (of learning which may be exactly what you’re after.)
I’ve come this far and I like learning this. no matter how frustrating at times. -
I tell people never host your own RSS feed
My own (and only my own) personal disagreement with this statement has little to do with your very valid reasons I’m sure. My reason for self hosting has really only one real reason. Legacy. Having it hosted isn’t THAT expensive and truly easier. However, the feed is always subject to some kind of hosting overlord. If I stop paying or any number of reasons, the feed is gone. My cloud service is a lifetime subscription and I am aware of the contradictions of it still being a service. However, for the time being it is giving me the ability to still have my show self hosted so I can learn at the same time. Sorry for my rant and it isn’t a disagreement. Its just for me.
Thank you again so much for you time. It really means a lot.
The next thing I’d do would be to try to get some technical details to investigate. Claude had this to say, when I prompted…
I’m trying to add my podcast to YouTube. I’ve submitted my RSS feed url, but YT hasn’t yet approved, nor started importing, my show’s existing episodes. What are the technical, nitty-gritty details, that YT requires of RSS feeds? I mean things like: what (if any) caching headers does it require, what XML entities and/or namespaces must be present, etc.
YouTube has specific technical requirements for podcast RSS feeds to ensure compatibility with their platform. Here are the nitty-gritty details:
## RSS Feed Technical Requirements
### Essential XML Elements and Namespaces
- Valid XML format with proper UTF-8 encoding
- Must include the iTunes namespace: `xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"`
- Standard RSS 2.0 namespace: `xmlns="http://www.w3.org/2005/Atom"`
- Content encoded namespace: `xmlns:content="http://purl.org/rss/1.0/modules/content/"`
### Feed Headers
- YouTube doesn't explicitly require specific caching headers, but standard HTTP caching headers are recommended
- `Cache-Control` with reasonable max-age values (e.g., 3600 seconds)
- `ETag` or `Last-Modified` headers help with efficient polling
### Required Channel Elements
- `<title>` - Your podcast name
- `<description>` - Podcast description
- `<link>` - URL to your podcast website
- `<language>` - Language code (e.g., "en-us")
- `<itunes:image>` - Square artwork (min 1400x1400px, max 3000x3000px, JPG/PNG)
- `<itunes:category>` - At least one category
- `<itunes:explicit>` - "true" or "false"
- `<itunes:author>` - Creator name
### Required Item (Episode) Elements
- `<title>` - Episode title
- `<enclosure url="">` - Direct MP3/audio file URL with size and type attributes
- `<guid>` - Unique identifier for each episode
- `<pubDate>` - RFC 822 formatted date
- `<itunes:duration>` - Episode length in seconds or HH:MM:SS format
- `<description>` or `<content:encoded>` - Episode description
### Media File Requirements
- MP3 format preferred (AAC/M4A also supported)
- Constant bit rate (CBR) recommended at 96-128 kbps
- File size under 200MB
- Audio must be properly formatted without ID3v2 padding issues
### Server Requirements
- HTTPS URLs strongly preferred for all links
- Server must support byte-range requests
- Server should allow HEAD requests
- No redirects for media files (or limited to one redirect)
- Content-Length header must match actual file size
- Content-Type header must correctly identify the media type
YouTube's crawler is particularly sensitive to media file access. If it encounters timeouts, inconsistent responses, or frequent server errors, it may delay or reject the import. Also, the RSS feed should be publicly accessible without authentication.
Is there a particular aspect of your feed that might be causing issues with YouTube's approval process?
I’ve no idea if any of that is true, but it gives lots of ideas of things to check—those “essential” XML namespaces would be the first thing I’d check. Then I’d check those “required” Channel and Item elements.
I note that your server’s response to my HEAD request (show in one of my replies above) includes the Accept-Ranges header—which suggests to me that your server does accept range-requests (which is critical for playback to work.)
Aside: crazy side quest I did related to range-requests: Content-encoding gzip, plus HTTP range requests, equals bad mojo – Craig Constantine
First off, I read your whole article about range requests. My ability with coding could best be described as someone reading a sign in a foreign language and sort of understanding what it is saying because one of the words is in english. I sort of know what it is doing but I don’t know why or how. So reading your article was entertaining enough to keep reading but only because I have a basic understanding of the words “range” and “request” does any of it make sense. All I need to know is that I can take your word for it that my server accepts range-requests and I will keep that in my back pocket to know it is required in the furture.
After lookiing up and down at my xml I came to only two possibilities. 1. One, or more of my mp3s are larger than 128 kbps, which I have just looked at and only TWO are less than 128 kbps and ONE is more that 200mb. The other is the possibility that my url enclosure is being routed with op3.dev/e/ for the purpose of analytics, making the enclosure url not the true and original. I could be (and probably am) wrong. But asside from those two things, everything else looks kosher (at least from my limited perspective)
The YT requirement about 128 is kbps that has to do with the nature and contents of your MP3 files— not their file size.
…but if you have a 200+ MB size file, then you’re not doing the mp3 encoding correctly. Off the top of my head, 30Mb is like 45 minutes of my shows… But that would only (if YT really doesn’t like +200MB size files) prevent that one RSS Item from importing.
That’s definitely not a problem. All four of my shows (which are in YT) all use those same OP3 redirections for analytics.
Does your XML include the namespaces, and all the entities (in channel and Items) that “Claude” mentioned?
Yes, I have all of those. I have ran my xml the w3schools rss validator every time I have added an episode to varify that the xml is a valid rss feed. All of the namespaces are there and every episode has the required elements.
I just found this on https://support.google.com/youtube/answer/12751636?hl=en#zippy=%2Ccreate-a-new-podcast-in-youtube-studio
I don’t know how much this matters or even makes sense. This almost seems like I’m suppost to have a video version of my mp3
My response was kicked back because new users can only post 2 links but I only posted one. However the text I added had embedded hyperlinks so the relevant info is under:
Keep in mind: