- JVM extractor now supports --daemon mode: starts once, processes
multiple archives via stdin JSON protocol, eliminating ~5s JVM boot
per archive
- TypeScript side: daemon manager starts JVM once, sends requests via
stdin, falls back to spawning new process if daemon is busy
- Fix extraction progress caching: replaced Object.create(null) + in
operator with Set<string> + linear Array scan — both Map.has() and
the in operator mysteriously failed to find keys that were just set
- Daemon auto-shutdown on app quit via shutdownDaemon() in before-quit
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Restore all source files from v1.5.49 (proven stable on both servers)
- Add startPackages() IPC method that starts only specified packages
- Fix context menu "Ausgewählte Downloads starten" to use startPackages()
instead of start() which was starting ALL enabled packages
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bring back callback-first RAR multipart opening with explicit RAR5/RAR fallback while keeping 7z.001 on VolumedArchiveInStream to improve 7z-JBinding compatibility on split RAR sets.
- Add automatic retry with 3s delay when JVM extractor fails with
"codecs" or "can't be opened" error during hybrid-extract mode
(handles transient Windows file locks after download completion)
- Log archive file size before JVM extraction in hybrid mode
- Remove unused ArchiveFormat import, RAR_MULTIPART_RE/RAR_OLDSPLIT_RE
patterns, and hasOldStyleRarSplits() method from Java extractor
- Keep simple openSevenZipArchive with currentVolumeName tracking
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two bugs in SevenZipVolumeCallback caused multi-part RAR extraction to fail:
1. getProperty(NAME) always returned firstFileName instead of tracking the
last opened volume name. 7z-JBinding needs this to compute subsequent
volume filenames.
2. The first IInStream was created separately instead of through the
callback's getStream() method, so the volume name tracker was not
properly initialized.
Verified with real multi-part RAR5 test archives (3 parts, WinRAR 7.01).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
VolumedArchiveInStream only works for .7z.001 splits - it rejects RAR
filenames. For multi-part RAR (.partN.rar), use RandomAccessFileInStream
with explicit ArchiveFormat.RAR5/RAR format specification. Auto-detection
with null format can fail for multi-volume RAR archives.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The JVM extractor used RandomAccessFileInStream for multi-part RAR archives,
which only provides a single file stream. 7z-JBinding requires
VolumedArchiveInStream to access additional volume parts via callback.
Added RAR_MULTIPART_RE and RAR_OLDSPLIT_RE patterns to detect multi-volume
RAR archives and route them through VolumedArchiveInStream, fixing
"Archive file can't be opened with any of the registered codecs" errors.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- findReadyArchiveSets: for .part1.rar, require ALL package items
to be terminal before allowing extraction (prevents premature
extraction when later parts have no targetPath/fileName yet)
- JVM extractor: remove CRCERROR from isPasswordFailure() — only
DATAERROR indicates wrong password. CRCERROR on archives where
7z-JBinding falsely reports encrypted no longer triggers password
cycling.
- looksLikeWrongPassword: remove CRC text matching, keep only
explicit "data error" for encrypted archives.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Root cause: SevenZip.initSevenZipFromPlatformJAR() was never called, so
native compression codecs (RAR5, LZMA2, etc.) were not loaded. Archives
could be opened (header parsing is pure Java) but all extractSlow() calls
returned UNSUPPORTEDMETHOD because no native decoder was available.
- Add ensureSevenZipInitialized() with lazy init before extraction
- Pass password to extractSlow(outStream, password) for RAR5 compatibility
- Add UNSUPPORTEDMETHOD -> legacy fallback in extractor.ts as safety net
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- New JVM sidecar (resources/extractor-jvm/) using SevenZipJBinding for
RAR/7z/TAR and Zip4j for ZIP multipart, matching JDownloader 2 stack
- Auto/JVM/Legacy backend modes via RD_EXTRACT_BACKEND env variable
- Fallback to legacy UnRAR/7z when JVM runtime unavailable
- Fix isJvmRuntimeMissingError false positives on valid extraction errors
- Cache JVM layout resolution to avoid repeated filesystem checks
- Route nested ZIP extraction through JVM backend consistently
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
