Topic: OPML Import Support for Podcasts? (Read 4624 times)

glynor · « **on:** February 27, 2012, 05:43:44 pm »

Is there any way to get MC to import an OPML file so that it can import my list of subscribed podcasts from other applications? I mainly use iCatcher on my phone to listen to and manage my podcasts, so that app is my "canonical list" of the podcasts I use. However, every so often it'd be nice to listen to or watch a podcast episode on my HTPC (I have this situation today), but the list that MC has is always woefully out of date (actually, right now it is blank for this very reason, I just stopped using it entirely).

iCatcher (and iTunes and pretty much any other "podcast catcher" application out there) can export and import a standard OPML file that contains the list of my current subscribed podcasts, along with the played/not-played status of individual episodes. I don't really care about exporting from MC (though that would be nice for other people, I suppose), but I do care about importing FROM my OPML file.

iCatcher is nice and I can easily copy the OPML to my Dropbox, which makes it easily available on all of my machines immediately.

Can I import this into MC somehow? Is MC's podcast.xml file really just an OPML file? If so, then I could just replace it, but I'd guess this is not the case.

If not that, is there some way to get my list of 100-or-so podcasts into MC without manually adding them through MC's UI, and setting manually each one to download episodes the way I want them to (for the vast majority of mine, I don't have it download episodes, they're just there and I stream them if I want them, but for a few that I listen/watch regularly, I have it download those episodes).

Matt · « **Reply #1 on:** February 27, 2012, 09:54:24 pm »

Media Center supports OPML.

You can associate it under Options > File Types.

glynor · « **Reply #2 on:** February 27, 2012, 10:49:08 pm »

Quote from: Matt on February 27, 2012, 09:54:24 pm

Media Center supports OPML.

You can associate it under Options > File Types.

Sweet, thanks!

I'll try it now.

glynor · « **Reply #3 on:** February 27, 2012, 11:00:20 pm »

Hmmm, well, I noticed two things:

1. You MUST do this from Windows Explorer. If, instead, you open the OPML file by going to File -> Open Media File, it gives you an error about playback and installing the proper DirectShow filters. If you drag-drop the file onto MC's title bar and choose Import, it imports the OPML file itself (which shows as an exclamation point icon), but not the podcasts within. To get it to import the OPML contents, you have to actually open the file from Windows Explorer with MC.

FWIW, I looked before I asked, but I was looking for an "Import" button in the Podcast view header, or in the dropdown menus. I would have never thought to do it this way.

2. They imported like this, which makes it of dubious usefulness:

I'm happy to post my test OPML file itself, if it'd help. But, it looks like just a text parsing issue.

Bill Kearney · « **Reply #4 on:** February 28, 2012, 08:56:50 am »

Does your OPML file have the text formatted that way? If so, it's not supposed to.

What program are you using to create these OPML files?

Matt · « **Reply #5 on:** February 28, 2012, 10:27:52 am »

It just looks like it needs to be dehexified.

Please email your OPML file to me. It might be a couple days before I get it fixed.

Bill Kearney · « **Reply #6 on:** February 28, 2012, 11:20:00 am »

The problem is it's likely using HTML character encoding in an improper manner. I'm excruciatingly aware of how XML encoding and feeds are supposed to work as I've been part of that effort since the 90's. It's a bad practice to have a program work around crappy output from another one. Best to see why the other program is getting it wrong. A casual work around here or there isn't a bad thing, but it leads to programs assuming they can "do it wrong" just because program X handles it. That just makes it worse for everyone down the road.

glynor · « **Reply #7 on:** February 28, 2012, 01:16:15 pm »

Because Bill seemed to be interested, I'm posting it here instead of emailing it to Matt:
http://glynor.com/temp/2012.02.27_1802_.Backup-Subscribed.opml.zip

FWIW, this OPML was generated by iCatcher (an iOS app), but the same OPML file works fine (without the %20 thing) in iTunes and a variety of other iOS podcast catchers I've used (including Podcaster, probably the most popular one out there).

