[Bug] Audiobook Streaming Delay (`audioBook.lcpl`) – Chunks Fully Buffered Before Playback Starts

[mohamedAlhadadi]

Describe the bug

Hello Readium team,

First of all, thank you for the recent update enabling progressive streaming for LCP-protected audiobooks — it’s a highly valuable addition, and we appreciate the continued effort.

However, while implementing this feature in our iOS app using the swift-toolkit, we encountered a couple of issues that are affecting the user experience:

1. Delayed Playback with Large Audiobooks

We've noticed that even though the content is streamed in chunks (each of 6MB), the audio does not begin playing until all chunks have been fully downloaded into the buffer.
This behavior is particularly noticeable with large audiobooks that have a single-chapter structure, where the full download can take a significant amount of time, causing a delay before playback begins.

We were expecting playback to start after the first chunk or two becomes available, with the remaining chunks being fetched progressively as needed during playback, rather than all at once upfront.
However, it seems that BufferingResource waits for the entire file to be fully buffered before playback begins.

---

2. Playback State During Buffering

During this initial buffering period, the playback model returns .playing even though the audio hasn’t started yet.
Ideally, we’d expect a .loading or .buffering state so we can show a loading indicator or spinner to inform the user that playback is still being prepared.

---

❓ Questions:

• Is this buffering behavior expected in the current implementation?
• Is there any internal flag or value that we can use to detect when the audio is still buffering, even if model.playback.state == .playing?
• Are there any recommended practices to improve the responsiveness of playback and the user feedback during this buffering stage?

Please don't hesitate to ask if you need any additional information to help reproduce or better understand the issue — I’d be happy to provide whatever is needed.

Best regards

How to reproduce?

1. Open the test app with a .lcpl audiobook file that:

• Is LCP-protected
• Has a large file size
• Has a single chapter

Readium version

3.2.0

OS version

17.2

Testing device

iPhone 15 Pro

[mickael-menu]

Is this buffering behavior expected in the current implementation?

Maybe? I agree that is less than ideal and I spent some time investigating this issue without success for now.

We are using the native AVPlayer with a custom AVAssetResourceLoaderDelegate. What I observed is that most of the time, and despite declaring support for byte range requests, the resource loader will request the full length of the resource and will start the playback only when everything is loaded.

From what I gathered, it's could be caused by the length of the resource being under a certain length threshold, and caused by the file format of the resource. As it's closed source and the documentation is sparse, I don't have definite answers.

Maybe there's a solution or at least a workaround. If you want to take a stab at it, the relevant implementation is here:

swift-toolkit/Sources/Navigator/Audiobook/PublicationMediaLoader.swift

Line 111 in 55e52e7

// MARK: - AVAssetResourceLoaderDelegate

And here are some additional resources that could be useful:

• https://jaredsinclair.com/2016/09/03/implementing-avassetresourceload.html
• https://developer.apple.com/forums/thread/125943
• https://developer.apple.com/forums/thread/110703

Is there any internal flag or value that we can use to detect when the audio is still buffering, even if model.playback.state == .playing?

Not that I know of, but I didn't touch this code for a while. Here again we are relying on AVPlayer and are directly reporting its internal status:

swift-toolkit/Sources/Navigator/Audiobook/AudioNavigator.swift

Lines 516 to 529 in 55e52e7

	private extension MediaPlaybackState {
	init(_ timeControlStatus: AVPlayer.TimeControlStatus) {
	switch timeControlStatus {
	case .paused:
	self = .paused
	case .waitingToPlayAtSpecifiedRate:
	self = .loading
	case .playing:
	self = .playing
	@unknown default:
	self = .loading
	}
	}
	}

Theoretically we should be in the state waitingToPlayAtSpecifiedRate. Maybe there's an event that we don't observe and that is missing, or an issue in AVPlayer itself. I guess we could also be smarter and check for the playback rate. It think it should be 0 when it's not really playing.

If you would like to give this a try, it would greatly be appreciated! Please feel free to discuss anything here if you need help.