RSS feed always uses video/mpeg, even for MP3s

[John Veness]

I use mythexport to export radio programs (broadcast on DVB-T - Freeview in the UK). I use the MP3 config downloadable from http://www.baablogic.net/mythexport/ . The files themselves export fine into my mythexport folder.

However, the RSS feeds that are generated mark each entry as MIME type video/mpeg, whereas for MP3s they should be type audio/mpeg. This appears to be hard-wired into the mythexportRSS.cgi file. For at least one podcatcher software (podkicker on Android), this can cause the podcatcher to attempt to play back the file with a video-player rather than an audio-player, causing undesired results.

As an quick fix for myself (which only works because at the moment I am only exporting radio programs) I have changed mythexportRSS.cgi to mark all entries as audio/mpeg, and they now play fine in podkicker. Of course, a better fix would be to autodetect the correct MIME type depending on the individual file, and put that MIME type in the RSS feed, but I don't know how to do that.

[John Veness (pelago)]

Having looked at the code some, I can think of a couple of ways to handle this. The first would be to add an attribute (sorry if that isn't the correct perl terminology) like the existing "extension" one to the config .pm files. It could be called mimetype, and could default to "video/mpeg" in the base config, and be overridden to "audio/mpeg" in MP3.pm or similar.

This value could be read by mythexport-daemon, and stored in the mythexport database table next to the other recording details, read later by mythexportRSS.cgi, and output to the RSS feed in the appropriate place. I do realise the would be changing the schema of the table, which can be awkward. As old rows in the table would have this column NULL, mythexportRSS.cgi could default to video/mpeg in such cases.

If changing the schema is undesired, I assume it is possible to look up, at runtime in mythexportRSS.cgi, a suitable MIME type from a file extension from somewhere.