Radarr: update is failing (version `GLIBC_2.27' not found) #8893

Open
opened 2026-02-20 00:08:23 -05:00 by deekerman · 29 comments
Owner

Originally created by @woutercoppens on GitHub (Nov 7, 2024).

Is there an existing issue for this?

  • I have searched the existing open and closed issues

Current Behavior

Launching the update from within Radarr is failing

Expected Behavior

Update should succeed

Steps To Reproduce

Launch update from within Radarr

Environment

- OS: Synololgy DSM 7.1.1-42962 Update 5
- Radarr: 5.14.0.9383
- Docker Install: No

Version 5.11.0.9244
Package Version armv7-7.1_20231118-21 by Team Radarr
.NET Yes (6.0.32)
Database Sqlite 3.34.1
Database Migration 239
AppData Directory /volume1/@appdata/radarr/.config/Radarr
Startup Directory /volume1/@appstore/radarr/share/Radarr/bin
Mode Console

What branch are you running?

Master

Trace Logs? Not Optional

2024-11-07 09:40:50.6|Info|InstallUpdateService|Downloading update 5.14.0.9383
2024-11-07 09:41:02.7|Info|InstallUpdateService|Verifying update package
2024-11-07 09:41:04.3|Info|InstallUpdateService|Update package verified successfully
2024-11-07 09:41:04.3|Info|InstallUpdateService|Extracting Update package
2024-11-07 09:41:37.5|Info|InstallUpdateService|Update package extracted successfully
2024-11-07 09:41:37.6|Info|BackupService|Starting Backup
2024-11-07 09:41:43.1|Info|InstallUpdateService|Preparing client
2024-11-07 09:41:48.4|Info|InstallUpdateService|Starting update client /volume1/@apptemp/radarr/radarr_update/Radarr.Update
2024-11-07 09:41:48.4|Info|InstallUpdateService|Radarr will restart shortly.
2024-11-07 09:41:48.9|Error|Radarr.Update|Failed to load /volume1/@apptemp/radarr/radarr_update/libcoreclr.so, error: /lib/libm.so.6: version `GLIBC_2.27' not found (required by /volume1/@apptemp/radarr/radarr_update/libcoreclr.so)

Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

  • I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.
Originally created by @woutercoppens on GitHub (Nov 7, 2024). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior Launching the update from within Radarr is failing ### Expected Behavior Update should succeed ### Steps To Reproduce Launch update from within Radarr ### Environment ```markdown - OS: Synololgy DSM 7.1.1-42962 Update 5 - Radarr: 5.14.0.9383 - Docker Install: No Version 5.11.0.9244 Package Version armv7-7.1_20231118-21 by Team Radarr .NET Yes (6.0.32) Database Sqlite 3.34.1 Database Migration 239 AppData Directory /volume1/@appdata/radarr/.config/Radarr Startup Directory /volume1/@appstore/radarr/share/Radarr/bin Mode Console ``` ### What branch are you running? Master ### Trace Logs? **Not Optional** 2024-11-07 09:40:50.6|Info|InstallUpdateService|Downloading update 5.14.0.9383 2024-11-07 09:41:02.7|Info|InstallUpdateService|Verifying update package 2024-11-07 09:41:04.3|Info|InstallUpdateService|Update package verified successfully 2024-11-07 09:41:04.3|Info|InstallUpdateService|Extracting Update package 2024-11-07 09:41:37.5|Info|InstallUpdateService|Update package extracted successfully 2024-11-07 09:41:37.6|Info|BackupService|Starting Backup 2024-11-07 09:41:43.1|Info|InstallUpdateService|Preparing client 2024-11-07 09:41:48.4|Info|InstallUpdateService|Starting update client /volume1/@apptemp/radarr/radarr_update/Radarr.Update 2024-11-07 09:41:48.4|Info|InstallUpdateService|Radarr will restart shortly. 2024-11-07 09:41:48.9|Error|Radarr.Update|Failed to load /volume1/@apptemp/radarr/radarr_update/libcoreclr.so, error: /lib/libm.so.6: version `GLIBC_2.27' not found (required by /volume1/@apptemp/radarr/radarr_update/libcoreclr.so) ### Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided. - [X] I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain `trace` - that are relevant and show this issue.
Author
Owner

@github-actions[bot] commented on GitHub (Nov 7, 2024):

👋 @woutercoppens, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please hop over onto our Discord.

@github-actions[bot] commented on GitHub (Nov 7, 2024): :wave: @woutercoppens, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please hop over onto our [Discord](https://radarr.video/discord).
Author
Owner

@mreid-tt commented on GitHub (Nov 8, 2024):

Hi Radarr team,

I believe this may indeed be a bug. After investigating SynoCommunity issue #6309, it appears that the upgrade from Radarr 5.11.0.9244 (which includes .NET 6.0.32) to Radarr 5.14.0.9383 (with .NET 6.0.35) could be causing problems specifically on ARMv7 CPUs. I've tested the upgrade on an x86_64 platform where it runs without any issues, so this may be related to differences in the libraries bundled for ARMv7.

The .NET release notes reference a feedback thread on the version following the last working build (.NET issue #9447), and this comment appears to confirm the issue on ARMv7.

I know Debian 9 (armhf) is not supported anymore, but since version 6.0.33 starting an application results in a segmentation fault.

Failed to load /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/libcoreclr.so, error: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.27' not found (required by /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/libcoreclr.so)
Segmentation fault

I didn't expect breaking changes like these in LTS versions, even if the OS is not supported anymore.

This suggests there may be a breaking change introduced starting from .NET 6.0.33.

@mreid-tt commented on GitHub (Nov 8, 2024): Hi Radarr team, I believe this may indeed be a bug. After investigating [SynoCommunity issue #6309](https://github.com/SynoCommunity/spksrc/issues/6309), it appears that the upgrade from Radarr 5.11.0.9244 (which includes .NET 6.0.32) to Radarr 5.14.0.9383 (with .NET 6.0.35) could be causing problems specifically on ARMv7 CPUs. I've tested the upgrade on an x86_64 platform where it runs without any issues, so this may be related to differences in the libraries bundled for ARMv7. The .NET release notes reference a feedback thread on the version following the last working build ([.NET issue #9447](https://github.com/dotnet/core/issues/9447)), and [this comment](https://github.com/dotnet/core/issues/9447#issuecomment-2299001398) appears to confirm the issue on ARMv7. > I know Debian 9 (armhf) is not supported anymore, but since version 6.0.33 starting an application results in a segmentation fault. > ``` > Failed to load /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/libcoreclr.so, error: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.27' not found (required by /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.33/libcoreclr.so) > Segmentation fault > ``` > I didn't expect breaking changes like these in LTS versions, even if the OS is not supported anymore. This suggests there may be a breaking change introduced starting from .NET 6.0.33.
Author
Owner

@bakerboy448 commented on GitHub (Jan 8, 2025):

Upstream track https://github.com/dotnet/runtime/issues/109739

@bakerboy448 commented on GitHub (Jan 8, 2025): Upstream track https://github.com/dotnet/runtime/issues/109739
Author
Owner

@mreid-tt commented on GitHub (May 1, 2025):

Hey @bakerboy448 — not sure if you might be able to assist here. I’ve been following up on the upstream ticket I opened regarding .NET 6, since it’s now out of support. The maintainers responded with the following:

can you please clarify whether this fails only on .NET 6 and not 7+ ? As mentioned on the download page 6 is out of support since 8 has been out for a while.

Unfortunately, I don’t have an ARMv7 platform to test on, and I’m also unsure whether apps like Radarr are planning to move to newer versions of .NET. If there are any plans—or even early builds—targeting .NET 7 or 8, I’d be happy to try rallying some ARMv7 users to help with testing. Would appreciate your guidance on this.

@mreid-tt commented on GitHub (May 1, 2025): Hey @bakerboy448 — not sure if you might be able to assist here. I’ve been following up on the upstream ticket I opened regarding .NET 6, since it’s now out of support. The maintainers responded with the following: > can you please clarify whether this fails only on .NET 6 and not 7+ ? As mentioned on the download page 6 is out of support since 8 has been out for a while. Unfortunately, I don’t have an ARMv7 platform to test on, and I’m also unsure whether apps like Radarr are planning to move to newer versions of .NET. If there are any plans—or even early builds—targeting .NET 7 or 8, I’d be happy to try rallying some ARMv7 users to help with testing. Would appreciate your guidance on this.
Author
Owner

@bakerboy448 commented on GitHub (May 1, 2025):

The plan is to move to dotnet 8 in the near future. Which I believe also comes with platform support changes. Cc @mynameisbogdan for additional commentary

@bakerboy448 commented on GitHub (May 1, 2025): The plan is to move to dotnet 8 in the near future. Which I believe also comes with platform support changes. Cc @mynameisbogdan for additional commentary
Author
Owner

@mynameisbogdan commented on GitHub (May 1, 2025):

  • Sadly currently there aren't any builds ready for #10258, I'll leave a message when one is ready.
@mynameisbogdan commented on GitHub (May 1, 2025): - Sadly currently there aren't any builds ready for #10258, I'll leave a message when one is ready.
Author
Owner
@mynameisbogdan commented on GitHub (May 10, 2025): Here's a .NET 8 build. https://radarr.servarr.com/v1/update/net80/updatefile?os=linux&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/net80/updatefile?os=linuxmusl&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/net80/updatefile?os=linux&runtime=netcore&arch=arm https://radarr.servarr.com/v1/update/net80/updatefile?os=linux&runtime=netcore&arch=arm64 `docker pull ghcr.io/linuxserver-labs/prarr:radarr-net80`
Author
Owner

@mreid-tt commented on GitHub (May 10, 2025):

@mynameisbogdan, really appreciate this. I've gone ahead and packaged it for Synology as a pre-release. I've deployed on my system as a test and it works well:

Image

Now awaiting the target users on ARMv7 to provide feedback.

@mreid-tt commented on GitHub (May 10, 2025): @mynameisbogdan, really appreciate this. I've gone ahead and packaged it for Synology as a [pre-release](https://github.com/mreid-tt/spksrc/releases/tag/radarr_v6-develop). I've deployed on my system as a test and it works well: <img width="498" alt="Image" src="https://github.com/user-attachments/assets/476321f3-9967-4e48-8eea-b1395d639642" /> Now awaiting the target users on ARMv7 to provide feedback.
Author
Owner
@mynameisbogdan commented on GitHub (May 10, 2025): New links for v6: https://radarr.servarr.com/v1/update/v6-develop/updatefile?os=linux&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/v6-develop/updatefile?os=linuxmusl&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/v6-develop/updatefile?os=linux&runtime=netcore&arch=arm https://radarr.servarr.com/v1/update/v6-develop/updatefile?os=linux&runtime=netcore&arch=arm64 Keep in mind these builds aren't production ready and they might break something at any time.
Author
Owner

@mreid-tt commented on GitHub (May 14, 2025):

Hey @mynameisbogdan, the last test version you provided worked successfully on the Synology ARMv7 platform. This looks like a viable path forward to ensure future updates reach those users.

@mreid-tt commented on GitHub (May 14, 2025): Hey @mynameisbogdan, the last test version you provided worked successfully on the Synology ARMv7 platform. This looks like a viable path forward to ensure future updates reach those users.
Author
Owner

@mreid-tt commented on GitHub (May 14, 2025):

Hey @mynameisbogdan, do you think we can go ahead and close the upstream ticket at this point? The Microsoft team has requested closure.

@mreid-tt commented on GitHub (May 14, 2025): Hey @mynameisbogdan, do you think we can go ahead and close the upstream ticket at this point? The Microsoft team has requested closure.
Author
Owner

@mynameisbogdan commented on GitHub (May 14, 2025):

You can since it's all good on .NET 8, but I'm not seeing a Radarr 6 stable till next year.

@mynameisbogdan commented on GitHub (May 14, 2025): You can since it's all good on .NET 8, but I'm not seeing a Radarr 6 stable till next year.
Author
Owner

@woutercoppens commented on GitHub (May 17, 2025):

What is for now the way forward? I uninstall this test version and go back to the old version of synocommunity?

@woutercoppens commented on GitHub (May 17, 2025): What is for now the way forward? I uninstall this test version and go back to the old version of synocommunity?
Author
Owner

@mreid-tt commented on GitHub (May 17, 2025):

What is for now the way forward? I uninstall this test version and go back to the old version of synocommunity?

I’d recommend rolling back to the previous SynoCommunity version. That version can’t update past v5.12.2.9335 — any newer release hits this same issue. If you’re comfortable with the Radarr 6 development branch and it’s working fine for you, you could stick with it, but bear in mind it won’t receive updates until the next dev cycle, which could be several months away.

@mynameisbogdan, do you have any other thoughts?

@mreid-tt commented on GitHub (May 17, 2025): > What is for now the way forward? I uninstall this test version and go back to the old version of synocommunity? I’d recommend rolling back to the previous SynoCommunity version. That version can’t update past v5.12.2.9335 — any newer release hits this same issue. If you’re comfortable with the Radarr 6 development branch and it’s working fine for you, you could stick with it, but bear in mind it won’t receive updates until the next dev cycle, which could be several months away. @mynameisbogdan, do you have any other thoughts?
Author
Owner

@woutercoppens commented on GitHub (May 17, 2025):

In both scenario's I won't receive any updates until Radarr 6 is released?

@woutercoppens commented on GitHub (May 17, 2025): In both scenario's I won't receive any updates until Radarr 6 is released?
Author
Owner

@mreid-tt commented on GitHub (May 17, 2025):

In both scenario's I won't receive any updates until Radarr 6 is released?

That's my interpretation of the current state of things. @mynameisbogdan will have to confirm.

@mreid-tt commented on GitHub (May 17, 2025): > In both scenario's I won't receive any updates until Radarr 6 is released? That's my interpretation of the current state of things. @mynameisbogdan will have to confirm.
Author
Owner
@mynameisbogdan commented on GitHub (May 17, 2025): I'm willing to maintain some custom builds with a downgrade version of dotnet for Synology if you're interested. https://radarr.servarr.com/v1/update/dotnet6-synology/updatefile?os=linux&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/dotnet6-synology/updatefile?os=linuxmusl&runtime=netcore&arch=x64 https://radarr.servarr.com/v1/update/dotnet6-synology/updatefile?os=linux&runtime=netcore&arch=arm https://radarr.servarr.com/v1/update/dotnet6-synology/updatefile?os=linux&runtime=netcore&arch=arm64
Author
Owner

@mreid-tt commented on GitHub (May 25, 2025):

I'm willing to maintain some custom builds with a downgrade version of dotnet for Synology if you're interested.

I appreciate the effort, but I'm not sure maintaining custom builds is worthwhile. From what I understand, the internal updater will still target the standard releases, which means updates will continue to fail unless we re-release each version to the repository. Historically, we haven’t maintained apps this way, especially since our update cadence doesn’t align with projects that release frequently. Given that, maintaining custom builds solely for ARMv7 users doesn’t seem like a sustainable approach.

@mreid-tt commented on GitHub (May 25, 2025): > I'm willing to maintain some custom builds with a downgrade version of dotnet for Synology if you're interested. I appreciate the effort, but I'm not sure maintaining custom builds is worthwhile. From what I understand, the internal updater will still target the standard releases, which means updates will continue to fail unless we re-release each version to the repository. Historically, we haven’t maintained apps this way, especially since our update cadence doesn’t align with projects that release frequently. Given that, maintaining custom builds solely for ARMv7 users doesn’t seem like a sustainable approach.
Author
Owner

@woutercoppens commented on GitHub (May 26, 2025):

I agree that custom builds are not a sustainable approach, but the alternative is that ARMv7 users stay on a release from oct 24.
Some updates via custom builds are better then no updates.

@woutercoppens commented on GitHub (May 26, 2025): I agree that custom builds are not a sustainable approach, but the alternative is that ARMv7 users stay on a release from oct 24. Some updates via custom builds are better then no updates.
Author
Owner

@mynameisbogdan commented on GitHub (May 28, 2025):

@mreid-tt I failed to ask, but is Radarr the only one with the issue with .NET greater than 6.0.32? I'm curious about Lidarr, Readarr and Prowlarr.

@mynameisbogdan commented on GitHub (May 28, 2025): @mreid-tt I failed to ask, but is Radarr the only one with the issue with .NET greater than 6.0.32? I'm curious about Lidarr, Readarr and Prowlarr.
Author
Owner

@mreid-tt commented on GitHub (May 28, 2025):

@mreid-tt I failed to ask, but is Radarr the only one with the issue with .NET greater than 6.0.32? I'm curious about Lidarr, Readarr and Prowlarr.

I believe this affects only the Servarr apps. The Lidarr I use has .NET 6.0.35. I assume so does Readarr and Prowlarr but I don't use these. For the Sonarr I use, they are still at .NET 6.0.13 so not affected.

EDIT: I was only commenting on the .NET versions. I can't say if Lidarr works on ARMv7 as I don't have one of these platforms to test it on. My NAS uses x64.

@mreid-tt commented on GitHub (May 28, 2025): > [@mreid-tt](https://github.com/mreid-tt) I failed to ask, but is Radarr the only one with the issue with .NET greater than 6.0.32? I'm curious about Lidarr, Readarr and Prowlarr. I believe this affects only the Servarr apps. The [Lidarr](https://github.com/Lidarr/Lidarr/blob/7217e891f70f8ff779bb1ca3b789e09ba47088c5/azure-pipelines.yml#L18) I use has .NET 6.0.35. I assume so does [Readarr](https://github.com/Readarr/Readarr/blob/18bca0b228e544cee9eb3c150adb3a8a6c482cae/azure-pipelines.yml#L18) and [Prowlarr](https://github.com/Prowlarr/Prowlarr/blob/c3ee3f2320c6638c6d5aaf88e417ba4f5fe3edd6/azure-pipelines.yml#L18) but I don't use these. For the Sonarr I use, they are still at .NET 6.0.13 so not affected. EDIT: I was only commenting on the .NET versions. I can't say if Lidarr works on ARMv7 as I don't have one of these platforms to test it on. My NAS uses x64.
Author
Owner

@mynameisbogdan commented on GitHub (May 28, 2025):

To confirm, you're saying Lidarr with 6.0.35 works but Radarr with same version doesn't?

I assume so does Readarr and Prowlarr but I don't use these.

Are they updated to latest versions in the syno repository and zero complains from users?

@mynameisbogdan commented on GitHub (May 28, 2025): To confirm, you're saying Lidarr with 6.0.35 works but Radarr with same version doesn't? > I assume so does [Readarr](https://github.com/Readarr/Readarr/blob/18bca0b228e544cee9eb3c150adb3a8a6c482cae/azure-pipelines.yml#L18) and [Prowlarr](https://github.com/Prowlarr/Prowlarr/blob/c3ee3f2320c6638c6d5aaf88e417ba4f5fe3edd6/azure-pipelines.yml#L18) but I don't use these. Are they updated to latest versions in the syno repository and zero complains from users?
Author
Owner

@mreid-tt commented on GitHub (May 28, 2025):

@mynameisbogdan Just to clarify, consistent with the issue noted in this ticket, any version built using a .NET runtime newer than 6.0.32 will not work for ARMv7 users. While we don't have direct reports confirming this from users of Lidarr, Readarr, or Prowlarr — likely due to fewer users running these on older platforms — I linked their repositories to show they’re all using the same .NET SDK version, so they’re likely affected in the same way as Radarr.

Regarding the SynoCommunity repository, we don’t publish every new release of the Servarr packages since the internal updaters typically handle incremental updates. However, I’ve published the last versions of each that still use .NET runtime 6.0.32. This ensures that new installs on ARMv7 will at least install and run, although auto-updates to newer versions will fail.

@mreid-tt commented on GitHub (May 28, 2025): @mynameisbogdan Just to clarify, consistent with the issue noted in this ticket, any version built using a .NET runtime newer than 6.0.32 will not work for ARMv7 users. While we don't have direct reports confirming this from users of Lidarr, Readarr, or Prowlarr — likely due to fewer users running these on older platforms — I linked their repositories to show they’re all using the same .NET SDK version, so they’re likely affected in the same way as Radarr. Regarding the SynoCommunity repository, we don’t publish every new release of the Servarr packages since the internal updaters typically handle incremental updates. However, I’ve published the last versions of each that still use .NET runtime 6.0.32. This ensures that new installs on ARMv7 will at least install and run, although auto-updates to newer versions will fail.
Author
Owner

@mynameisbogdan commented on GitHub (May 28, 2025):

Can anyone post trace logs with the error? I just noticed they are only info.

@mynameisbogdan commented on GitHub (May 28, 2025): Can anyone post trace logs with the error? I just noticed they are only info.
Author
Owner

@github-actions[bot] commented on GitHub (May 28, 2025):

👋 @woutercoppens, In order to help you further we'll need to see logs. You'll need to enable trace logging and replicate the problem that you encountered. Guidance on how to enable trace logging can be found in our troubleshooting guide.

@github-actions[bot] commented on GitHub (May 28, 2025): :wave: @woutercoppens, In order to help you further we'll need to see logs. You'll need to enable trace logging and replicate the problem that you encountered. Guidance on how to enable trace logging can be found in our [troubleshooting guide](https://wiki.servarr.com/radarr/troubleshooting#logging-and-log-files).
Author
Owner

@woutercoppens commented on GitHub (Jun 4, 2025):

Please have a look at https://gist.github.com/woutercoppens/1c61f88f41fc1695350138d0da38dd6d

@woutercoppens commented on GitHub (Jun 4, 2025): Please have a look at https://gist.github.com/woutercoppens/1c61f88f41fc1695350138d0da38dd6d
Author
Owner

@mreid-tt commented on GitHub (Sep 22, 2025):

I note that in the develop branch we have a pre-release of v6.0.0.10217. This is built with .NET 8 so based on previous testing it should resolve this issue. Let us know @woutercoppens what are your findings with this version.

@mreid-tt commented on GitHub (Sep 22, 2025): I note that in the develop branch we have a pre-release of v[6.0.0.10217](https://github.com/Radarr/Radarr/releases/tag/v6.0.0.10217). This is built with .NET 8 so based on previous testing it should resolve this issue. Let us know @woutercoppens what are your findings with this version.
Author
Owner

@woutercoppens commented on GitHub (Sep 25, 2025):

How do I install v6.0.0.10217?

I changed the channel to develop (and even restarted Radarr). I can see v6.0.0.10217 in the available updates but when I clikc on install latest, it always downloads v5.28.0.10205.

@woutercoppens commented on GitHub (Sep 25, 2025): How do I install v6.0.0.10217? I changed the channel to develop (and even restarted Radarr). I can see v6.0.0.10217 in the available updates but when I clikc on install latest, it always downloads v5.28.0.10205.
Author
Owner

@ben63vw commented on GitHub (Dec 8, 2025):

I'm having this issue now with Radarr 6.0.3.10276 that has .NET 8.0.12 installed and running on a Qnap TVS-682 which is running an Intel x86 CPU. I'm on the develop update channel and it shows that 6.1.0.10293 update is available but I get errors for GLIBC_2.34 and GLIBC_2.35 not found when trying to update from within Radarr. I've attached my log file.

radarr.txt

@ben63vw commented on GitHub (Dec 8, 2025): I'm having this issue now with Radarr 6.0.3.10276 that has .NET 8.0.12 installed and running on a Qnap TVS-682 which is running an Intel x86 CPU. I'm on the develop update channel and it shows that 6.1.0.10293 update is available but I get errors for GLIBC_2.34 and GLIBC_2.35 not found when trying to update from within Radarr. I've attached my log file. [radarr.txt](https://github.com/user-attachments/files/24041925/radarr.txt)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Radarr#8893
No description provided.