时间戳

首页 > 解决方案 > 不从文件开头开始的有声读物章节

sonos - 不从文件开头开始的有声读物章节

问题描述

我们已经实现了 SMAPI 服务，并正在尝试提供有声读物。我们可以选择有声读物并开始播放，但是当我们想要在章节之间移动时会遇到问题，因为我们的音频文件没有按章节拆分。每本有声读物都被分成大致相等长度的部分，我们有关于每章从哪一部分开始以及从多远开始的信息。

所以我们遇到了一个问题，我们的getMetadata响应是返回有声读物的章节，因为这是我们希望用户能够浏览这本书的方式，但是我们getMediaURI对每一章的响应是返回部分的 URL音频文件被划分，我们似乎无法从这些文件中的特定位置开始。

我们第一次尝试解决这个问题是positionInformation在我们的getMediaURI回复中加入。这仍然会给我们留下一个问题，即在适当的地方结束一章，但可能会让我们从适当的地方开始。但是根据Sonos 文档，您不应该包含各个有声读物章节的位置信息，而且它似乎被忽略了。

我们的第二个想法，可能是更好的解决方案，是使用响应部分为文件中与章节相对应的部分设置httpHeaders标题。但是 Sonos 似乎在我们设置标题时遇到了问题，并且似乎在我们尝试播放章节时忽略了我们的标题或中断。我们假设这是因为Sonos 正在尝试设置自己的标头。getMediaURIRangeRangeRange

我们目前的想法是，我们可能能够通过某种代理传递媒体 URL，通过Range根据音频文件中章节开始的位置向开始和结束值添加偏移量来调整 Sonos 标头。

所以现在我们返回<fileUrl>，getMediaURISonos 发送如下请求：

<fileUrl>
Range: bytes=100-200

相反，我们<proxyUrl>?url=<urlEncodedFileUrl>&offset=3000将从getMediaURI. Sonos 会发送如下内容：

<proxyUrl>?url=<htmlEncodedFileUrl>&offset=3000
Range: bytes=100-200

代理会重定向到这样的东西：

<fileUrl>
Range: bytes=3100-3200

有没有其他人处理过与其章节不匹配的音频文件？你是怎么处理的？

标签： sonos

解决方案

简单的答案是 Sonos 播放器尊重文件的持续时间，而不是元数据中表达的持续时间。您无法使用positionInformationCloud Queues 解决此问题。

但是，您不应该positonInformation在有声读物中的章节中使用的注释似乎不正确，因此我将其删除。Saving and Resuming 文档指出，如果用户正在恢复收听，您应该将其包括在内。您可以使用它在音频文件中的特定位置开始播放。尝试执行此操作时是否收到错误？

请注意，您将无法在文件中停止播放（例如，如果一章在文件结束之前结束）。播放器会在停止之前播放整个文件。元数据也不会改变，直到文件结束。因此，例如，如果文件的元数据是“第 2 章”并且第 2 章在文件结束之前结束，Sonos 应用程序仍将显示“第 2 章”直到文件结束。

另请注意，报告 API 已被弃用。有关您的服务应托管的新报告端点，请参阅添加报告。

推荐阅读