Closed andreasgangso closed 7 months ago
I reproduced it now with the steps above and it tried to load a track with &Expires=1692624483
(13:28 UTC, i.e. it expired almost an hour ago)
This will be handled by #153. I just removed the mentioning of electron in the title. Thanks for reporting, I'll close it as duplicate. Feel free to fix #153.
Sorry, but had to reopen 😅 if this is for playing and continue playing, we'd need to replace the token while continuing to play from the same URI.
Please help us getting a better understanding here: does this apply to continuing content or also playing other content when the website has remained open in the background? Does either one work? I know some systems use aggressive prefetching, where the first would not be testable...
Be aware that these technically are two very different cases, which might not be that apparent for a user 😅
This is for resuming the same content. But this isnt the access token expiring, its the signed file url which expires after a time, so you’d need to fetch a new url from the api or something
@kkuepper would be good to know how this is tackled in the app. The mp3-link in a track is just valid for about 60 minutes...
If I remember correctly, we're watching for errors during playback. If an error happens we reset the player, leading to rebuilding the url with a potentially updated access token.
(Another thing that could cause problems on BMM-Web: When loading the mp3, the first request goes to the Api. The Api then redirects to Cloudfront, with a url that's valid for 60? minutes. If the redirect is cached by the browser that would lead to using an expired link. My guess is that it's not cached, but I wanted to verify.)
Setting https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#preload could help debugging...
@kkuepper this means, this is just for the currently playing track, right? If we rebuild the audio interface on the current position, it should work? I can create a POC on this based on PR #342 I had to this topic.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/error_event I think I have enough info now. I'll create a new PR based on the mentioned one where the audio will rebuild on error. The media should resume on error, right?
The network request for the mp3 failed after trying to resume after leaving the website tab in the background. I forgot to log more details like the access token etc before I closed the tab. If I can make it happen again I'll post more details. Here's all I have. Chromium-based edge on mac.
Repro steps as far as I know:
Error somethingsomething.mp3