Web.archive audio playlists now have display error

On earlier versions of Discourse, archive.org playlists used to display like this

now however, pasting in that same link results in this, where you can only play the first file through a generic audio player.

Not certain if this is a bug or just an unfortunate result of a larger change to how audio files are displayed, so I’ve just put it under the “ux” category to be safe.

Also, the previous version where they displayed correctly was 2.4.0.beta8 (was on a hosted solution)


This may be due to the new onebox allowed iframe domains setting.

1 Like

I tried editing this, but it simply said that "You specified the invalid choice archive.org" (also tried it with http:// and https:// beforehand), so I left it at the default *.

I’m really stumped as to what could be making it display like this. It’s like it’s something that searches pages for playable files, then it sticks them into the display that it thinks would fit best, but it’s obviously not a perfectly one-size-fits-all situation, as it fails to take playlists into account.

Have tried taking away the default “*” and leaving it blank. Same result, sadly.

I think this arises because archive.org always starts you off with the first song of the playlist highlighted.

I thought this was by design :o Thanks for bringing it up @b481. I’m also interested in getting that nice one box with the full playlist.


I think it is by design, as part of a wider thing where it scours webpages for playable files to embed in native players, whether they be video or audio, but a one size fits all approach isn’t optimal IMO, especially for sites like archive, which my site users use and love a lot, and they’re pretty bummed about this change. I wish there was an option in settings where you could either opt out of it entirely or even better exempt/blacklist certain sites from being this process and revert to their former way of embedding.

On a new installation, I am seeing a Cross-Origin error when the media player tries to read the data for a single Archive.org link:

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://archive.org/details/jrad2016-03-24.jrad2016-03-24/08+In+Memory+of+Elizabeth+Reed.mp3 with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.
fetch @ fetchWrapper.mjs:111
async function (async)
fetch @ fetchWrapper.mjs:41
q @ NetworkFirst.mjs:219
makeRequest @ NetworkFirst.mjs:142
handle @ NetworkFirst.mjs:95
handleRequest @ Router.mjs:213
(anonymous) @ Router.mjs:58

live example here: Adding media to a post - #2 by ufo_joe - Site Feedback - The Lot

1 Like

https://archive.org/details/.../...Reed.mp3 with MIME type text/html

The browser is functioning correctly here - the returned data is a webpage, NOT an audio file. The onebox code needs to be corrected to treat it as an OpenGraph/OEmbed page instead of an audio file direct link.

The direct audio link is https://archive.org/download/jrad2016-03-24.jrad2016-03-24/08%20In%20Memory%20of%20Elizabeth%20Reed.mp3, which can be found under “Files > Show All”: jrad2016-03-24.jrad2016-03-24 directory listing