I know. Why. Well, because I am Borg. Probably Azure Blob Storage would be the better Microsoft centric storage solution for 100K, 80 minute, MP3s. I first went down the path of using the OneDrive API to create sharing links I would feed to a html audio tag. That worked for a couple years. CoPilot still thinks this is an option based on the web noise discussing this solution. However, it stopped working a few months ago and now that sharing link will load a JavaScript player. It doesn't matter what you do to adjust the URL. I was able to assign the sharing links to the src of an iframe. It gave me no control over the player but otherwise it appeared to work. After a while I noticed a consistent failure around an hour; I thought the player was just being overly conservative with the buffer. I noticed in the Graph documentation that the DriveItem has a property downloadUrl:
https://learn.microsoft.com/en-us/graph/api/resources/driveitem?view=graph-rest-1.0
The @microsoft.graph.downloadUrl value is a short-lived URL and can't be cached.
The URL is invalidated after for a short period of time (1 hour).
Removing file permissions for a user might not immediately invalidate the URL.
This is an Instance Annotation, whatever that means. What is obvious to me now is that the OneDrive JavaScript Player uses this expiring resource. Similarly, the DownloadUrl fed to an audio tag will die after around an hour of playback. Download and cache would be the obvious solution. I went fancy. I created a proxy that forwards the audio player Range header requests to the DownloadUrl. But every 30 minutes, I request a new Drive item, and it has a new DownloadUrl. No use of local storage on the server but I am not sure what high traffic would do to the server doing the proxy. What can I tell you bro, it just works.