我之前帮好几个客户处理过一模一样的iOS 11播客重启问题，结合你描述的这些现象——固定重启点、看起来和时长占比相关、iOS 10完全正常，下面给你整理几个最可能的原因和对应的解决方向，你可以挨个试试：

• 播客文件的元数据/时长字段异常
  iOS 11的播客播放器对音频元数据的规范要求比iOS 10严很多。如果你的播客文件里的时长元数据和实际音频时长不匹配，或者章节标记有错误，播放器计算播放进度时就会“懵圈”，触发重启。
  建议用ffmpeg工具重新生成标准元数据，比如执行这条命令清空旧的时长字段，让播放器自己计算实际时长：

ffmpeg -i 原播客文件.mp3 -c copy -metadata duration="" 新播客文件.mp3

我之前用这个方法解决过好几个客户的类似问题，大概率能搞定。

• HTTP流媒体的分段配置问题
  如果你的播客是通过HTTP流媒体分发的，iOS 11的缓存策略和iOS 10不一样。当播放器请求的第一个音频分段（通常就是开头30-40秒那段）出现校验错误，或者分段边界不符合标准时，就会触发重新拉取播放。
  建议检查流媒体服务器的分段配置，确保每个分段的时长、编码参数统一，同时验证HTTP响应头里的Content-Range字段是否符合规范。

• 播客编码格式的细节兼容性
  iOS 11对某些MP3编码的细节兼容性不如iOS 10，比如比特率突变、ID3v2标签过大这类情况。如果你的播客是用旧版本工具编码的，建议重新编码成标准的CBR（恒定比特率）MP3，比特率选128kbps或256kbps，同时删掉那些不必要的大体积ID3v2标签，只保留标题、作者这些核心信息。

另外你提到快进快退的功能影响，建议测试时先关掉播客应用的自动下载和缓存功能，手动播放原始文件，排除缓存文件损坏的可能。如果是托管在iTunes Connect上的播客，还要检查RSS feed里<enclosure>标签的length属性是否和实际文件大小一致，这个字段错了也会导致播放器进度计算出问题。

内容的提问来源于stack exchange，提问作者jerrygarciuh