Open JoeGermuska opened 8 years ago
More information:
I have noticed that sometimes individual SoundCite buttons timeout if the audio hasn't been previously played. When the page loads, the buttons also load on the page. I can hear the audio if I click on a SoundCite button once the page loads. However, if I let the page sit there for a few minutes (I tried 5 minutes) and then I come back to play the audio from some of the SoundCite buttons, I find that only some SoundCite buttons play audio. The only buttons that end up playing audio are buttons that I've previously clicked on once the page loaded. In order to get the button to play the audio, the user needs to refresh the page and click on the button again.
I am able to reproduce this problem. Clips do consistently timeout. I do not know the exact time, but a 5 minute wait after page load consistently produces a 403 on attempt to play a clip.
I have spent some time trying to figure out how to catch this exception, but still don't have it. Given upcoming changes (updating styles to OrangeLine, updating build process, etc) I recommend that we also consider updating the code to use SoundCloud's sdk v. 3, as we are currently using a deprecated and undocumented version of the sdk. Version 3 includes an error event that might (I'm not sure) give us a handle for dealing with this problem. Another consideration during these changes might be to make the clips load in dynamically rather than binding all of the behavior on page load.
An organization implementing an article with Soundcloud based clips has reported that the clips are unplayable after "perhaps five minutes".
The dev console shows something like this
The
403
and the long request parameter make me hypothesize that SoundCloud is now timing out URLs. It should be pretty easy to make a test page and verify that SoundCloud clips time out after a period of time.The immediate workaround would be to serve MP3s from a regular web server. Maybe we can recognize this
403
error and request a new clip from Soundcloud?