Audio playback fails due to incorrect request headers

[Wijnants]

Bug Description

When loading a valid IIIF Presentation 3 manifest that contains an audio file (type: "Sound"), the Clover viewer fails to play the audio. No sound is produced and no errors appear in the browser console. The same manifest and audio file work perfectly in other viewers like Mirador.

A key symptom is that the network request for the .mp3 file is not reliably initiated. On the first load, the request is often missing entirely from the Developer Tools' "Network" tab. Only after reloading the page 2-3 times does the request for the media file appear. This intermittent behavior strongly suggests a race condition or timing issue within the viewer's code.

Steps to Reproduce

1. Go to the Clover demo page: https://samvera-labs.github.io/clover-iiif/docs/viewer/demo

2. Load the following IIIF Manifest URL:
   https://vetmediathek.vetmeduni.ac.at/api/v1/objects/uuid/568a9701-0d4a-4ed7-8ae6-1e9c4fe944ec/format/iiif/v3/manifest.json

3. Observe that the audio does not play.

4. Open the browser's Developer Tools and check the "Network" tab. You may need to reload the page multiple times for the .mp3 request to appear.

Analysis & Evidence

The IIIF manifest is valid and the server is configured correctly (it supports HTTP Range Requests with a 206 Partial Content response). The problem lies within the Clover viewer's logic.

1. Race Condition: The inconsistent firing of the network request for the audio file points to a client-side timing issue. It seems the logic to initiate the audio fetch is not synchronized correctly with the component's lifecycle.

2. Incorrect Request Headers: When the request for the MP3 file is successfully made, the request headers initiated by Clover are incorrect:

• Sec-Fetch-Mode: no-cors: This is the critical error. A no-cors request prevents the player's JavaScript from accessing the response data, making playback impossible even after a successful download.

• Sec-Fetch-Dest: video: The request's destination is incorrectly flagged as video instead of audio.

Conclusion

The evidence suggests two distinct bugs in how Clover handles audio content: a race condition that prevents the media request from being made reliably, and the use of incorrect fetch headers(no-cors) that prevents playback even when the request succeeds.

The fetch request should be made reliably with mode: 'cors' to allow the player to access the audio data.

[Wijnants]

Update with further findings:

To isolate the issue, I tested the official IIIF Cookbook audio recipe in the Clover demo viewer:

Manifest: https://iiif.io/api/cookbook/recipe/0002-mvm-audio/manifest.json

Test Link: https://samvera-labs.github.io/clover-iiif/docs/viewer/demo/?iiif-content=https://iiif.io/api/cookbook/recipe/0002-mvm-audio/manifest.json

Result: The viewer exhibits the exact same behavior. The UI loads, the timeline and play/pause buttons work, but no sound is produced.

Conclusion:
This proves that the issue is not specific to our server configuration or manifests. It appears to be a general bug in Clover's audio playback engine, as even the most basic IIIF Cookbook examples are currently not working.