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)
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.
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.
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