我们已经实现了SMAPI服务，并正在尝试提供有声读物。我们可以选择有声读物并开始播放，但是当我们想在章节之间移动时会遇到问题，因为我们的音频文件没有按章节拆分。每个有声读物都分为大致相等长度的部分，并且我们掌握有关每章开始于哪一部分以及该部分开始多远的信息。
因此，我们遇到了一个问题，我们的getMetadata响应会退还有声读物的章节，因为那是我们希望用户能够浏览这本书的方式，但是我们的{{1} }每章的回复都给出了音频文件所分为的部分的URL，我们似乎无法从这些文件中的特定位置开始。
我们解决此问题的第一个尝试是在我们的getMediaURI回复中加入positionInformation。那仍然会给我们留下在适当的地方结束一章的问题，但可能允许我们从适当的地方开始。但是根据the Sonos docs，您并不是要包含各个有声读物章节的位置信息，而且似乎被忽略了。
我们的第二个想法，可能是一个更好的解决方案，是使用getMediaURI响应的httpHeaders部分为文件的相应部分设置getMediaURI标头本章。但是Sonos似乎对我们设置Range标头存在问题，并且似乎在尝试播放章节时忽略了标头或中断了标题。我们认为这是因为Sonos is trying to set its own Range headers。
我们目前的想法是，我们也许可以通过某种代理来传递媒体URL，并根据章节在开始位置的开始和结束值添加偏移量来调整Sonos Range标头音频文件。
所以现在我们从Range返回<fileUrl>，Sonos发送了这样的请求：
getMediaURI相反，我们将从<fileUrl>
Range: bytes=100-200
返回<proxyUrl>?url=<urlEncodedFileUrl>&offset=3000。 Sonos会发送如下内容：
getMediaURI并且代理将重定向到这样的内容：
<proxyUrl>?url=<htmlEncodedFileUrl>&offset=3000
Range: bytes=100-200
是否还有其他人处理过与章节一一对应的音频文件？您是如何处理的？
答案 0 :(得分：0)
简单的答案是Sonos播放器尊重文件的持续时间，而不是元数据中表示的持续时间。您无法使用positionInformation或Cloud Queue来解决这个问题。
但是，关于有声读物的章节中不应使用positonInformation的注释似乎不正确，因此我将其删除。 Saving and Resuming documentation指出，如果用户正在恢复收听，则应包括它。您可以使用它在音频文件中的特定位置开始播放。尝试执行此操作时收到错误消息了吗？
请注意，您将无法停止文件中的播放（例如，如果章节在文件结束之前结束）。播放器将在停止播放之前播放整个文件。直到文件结尾，元数据也不会更改。因此，例如，如果文件的元数据为“第2章”，而第2章在文件结尾之前结束，则Sonos应用程序仍将显示“第2章”，直到文件结尾。
还请注意，报告API已被弃用。有关您的服务应托管的新报告端点，请参见Add Reporting。