pdfminer 过滤损坏 PDF 文件后再 batch_do_parse 批量推理，运行中断报错 pymupdf.mupdf.FzErrorFormat: code=7: cannot parse object (103 0 R)

[Yiminger]

🔎 Search before asking | 提交之前请先搜索

• [x] I have searched the MinerU Readme and found no similar bug report.
• [x] I have searched the MinerU Issues and found no similar bug report.
• [x] I have searched the MinerU Discussions and found no similar bug report.

Description of the bug | 错误描述

batch_do_parse 批量推理因损坏的 PDF 文件运行中断，尽管添加了PDF文件是否损坏的检查代码和使用try-catch包围

批量预测代码（已经尝试使用pdfminer过滤损坏文件：

程序被迫中断，错误输出日志：

How to reproduce the bug | 如何复现

如上代码

Operating System Mode | 操作系统类型

Linux

Operating System Version| 操作系统版本

Ubuntu 20.04.2 LTS

Python version | Python 版本

3.10

Software version | 软件版本 (magic-pdf --version)

1.3.x

Device mode | 设备模式

cuda

[myhloli]

可以尝试将pdf文件分组20~50个一组，批量推理失败则failback回遍历推理该组

[Yiminger]

可以尝试将pdf文件分组20~50个一组，批量推理失败则failback回遍历推理该组

我看了MinerU的报告，其中提到使用了PyMuPDF过滤了不可处理的PDF文件，我也尝试添加了PyMuPDF的过滤代码，但batch推理的时候还是会出错，导致浪费了已经批次推理的时间，只能重新回退遍历推理该组

能不能批次推理前，就提前过滤一遍呢？请问官方相关的过滤实现在哪部分代码里呢？

[myhloli]

所有pdf文件输入时会有前置的修复处理，能够修复绝大部分损坏的文档，经过修复处理后依然有问题的文档在常见场景下应少于万分之一，在20～50的批大小下，遇到错误组的概率在0.2%～0.5%左右，如果你经常遇到解析错误的情况，可以不使用批处理功能，直接遍历文档并解析。