Also note, this is a small subset of my total subscribed podcasts list (these are the ones I actually use the most often)... That doesn't much matter, but I figured I'd mention it.

Matt · « **Reply #8 on:** February 28, 2012, 01:23:00 pm »

Interesting.

Why are values in XML attributes being hexified? That's not normal XML escapement. XML uses escapement like: & etc. and spaces in attributes don't need escapement.

Bill Kearney · « **Reply #9 on:** February 28, 2012, 02:53:27 pm »

What itunes and other apple-related products are willing to consume or create carries no guarantee of authentic support of standards. They're among the worst of the bunch when it comes to actually adhering to standards and among the last, if ever, to get around to addressing their glaring bugs. >spit< in the general direction of iTunes... with a private part wave too.

More often that not a program does a 'bad thing' because their developers are either lazy or naive and only test their results against a 'well known' product. Not one that's actually standards compliant. A lot of the time they're willing to adjust their code to fall in line with standards when someone puts forth the effort to ask them about it.

Technically XML only supports 5 character escapes. Any others would have to be numerically noted or in the document's DTD. Using HTML escapes is not valid XML otherwise.

Yes, this is a bit of pedantic nit-picking, but it's crucial for machine-readable content to actually get it right. Otherwise it just leads to compounded errors.

OMFG, that OPML is a mess. Besides any use of the big 5 (>'<"&), there's truly no need at all for them to have encoded the string inside the "text=" element. That's just plain wrong. For a technical explanation, it's because there's nothing in the XML document that defines what those character substitutions are based upon. XML is supposed to be machine readable, and that document gives a machine no way to know the text inside that element might make use of HTML encoding.

So the questions here are a) will the developers of iCatcher make the necessary fixes (if that's actually necessary) and b) will those fixes result in output that continues to work as expected to their customer base? As in, will it not break tools that incorrectly depend upon bad practices.

As for making MC 'work around it'.... DON'T. You wander down a uselessly complex rabbit hole when you start trying to second guess all the half-assed crap some folks try to jam into an XML document. Like the disaster of layered encoding nonsense. Like doing HTML encoding of XML encoding that had HTML encoding in it. Leading to all sorts of nonsense, the likes of which I have grown tired of trying to type... But you've all seen it before, text headlines with &amp and the like. JUST. STOP. IT. by getting products to produce valid content. Working around idiocy never works, as the idiots keep coming up with new ways to do it wrong.

Yes, you could say I have a sore spot for bad document encoding...

glynor · « **Reply #10 on:** February 28, 2012, 03:24:12 pm »

I have to say... I'm much more of a "practicalist". I'd say that in the Real World, the primary use of OPML files, in just about every application that supports them, is to interchange podcast data with iTunes. So, saying that Apple doesn't support the standard properly, is completely irrelevant from an end-user's perspective. Therefore, the "standard" (little "s") is whatever Apple decides to do, and the Standard (big "s") be damned. Facts on the ground and all that.

Now, granted, they didn't define the OPML system. But they also aren't the ones who started using them for exchanging podcast data. That was added well after the practice was implemented by 3rd Parties. So, assuming that iTunes' OPML files are similarly ugly, is probably related to whomever originally did the work, and they were stuck with what had become "common practice" by the time they implemented it.

Now, it could be that just stupid iCatcher's OPML files are ugly. That's possible. In that case, I'd say it isn't worth fixing just for me. That's fine. I did notice before when iTunes imports these OPML files, it actually shows those same %20 characters for a split second, but then it "fixes" them. In any case, it works right. Here's the same feeds exported as an OPML from iTunes:

http://glynor.com/temp/iTunes_Podcasts.opml.zip

In any case, the guy who develops iCatcher (which is a one-man shop, I believe) would probably be open to correcting problems. I've emailed him before and he was helpful and friendly. I'd guess that as long as it doesn't break interchange with iTunes and the other major podcast catchers in the App store (which would defeat the main point of his support for the format) I bet he'd be open to fixing it.

And... As far as this:

Quote from: Bill Kearney on February 28, 2012, 02:53:27 pm

As for making MC 'work around it'.... DON'T.

I mean... Whatever. I understand where you're coming from, but that essentially would say to me: Do not use MC for podcast support because it doesn't interchange with other common applications well. (Again, assuming that iTunes' files are similarly broken, which might not be a good assumption.)

I'm a practicalist.
Obey standards when you can, but don't let it get in the way of your real work, especially when the standards are so loosely followed that you'd be alone in the wilderness.

glynor · « **Reply #11 on:** February 28, 2012, 03:28:34 pm »

I just checked. iTunes' OPML file is not similarly ugly (at least not using the dumb hex encoding). Of course, it also doesn't include the download preferences and "items to keep" preferences.

I wonder if some other application that he gets requests to interchange with all the time requires this? Or maybe his app is just dumb. I don't know. It is, by-far, the best podcast catcher on the App Store (though I'm not 100% sold on it, and I continually try new ones out trying to find the perfect fit).

Matt · « **Reply #12 on:** February 28, 2012, 03:36:08 pm »

Glynor, maybe you could write to the author of iCatcher and let us know what he says? Maybe there's some argument for the hexification.

glynor · « **Reply #13 on:** February 28, 2012, 03:36:56 pm »

Quote from: Matt on February 28, 2012, 03:36:08 pm

Glynor, maybe you could write to the author of iCatcher and let us know what he says? Maybe there's some argument for the hexification.

I actually just sent him a message on Twitter.

I'll let you know if he responds.

Matt · « **Reply #14 on:** February 28, 2012, 03:52:07 pm »

Here's my belief about standards:

When writing, be as mean and strict as possible.

When reading, be as forgiving and tolerant as possible.

glynor · « **Reply #15 on:** February 28, 2012, 04:01:37 pm »

Quote from: Matt on February 28, 2012, 03:52:07 pm

Here's my belief about standards:

When writing, be as mean and strict as possible.

When reading, be as forgiving and tolerant as possible.

Exactly how I'd do it.

Bill Kearney · « **Reply #16 on:** February 28, 2012, 04:29:26 pm »

NO. Being lax about consumption is BAD. You're just encouraging the other developers to keep producing crap. And then when others imitate them, but make more mistakes, you're faced with trying to work around more crap.

More often than not the developers of said 'crap', and I use that term euphemistically, not as a direct insult, are quite willing to address what their product might be doing wrong. Only rarely is there some huge legacy application involved that can't be fixed without a bajillion committee meetings and such. Trust me on this, I've dealt with this for nigh on a decade now with various RSS, RDF and XML applications.

What really helps is discovering a program that uses a popular library for the dirty work. This leads to getting a library fixed and along with it, any descendent apps.

So it's usually worth trying to fix the problems at the source. The end result is everyone else's code can read the results with no extra efforts. Win-win.

glynor · « **Reply #17 on:** March 06, 2012, 06:12:45 pm »

Quote from: Matt on February 28, 2012, 03:36:08 pm

Glynor, maybe you could write to the author of iCatcher and let us know what he says? Maybe there's some argument for the hexification.

I got a response back. This was it (it was on twitter so it was length-limited):

Quote

I should check that. I may not need to do that. Been so long since I coded that part

glynor · « **Reply #18 on:** March 08, 2012, 08:19:27 pm »

He's followed up with me again. Seems like he is going to fix it, so nevermind.

Matt · « **Reply #19 on:** March 08, 2012, 08:24:24 pm »

Thanks for following this through.

Gene, our since retired Podcast-guy, would be happy with the outcome. He likes standards.

I have good memories of arguing with him about whether we should reject podcasts that used dates that didn't strictly conform to the ISO standard. He wanted to make the world a better place. I just wanted the program to work

Bill Kearney · « **Reply #20 on:** March 08, 2012, 09:01:21 pm »

That's excellent news. Sometimes all it takes to fix a problem is to explain it and ask for a fix. That's a lot more effective than wasting energies trying to work around what's know to be broken. Just making it work only prolongs the inevitable hassle of getting it fixed anyway.

INTERACT FORUM

Author Topic: OPML Import Support for Podcasts? (Read 4624 times)