分片数 ≥1800 触发 partial merge 会破坏时间轴，合并后时长严重偏短（即使已启用 --use-ffmpeg-concat-demuxer）

Environment

• N_m3u8DL-RE version: Beta 20260628 (0.6.0+df70f0b3)
• ffmpeg: 7.1.2
• System: Linux (Docker container, Debian)

Phenomenon

Downloading an HLS long video (movie/TV recording) with more than 1800 fragments, and the output mp4 file is significantly shorter than the original duration. Test case: A HLS stream for a movie, with a total of 2140 fragments/142.62 minutes.

• The merged file size is 955MB (the data is basically complete)
• However, ffprobe shows the duration ≈ 1983s (about 33 minutes), and DTS has an abnormal value of ~13 hours.
• The log shows "Segments more than 1800, start partial merge…", and there are many "Non-monotonic DTS; previous: 26784000, current: -7200". This means that the data is there, but the timeline is corrupted, not due to missing fragments.

Reproduction conditions

1. Number of fragments ≥ 1800
2. The content has fragment timestamp reset / loop (common in TV recordings and partial on-demand sources, and is shown in the log as "Non-monotonic DTS").
3. Even with --use-ffmpeg-concat-demuxer enabled, it will still trigger (see the root cause below).

Root cause analysis

In src/N_m3u8DL-RE/DownloadManager/SimpleDownloadManager.cs:590:

// If there are more than 1800 fragments, partial merge is required.
if (files.Length >= 1800)
{
    Logger.WarnMarkUp(ResString.partMerge);
    files = MergeUtil.PartialCombineMultipleFiles(files);
    ...
}
The `PartialCombineMultipleFiles` in `src/N_m3u8DL-RE/Util/MergeUtil.cs:88` merges 100 fragments at a time into a large TS intermediate file (T0000.ts…), deleting the original fragments, and then uses ffmpeg to merge these intermediate files. The problem lies in two points:
1. Partial merge will be triggered regardless of whether `--use-ffmpeg-concat-demuxer` is enabled. The concat demuxer itself reads fragment files stream by stream, and does not open a large number of files at once, so partial merge is unnecessary in this mode.
2. When the content has a reset timestamp in the fragments, after merging 100 fragments into a single TS file, ffmpeg reads it as a continuous stream, and cannot handle the timestamp reset within the file, resulting in a distorted timeline and a significantly shorter duration.