Podba.se might be incorrectly reporting itunes:explicit

[Agorise]

Hi @CharlesWiltgen :) Podba.se might be incorrectly reporting itunes:explicit at both the channel and item levels.

See one of our rss feeds: https://cast.garden/feeds/podcast/videos.xml?videoChannelId=37 And as reported though on podba.se: https://podba.se/?url=https://cast.garden/feeds/podcast/videos.xml?videoChannelId=37

[Agorise]

Nevermind, I just realized it is looking for true/false, not yes/no

[CharlesWiltgen]

Hey @Agorise, I really appreciate the report, and I'll enhance the validator to report unexpected values. Thank you!

[Marzal]

Hey @Agorise, I really appreciate the report, and I'll enhance the validator to report unexpected values. Thank you!

Hi, sorry to crash this closed issue, but I've been looking for the repo for podba.se or a contact info.

It his repo a valid place to ask you another "error" validating a feed?

https://podba.se/?url=https://kdeexpress.gitlab.io/feed_mp3

[Agorise]

Also @CharlesWiltgen on the @Marzal Cover Art report on podba.se there is an error on his feed that says:

I for the life of me could not get a 3000x3000 sized image below 944K (I use tinypng.com too). So, you might want to set your error reporting on podba.se to not show that blue error message above unless the image filesize exceeds 1MB.

[CharlesWiltgen]

I for the life of me could not get a 3000x3000 sized image below 944K (I use tinypng.com too).

@Agorise, mind sharing the link so I can see the image?

[Agorise]

Hey @CharlesWiltgen :) Here's a couple of examples. Please use your favorite compression tool to shrink the filesize on these: https://cast.garden/images/t/apple-itunes-images-channel-avatar.png (17.1 MB) https://cast.garden/images/t/apple-itunes-images-channel-avatar.jpg (9.3 MB)

[CharlesWiltgen]

It his repo a valid place to ask you another "error" validating a feed?

Sure, @Marzal! You can also use the chat widget on the validator page to report feed URLs that the validator doesn't handle correctly. That podcast feed has an <item> element without an <enclosure>, which is something I've never seen before (and so have never tested before) in a podcast feed.

Thank you for taking the trouble to report this, and hopefully it will work for you now. Can you please try again?

[CharlesWiltgen]

Here's a couple of examples. Please use your favorite compression tool to shrink the filesize on these:

JPEG is definitely a more appropriate compression scheme for this content unless lossless compression is a must. I dropped the JPEG on ImageOptim and it reduced the size by ~80% to ~1.8 MB without any apparent visual loss. Using squoosh.app, I reduced it to <500 MB pretty easily with minimal fine detail loss.

FWIW, this is a purely informational recommendation. That being said, (1) I'll change the larger icon to match the small ℹ️, and (2) I think it's fine to increase the high end of the recommended maximum size as the resolution increases, and that 1 MB sounds reasonable for 3,000px images. I'll add that to my to-do list, thank you @Agorise!

[Marzal]

It his repo a valid place to ask you another "error" validating a feed?

Sure, @Marzal! You can also use the chat widget on the validator page to report feed URLs that the validator doesn't handle correctly. That podcast feed has an <item> element without an <enclosure>, which is something I've never seen before (and so have never tested before) in a podcast feed.

Thank you for taking the trouble to report this, and hopefully it will work for you now. Can you please try again?

Thanks for the quick update. And also the validator is now more verbose with the errors in https://kdeexpress.gitlab.io/feed, which is the same feed but with ogg files instead of mp3. In this case is in porpuse but verbose is always good 👍

[CharlesWiltgen]

In this case is in porpuse but verbose is always good 👍

Is it useful? I'm wondering if I should special case the situation where every <enclosure> is using an invalid file extension.

Out of curiosity, why not use a universally supported format for the <enclosure> and then use <podcast:alternateEnclosure> for others?

[Marzal]

In this case is in porpuse but verbose is always good +1

Is it useful? I'm wondering if I should special case the situation where every <enclosure> is using an invalid file extension.

I do think that if all the enclosures match the same error it could be summarized

Out of curiosity, why not use a universally supported format for the <enclosure> and then use <podcast:alternateEnclosure> for others?

When the first podcast that uses the "framework" to create the feeds was created, mp3 was not yet a free (in a free software sense) codec/Open format, and this podcast is about Linux and Free Software, so ogg was preferred, also we didn't know about alternateEnclosure or was not yet approved. Some podcasters preferred to use 2 enclosures (against the RSS spec) per episode given that most of the apps fallback to mp3 (the second one) if they don't support ogg. Others just create 2 feeds (one with ogg and one with mp3 for Apple).

<podcast:alternateEnclosure> is not yet enough supported , but I will add it as soon as I have the time as is the correct/canonical way to go.

TL:NR GNU/Linux communities/podcaster are sometimes a bit special/"purist" and it just works most of the time :rofl:

[Marzal]

@CharlesWiltgen also I found why I didn't find the chat widget on the validator, it's blocked by default with uBlock Origin :sweat_smile: