C'est corrigé !Le lien vers la version Apache80 est pas le bon, c'est celui d'Apache.
QNAP [ Radarr ] automatically downloading movies
- Auteur du sujet QoolBox
- Date de début
4.2.4.6635
Changes:
- 8a63f6a Fix TagDetails sql for PG, add test
- 069b18e Fixed: Add YTS.AG to the exception Release Groups (#7627)
- f05333d Fixed: Improve RarBG Error Handling
- b9886cd Fixed: Repack Preference Ignored [ #6595, #7621 ]
- 9f3eecb Fixed: Ignore Movies with null tags when pulling AllMovieTags
- 52c24a4 New: Torrent Seed Ratio no longer advance settings
- 1e1a424 Fixed: Collection Carousel Improvements
- f6dd600 Clarify Folder as Root Folder (#7598)
- 40a15d5 Fixed: Toolbar Button labels overlap [ #7553 ]
- c7baa66 Fixed: Series list jump bar click issues
- 2be70f5 Fixed: Use translated title for sorttitle in Kodi nfo [ #7482 ]
- da85770 Handle redirects for 308 redirects
- 828d7eb Fixed: Improve Radarr List help text
- b3a056e Fixed: Improve Quality Profile in-use helptext
- 98437c3 Bump version to 4.2.4
Subject: RadarrDotNet83 6.4.3.1064 ships FreeBSD binaries — package will not start on QTS
Reporting two separate bugs in RadarrDotNet83, one blocking.
Environment
Bug 1 (blocking): package contains the freebsd-core-x64 artifact instead of linux-core-x64
After updating from 6.2.0.10390 to 6.4.3.1064, App Center reported "Unable to install the package", although the System Event Log recorded a successful install. Starting manually gives:
# /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/RadarrDotNet83.sh start
[RadarrDotNet83] Firmware détecté: 5.2.10
[RadarrDotNet83] Seuil: 5.9.0
[RadarrDotNet83] Exécution: /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/start-Q.sh start
other ELF already added to QPKG
./Radarr: error while loading shared libraries: ./Radarr: ELF file OS ABI invalid
The ELF header shows EI_OSABI = 0x09 (ELFOSABI_FREEBSD):
# hexdump -C -n 8 /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/Radarr/Radarr
00000000 7f 45 4c 46 02 01 01 09 |.ELF....|
glibc's loader only accepts ELFOSABI_SYSV (0x00) or ELFOSABI_GNU (0x03), so it rejects the file.
This affects all 31 native binaries and shared objects in the Radarr/ directory, including the nested Radarr.Update/ tree — Radarr, ffprobe, ServiceInstall, ServiceUninstall, libcoreclr.so, libclrjit.so, libclrgc.so, libhostfxr.so, libhostpolicy.so, libmscordaccore.so, libmscordbi.so, libMonoPosixHelper.so, libSystem.Native.so, libSystem.Globalization.Native.so, libSystem.IO.Compression.Native.so, libSystem.Net.Security.Native.so, libSystem.Security.Cryptography.Native.OpenSsl.so, and their Radarr.Update/ counterparts.
Zeroing the OSABI byte gets past the loader check but reveals the real problem:
./Radarr: error while loading shared libraries: libthr.so.3: cannot open shared object file: No such file or directory
libthr.so.3 is FreeBSD's threading library. These are genuine FreeBSD binaries, not mislabelled Linux ones. Radarr publishes both artifacts with nearly identical filenames, so the build script appears to have fetched:
Radarr.master.<version>.freebsd-core-x64.tar.gz
instead of:
Radarr.master.<version>.linux-core-x64.tar.gz
Size is a quick tell: the FreeBSD tarball is ~70 MB, the Linux one ~105 MB.
Additionally, 6.4.3 is not on Radarr's master branch — the current master release is v6.3.0.10514. The package appears to be built from develop/nightly.
Workaround I used: downloaded Radarr.master.6.3.0.10514.linux-core-x64.tar.gz from GitHub and copied its contents over Radarr/, leaving the elf.tgz-extracted glibc runtime (ld-qnap, ld-linux-x86-64.so.2, libc.so.6) in place. Radarr 6.3.0.10514 then starts normally, migrations run, and the existing database in .config/Radarr is unaffected.
Bug 2 (latent): start-Q.sh guard prevents the bundled runtime from ever being updated
In start-Q.sh:
if ! [ -f $TRGT/libc.so.6 ]; then
echo "extracting new ELF"
tar -xvf $QPKG_ROOT/elf.tgz -C $TRGT
rm -rf $QPKG_ROOT/elf.tgz
...
else
echo "other ELF already added to QPKG"
fi
The guard is a bare existence check with no version comparison, so on any existing install a newer elf.tgz is silently skipped forever. On my system the extracted runtime is dated 2022-11-06 (glibc 2.36) and elf.tgz was still present and unextracted. A version marker or checksum comparison would fix this.
Also worth noting: the bundled glibc 2.36 reports "Minimum supported kernel: 5.10.148", while QTS 5.2.10 ships kernel 5.10.60. Not currently fatal, but a mismatch.
Minor: running the control script from inside the Radarr/ directory breaks it
Both scripts append to LD_LIBRARY_PATH; when the variable is previously unset this produces a trailing colon, which glibc treats as "current directory". Running the script from within Radarr/ then causes /sbin/getcfg and /sbin/setcfg to load the bundled libgcc_s.so.1 against the system libc:
/sbin/getcfg: /lib/libc.so.6: version `GLIBC_2.35' not found (required by libgcc_s.so.1)
RadarrDotNet83 is disabled.
The "is disabled" message is misleading — Enable = TRUE in qpkg.conf; getcfg simply failed. Setting LD_LIBRARY_PATH with a guard against the empty case would avoid this.
Reporting two separate bugs in RadarrDotNet83, one blocking.
Environment
- NAS: QNAP x86_64, QTS 5.2.10.3577
- Kernel: 5.10.60-qnap #1 SMP Fri Jul 31 00:56:10 CST 2026 x86_64
- Package: RadarrDotNet83 6.4.3.1064, Build 20260901, author QoolBox
- Install path: /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83
- Previous working version: 6.2.0.10390
- Dependency: Apache83
Bug 1 (blocking): package contains the freebsd-core-x64 artifact instead of linux-core-x64
After updating from 6.2.0.10390 to 6.4.3.1064, App Center reported "Unable to install the package", although the System Event Log recorded a successful install. Starting manually gives:
# /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/RadarrDotNet83.sh start
[RadarrDotNet83] Firmware détecté: 5.2.10
[RadarrDotNet83] Seuil: 5.9.0
[RadarrDotNet83] Exécution: /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/start-Q.sh start
other ELF already added to QPKG
./Radarr: error while loading shared libraries: ./Radarr: ELF file OS ABI invalid
The ELF header shows EI_OSABI = 0x09 (ELFOSABI_FREEBSD):
# hexdump -C -n 8 /share/CACHEDEV1_DATA/.qpkg/RadarrDotNet83/Radarr/Radarr
00000000 7f 45 4c 46 02 01 01 09 |.ELF....|
glibc's loader only accepts ELFOSABI_SYSV (0x00) or ELFOSABI_GNU (0x03), so it rejects the file.
This affects all 31 native binaries and shared objects in the Radarr/ directory, including the nested Radarr.Update/ tree — Radarr, ffprobe, ServiceInstall, ServiceUninstall, libcoreclr.so, libclrjit.so, libclrgc.so, libhostfxr.so, libhostpolicy.so, libmscordaccore.so, libmscordbi.so, libMonoPosixHelper.so, libSystem.Native.so, libSystem.Globalization.Native.so, libSystem.IO.Compression.Native.so, libSystem.Net.Security.Native.so, libSystem.Security.Cryptography.Native.OpenSsl.so, and their Radarr.Update/ counterparts.
Zeroing the OSABI byte gets past the loader check but reveals the real problem:
./Radarr: error while loading shared libraries: libthr.so.3: cannot open shared object file: No such file or directory
libthr.so.3 is FreeBSD's threading library. These are genuine FreeBSD binaries, not mislabelled Linux ones. Radarr publishes both artifacts with nearly identical filenames, so the build script appears to have fetched:
Radarr.master.<version>.freebsd-core-x64.tar.gz
instead of:
Radarr.master.<version>.linux-core-x64.tar.gz
Size is a quick tell: the FreeBSD tarball is ~70 MB, the Linux one ~105 MB.
Additionally, 6.4.3 is not on Radarr's master branch — the current master release is v6.3.0.10514. The package appears to be built from develop/nightly.
Workaround I used: downloaded Radarr.master.6.3.0.10514.linux-core-x64.tar.gz from GitHub and copied its contents over Radarr/, leaving the elf.tgz-extracted glibc runtime (ld-qnap, ld-linux-x86-64.so.2, libc.so.6) in place. Radarr 6.3.0.10514 then starts normally, migrations run, and the existing database in .config/Radarr is unaffected.
Bug 2 (latent): start-Q.sh guard prevents the bundled runtime from ever being updated
In start-Q.sh:
if ! [ -f $TRGT/libc.so.6 ]; then
echo "extracting new ELF"
tar -xvf $QPKG_ROOT/elf.tgz -C $TRGT
rm -rf $QPKG_ROOT/elf.tgz
...
else
echo "other ELF already added to QPKG"
fi
The guard is a bare existence check with no version comparison, so on any existing install a newer elf.tgz is silently skipped forever. On my system the extracted runtime is dated 2022-11-06 (glibc 2.36) and elf.tgz was still present and unextracted. A version marker or checksum comparison would fix this.
Also worth noting: the bundled glibc 2.36 reports "Minimum supported kernel: 5.10.148", while QTS 5.2.10 ships kernel 5.10.60. Not currently fatal, but a mismatch.
Minor: running the control script from inside the Radarr/ directory breaks it
Both scripts append to LD_LIBRARY_PATH; when the variable is previously unset this produces a trailing colon, which glibc treats as "current directory". Running the script from within Radarr/ then causes /sbin/getcfg and /sbin/setcfg to load the bundled libgcc_s.so.1 against the system libc:
/sbin/getcfg: /lib/libc.so.6: version `GLIBC_2.35' not found (required by libgcc_s.so.1)
RadarrDotNet83 is disabled.
The "is disabled" message is misleading — Enable = TRUE in qpkg.conf; getcfg simply failed. Setting LD_LIBRARY_PATH with a guard against the empty case would avoid this.
This latest version of Radarr 84 broke something in my settings. Where can I download previous versions?