乐之邦 Monitor 09 Mark III 固件缺陷反馈
发表于 : 27 5月 2026, 10:31
您好：
因为再实际使用中出现播放器多翻页后，播放器卡死的问题，下载了相应固件，使用claude code(deep seek V4 PRO模型)帮助解决现有问题，因没有相应源码、编译工具，无法自行修复，只能将现有分析发出，还请帮助看是否能够解决。感谢！
设备型号：Monitor 09 Mark III
固件版本：MOS 20220101 / TFP 20220201
TF 卡：128GB exFAT，945 首 WAV 文件（文件名仅含中文/英文/数字/空格，无特殊字符）
Bug 1：曲目索引数组固定上限，溢出后崩溃（主因）
症状：945 首放在 music 根目录，可浏览约 10+ 页（约 100~150 首），之后播放器完全卡死，无法继续翻页或播放。文件名显示出现乱码/异常。但曲目数控制在 10 首时完全正常。
代码层推断：
固件中极有可能定义了固定大小的曲目信息数组：
#define MAX_TRACKS 256 // 或 128、512 之类
TrackInfo g_track_list[MAX_TRACKS];
当扫描到的曲目数超过 MAX_TRACKS 时，代码继续向数组写入，导致栈/堆越界，覆盖了相邻内存区域（可能是显示缓冲区、DMA 配置等），表现为文件名乱码、界面卡死。
证据：
固件是裸机/RTOS 程序（90KB 的 .bin），没有操作系统级的内存保护
固件字符串中未找到任何与文件数上限相关的配置项或错误提示，说明开发者未做边界检查
"翻到一定页数才卡死"符合数组越界的典型特征 —— 不是立即崩，而是踩到关键内存后才崩
Bug 2：非递归扫描，遇子目录未做类型判断（次要）
症状：在 music/ 下创建子文件夹 01/ 后，播放器进入目录搜索即立即卡死，文件名显示异常。
代码层推断：
固件扫描 music 时，对每个目录项的处理逻辑如下（推测）：
// 伪代码：当前可能的实现
while (read_dir(&entry) == OK) {
if (entry.is_file && is_audio(entry.name)) {
add_track(entry.name); // 只处理文件，但遇到目录时可能走了意外路径
}
// BUG: 缺少 else if (entry.is_dir) { skip; }
}
当遇到子目录 01/ 时，固件要么把它当作音频文件尝试解析（导致元数据解析异常），要么进入子目录后不受控地递归扫描。无论哪种，都因为没有正确处理目录类型而崩溃。
证据：
固件字符串中没有任何与子目录/文件夹导航相关的 UI 字符串（如 "Folder"、"Open" 等），说明开发者从未设计子文件夹功能
同级并行文件夹 music1/ 完全被忽略，进一步确认固件只扫描固定的顶层 music 路径
Bug 3：长文件名缓冲区溢出风险
症状：部分曲目文件名超过 60 字符（最长 94 字符），在某些浏览操作下可能导致显示缓冲区溢出。
代码层推断：
固件字符串中包含 printf_s: bad %s argument 错误信息，这是 C 标准库的安全函数报错，说明代码中使用了 printf_s 族函数。如果某处用固定长度缓冲区格式化长文件名：
char display_buf[32]; // 或 64
sprintf(display_buf, "%s", track_name); // 94 字符的文件名直接溢出
会导致显示区内存被破坏，进一步诱发界面异常或卡死。
Bug 4：无内存不足/溢出时的降级处理
症状：所有异常场景（文件过多、子文件夹、字符异常）最终表现都是直接卡死，而非弹出错误提示（如 "too many files" 或 "unsupported"）。
代码层推断：
固件中没有任何防护性检查：
没有 if (track_count >= MAX_TRACKS) break;
没有 if (dir_entry is directory) continue;
没有异常捕获或看门狗超时保护
这说明固件是在**"理想条件"（几十首曲目、无子目录、短文件名）下开发和测试的**，没有做过压力测试。
总结
Bug 严重度 疑似根因
#1 曲目数超限崩溃 致命 固定数组 MAX_TRACKS 未做边界检查
#2 子目录崩溃 高 目录遍历未过滤 is_dir 类型
#3 长文件名风险 中 显示缓冲区可能不足 32/64 字节
#4 无降级处理 中 缺少异常分支和用户提示
向厂家反馈建议
请确认 TAP_LIST1.MUS 播放列表的最大条目数是多少
请求出新固件解决该问题
请求下一版固件增加曲目数上限检测（超出时给出提示而不是崩溃）
请求增加子目录跳过/导航支持
请求说明 Monitor 09 Mark III 实际支持的 TF 卡容量上限和曲目数上限（目前说明书未标注）
因为再实际使用中出现播放器多翻页后，播放器卡死的问题，下载了相应固件，使用claude code(deep seek V4 PRO模型)帮助解决现有问题，因没有相应源码、编译工具，无法自行修复，只能将现有分析发出，还请帮助看是否能够解决。感谢！
设备型号：Monitor 09 Mark III
固件版本：MOS 20220101 / TFP 20220201
TF 卡：128GB exFAT，945 首 WAV 文件（文件名仅含中文/英文/数字/空格，无特殊字符）
Bug 1：曲目索引数组固定上限，溢出后崩溃（主因）
症状：945 首放在 music 根目录，可浏览约 10+ 页（约 100~150 首），之后播放器完全卡死，无法继续翻页或播放。文件名显示出现乱码/异常。但曲目数控制在 10 首时完全正常。
代码层推断：
固件中极有可能定义了固定大小的曲目信息数组：
#define MAX_TRACKS 256 // 或 128、512 之类
TrackInfo g_track_list[MAX_TRACKS];
当扫描到的曲目数超过 MAX_TRACKS 时，代码继续向数组写入，导致栈/堆越界，覆盖了相邻内存区域（可能是显示缓冲区、DMA 配置等），表现为文件名乱码、界面卡死。
证据：
固件是裸机/RTOS 程序（90KB 的 .bin），没有操作系统级的内存保护
固件字符串中未找到任何与文件数上限相关的配置项或错误提示，说明开发者未做边界检查
"翻到一定页数才卡死"符合数组越界的典型特征 —— 不是立即崩，而是踩到关键内存后才崩
Bug 2：非递归扫描，遇子目录未做类型判断（次要）
症状：在 music/ 下创建子文件夹 01/ 后，播放器进入目录搜索即立即卡死，文件名显示异常。
代码层推断：
固件扫描 music 时，对每个目录项的处理逻辑如下（推测）：
// 伪代码：当前可能的实现
while (read_dir(&entry) == OK) {
if (entry.is_file && is_audio(entry.name)) {
add_track(entry.name); // 只处理文件，但遇到目录时可能走了意外路径
}
// BUG: 缺少 else if (entry.is_dir) { skip; }
}
当遇到子目录 01/ 时，固件要么把它当作音频文件尝试解析（导致元数据解析异常），要么进入子目录后不受控地递归扫描。无论哪种，都因为没有正确处理目录类型而崩溃。
证据：
固件字符串中没有任何与子目录/文件夹导航相关的 UI 字符串（如 "Folder"、"Open" 等），说明开发者从未设计子文件夹功能
同级并行文件夹 music1/ 完全被忽略，进一步确认固件只扫描固定的顶层 music 路径
Bug 3：长文件名缓冲区溢出风险
症状：部分曲目文件名超过 60 字符（最长 94 字符），在某些浏览操作下可能导致显示缓冲区溢出。
代码层推断：
固件字符串中包含 printf_s: bad %s argument 错误信息，这是 C 标准库的安全函数报错，说明代码中使用了 printf_s 族函数。如果某处用固定长度缓冲区格式化长文件名：
char display_buf[32]; // 或 64
sprintf(display_buf, "%s", track_name); // 94 字符的文件名直接溢出
会导致显示区内存被破坏，进一步诱发界面异常或卡死。
Bug 4：无内存不足/溢出时的降级处理
症状：所有异常场景（文件过多、子文件夹、字符异常）最终表现都是直接卡死，而非弹出错误提示（如 "too many files" 或 "unsupported"）。
代码层推断：
固件中没有任何防护性检查：
没有 if (track_count >= MAX_TRACKS) break;
没有 if (dir_entry is directory) continue;
没有异常捕获或看门狗超时保护
这说明固件是在**"理想条件"（几十首曲目、无子目录、短文件名）下开发和测试的**，没有做过压力测试。
总结
Bug 严重度 疑似根因
#1 曲目数超限崩溃 致命 固定数组 MAX_TRACKS 未做边界检查
#2 子目录崩溃 高 目录遍历未过滤 is_dir 类型
#3 长文件名风险 中 显示缓冲区可能不足 32/64 字节
#4 无降级处理 中 缺少异常分支和用户提示
向厂家反馈建议
请确认 TAP_LIST1.MUS 播放列表的最大条目数是多少
请求出新固件解决该问题
请求下一版固件增加曲目数上限检测（超出时给出提示而不是崩溃）
请求增加子目录跳过/导航支持
请求说明 Monitor 09 Mark III 实际支持的 TF 卡容量上限和曲目数上限（目前说明书未标注）