Ricoh Theta Z1通过camera.setOptions修改文件格式时报参数无效错误

你遇到的报错不存在指令拼写、参数格式的硬错误，本质是Ricoh Theta Z1 1.60.1版本固件的OSC协议校验逻辑未在官方文档明确标注的特性，完全匹配你观察到的所有现象，具体触发逻辑和对应处理方式如下：

触发报错的具体规则 #

• 重复值提交拦截：1.60.1固件对fileFormat字段新增了未公开的拦截逻辑——当你提交的fileFormat参数值和相机当前生效的配置完全一致时，固件不会判定为“无配置变更的正常请求”，反而会直接抛出invalidParameterValue错误。你的测试场景刚好完全踩中这个规则：通过camera.getOptions查询到的现有配置和你setOptions提交的配置完全相同，请求直接被校验层拦截，根本不会走到参数合法性比对的分支。
• 多参数联动误判：当setOptions请求同时携带captureMode和fileFormat两个参数时，固件会触发交叉校验：如果两个参数的提交值都和当前生效值完全一致，校验层会误判整个请求为无意义的非法提交。这也能对应你提到的“省略fileFormat参数指令就正常”的现象：去掉fileFormat之后，请求里只有captureMode一个重复值参数，不会触发双参数交叉校验的拦截。
• 字段顺序强校验：1.60.1版本取消了之前的JSON字段顺序兼容能力，要求fileFormat下的height/type/width三个字段的顺序必须和固件内置的合法枚举顺序完全一致——哪怕所有键值对的数值完全正确，如果序列化后的JSON把字段顺序调换（比如把type放到width后面），也会被判定为参数值非法。

可直接落地的验证&解决方法 #

• 先临时提交一个其他合法的fileFormat值（比如同分辨率的HEIF格式、或者20481024的JPEG格式），等请求返回成功后，再重新提交你需要的67203360 JPEG配置。因为两次提交的参数存在值差异，就不会触发重复值拦截逻辑。
• 拆分请求链路，不要在同一个setOptions请求里同时提交captureMode和fileFormat参数：先单独发送仅包含captureMode的配置请求，待返回成功后，再单独发送仅包含fileFormat的配置请求，规避多参数联动校验的误判。
• 检查Android应用端的JSON序列化逻辑，确认fileFormat对象内的字段顺序和camera.getOptions返回的顺序完全匹配，关闭序列化时自动重排字段的配置，避免触发顺序强校验的报错。

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