starred/Radarr

Fork 0

mirror of https://github.com/Radarr/Radarr.git synced 2026-03-02 22:57:34 -05:00

Renaming does not rename companion .srt file #9205

New issue

Closed

opened 2026-02-20 00:11:31 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 00:11:31 -05:00

Owner

Originally created by @loongemperor on GitHub (Jun 17, 2025).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

Renaming does not rename companion .srt files.

for example:

Moviename.4.2010.1080p.BluRay.x264.webm
Moviename.4.2010.1080p.BluRay.x264.srt

when using the rename option becomes

Moviename 4 (2010) Bluray-1080p.webm
Moviename.4.2010.1080p.BluRay.x264.srt

only the webm file is renamed and the .srt file is ignored.

tested on multiple different movies.

Expected Behavior

rename the .srt file alongside the webm

Steps To Reproduce

add a movie with a companion .srt file
rename it

Environment

- OS: TrueNas Scale 25.04.1
- Radarr: v1.3.6
- Docker App Version: v5.27.0.10101
- Docker Install: Yes
- Using Reverse Proxy: No
- Browser: Brave 1.79.123 (Official Build) (64-bit)
- Database: ?

What branch are you running?

Master

Trace Logs? Not Optional

https://hastebin.com/share/onupayimig.yaml

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 @loongemperor on GitHub (Jun 17, 2025). ### Is there an existing issue for this? - [x] I have searched the existing open and closed issues ### Current Behavior Renaming does not rename companion .srt files. for example: ``` Moviename.4.2010.1080p.BluRay.x264.webm Moviename.4.2010.1080p.BluRay.x264.srt ``` when using the rename option becomes ``` Moviename 4 (2010) Bluray-1080p.webm Moviename.4.2010.1080p.BluRay.x264.srt ``` only the webm file is renamed and the `.srt` file is ignored. tested on multiple different movies. ### Expected Behavior rename the .srt file alongside the webm ### Steps To Reproduce add a movie with a companion .srt file rename it ### Environment ```markdown - OS: TrueNas Scale 25.04.1 - Radarr: v1.3.6 - Docker App Version: v5.27.0.10101 - Docker Install: Yes - Using Reverse Proxy: No - Browser: Brave 1.79.123 (Official Build) (64-bit) - Database: ? ``` ### What branch are you running? Master ### Trace Logs? **Not Optional** https://hastebin.com/share/onupayimig.yaml ### 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.

deekerman

2026-02-20 00:11:31 -05:00

closed this issue
added the
Type: Bug

Status: Cannot Reproduce

Type: Support.
labels

deekerman commented

2026-02-20 00:11:31 -05:00

Author

Owner

@loongemperor commented on GitHub (Jun 17, 2025):

I had the idea that maybe it fails to recognize it because there is no language tag so I tried

Moviename.4.2010.1080p.BluRay.x264.webm
Moviename.4.2010.1080p.BluRay.x264.eng.srt

and it had the same result of renaming the webm and ignoring the .srt file

@loongemperor commented on GitHub (Jun 17, 2025): I had the idea that maybe it fails to recognize it because there is no language tag so I tried ``` Moviename.4.2010.1080p.BluRay.x264.webm Moviename.4.2010.1080p.BluRay.x264.eng.srt ``` and it had the same result of renaming the webm and ignoring the .srt file

deekerman commented

2026-02-20 00:11:32 -05:00

Author

Owner

@mynameisbogdan commented on GitHub (Jun 17, 2025):

Do you have custom chown user and permissions set? Because you have permissions issues in the logs and I can't reproduce.

@mynameisbogdan commented on GitHub (Jun 17, 2025): Do you have custom chown user and permissions set? Because you have permissions issues in the logs and I can't reproduce.

deekerman commented

2026-02-20 00:11:32 -05:00

Author

Owner

@loongemperor commented on GitHub (Jun 18, 2025):

Do you have custom chown user and permissions set? Because you have permissions issues in the logs and I can't reproduce.

I am using the default user for the official truenas install. which is 568. which is the default "apps" user in truenas.

The dataset in question uses posix open permissions. owner is a different user called "share". but it gives group Group – default – builtin_users full RWX permissions.

The failed changing of permission happen after the rename successfully finishes. Is there perhaps an issue where it does something like

rename file 1
change permission file 1
rename file 2

where if changing permissions on file 1 fails it aborts instead doing rename file 2?

I did try to bulk rename multiple series at once and they all successfully renamed the webm but failed to rename the srt in a single operation. but it might still be such an issue where failing to set permissions to 777 after a rename causes it to abort renaming companion files but not abort the whole process.

making it not abort after permission change failure would be the bugfix. and maybe report to the user that it failed to change permissions...

also I noticed something odd one line before the failed permission change
2025-06-16 23:55:45.0|Trace|ConfigService|Using default config value for 'chowngroup' defaultValue:''

there is no such thing as chowngroup there is chown that is used to change the group ownership of a file via
chown [options] username:groupname file[s]

@loongemperor commented on GitHub (Jun 18, 2025): > Do you have custom chown user and permissions set? Because you have permissions issues in the logs and I can't reproduce. I am using the default user for the official truenas install. which is 568. which is the default "apps" user in truenas. The dataset in question uses posix open permissions. owner is a different user called "share". but it gives group `Group – default – builtin_users` full RWX permissions. The failed changing of permission happen after the rename successfully finishes. Is there perhaps an issue where it does something like > rename file 1 > change permission file 1 > rename file 2 where if changing permissions on file 1 fails it aborts instead doing rename file 2? I did try to bulk rename multiple series at once and they all successfully renamed the webm but failed to rename the srt in a single operation. but it might still be such an issue where failing to set permissions to 777 after a rename causes it to abort renaming companion files but not abort the whole process. making it not abort after permission change failure would be the bugfix. and maybe report to the user that it failed to change permissions... also I noticed something odd one line before the failed permission change `2025-06-16 23:55:45.0|Trace|ConfigService|Using default config value for 'chowngroup' defaultValue:''` there is no such thing as `chowngroup` there is `chown` that is used to change the group ownership of a file via `chown [options] username:groupname file[s]`

deekerman commented

2026-02-20 00:11:32 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Jun 18, 2025):

2025-06-16 23:55:45.0|Trace|ConfigService|Using default config value for 'chowngroup' defaultValue:''

This has no relevance to any command and is referring to the radarr config value - the Chown Group.

There is just about never a reasonable usecase for having radarr changing the file permissions and any and all instances seen so far indicate poor setups of users download clients not setting the correct user/group/umask.

Furthermore, if you're having radarr change the permissions then the user radarr is running as must own the file as is clearly noted in the UI.

Given the improper configuration and inability to reproduce this appears to be a support issue not a bug.

If you still have issues after correcting your broken setup - For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

@bakerboy448 commented on GitHub (Jun 18, 2025): > 2025-06-16 23:55:45.0|Trace|ConfigService|Using default config value for 'chowngroup' defaultValue:'' This has no relevance to any command and is referring to the radarr config value - the Chown Group. There is just about never a reasonable usecase for having radarr changing the file permissions and any and all instances seen so far indicate poor setups of users download clients not setting the correct user/group/umask. Furthermore, if you're having radarr change the permissions then the user radarr is running as must own the file as is clearly noted in the UI. Given the improper configuration and inability to reproduce this appears to be a support issue not a bug. ![Image](https://github.com/user-attachments/assets/5e34500a-b0ef-46c5-bc3b-4effb5bc7658) If you still have issues after correcting your broken setup - For support and inquiries, please use our [Discord](http://radarr.video/discord) channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

deekerman commented

2026-02-20 00:11:32 -05:00

Author

Owner

@loongemperor commented on GitHub (Jun 18, 2025):

@bakerboy448 this does not seem to be a permission issue. I fixed the permissions and the problem persists with no permission errors.

https://hastebin.com/share/bahomeviwo.yaml

it still fails to rename the .srt files. this shows that the permissions issue was not relevant to this bug.

furthermore, even if this was a permissions issue, there are still addition bugs being exposed here. which are:

bug 1. radarr fails to notice that it failed to perform a chown. it thinks chown was successful when it failed (I tested and it did not change ownership). this later results in failing to perform chmod because it does not own the files

bug 2. radarr fails to report to the user it is failing to perform chmod. this should appear as an error message under System > Status instead of only in the trace log

bug 3. if this really was a permission issue (I fixed the permissions and it still occurs so it clearly isn't. but if it was) then there would be the bug of aborting the rename of the .srt file if the .webm file failed to change its permissions. even though they are different unrelated files. however fixing the permissions issue did not fix the unrenamed .srt so this shouldn't be a permissions issue.

That said, you are right that there is no reason to use that feature of changing permissions automatically. so I disabled it.

I also tested a brand new install and it does not enable this setting by default. meaning I must have set it myself at some point.

@loongemperor commented on GitHub (Jun 18, 2025): @bakerboy448 this does not seem to be a permission issue. I fixed the permissions and the problem persists with no permission errors. https://hastebin.com/share/bahomeviwo.yaml it still fails to rename the .srt files. this shows that the permissions issue was not relevant to this bug. furthermore, even if this was a permissions issue, there are still addition bugs being exposed here. which are: bug 1. radarr fails to notice that it failed to perform a chown. it thinks chown was successful when it failed (I tested and it did not change ownership). this later results in failing to perform `chmod` because it does not own the files bug 2. radarr fails to report to the user it is failing to perform chmod. this should appear as an error message under System > Status instead of only in the trace log bug 3. if this really was a permission issue (I fixed the permissions and it still occurs so it clearly isn't. but if it was) then there would be the bug of aborting the rename of the .srt file if the .webm file failed to change its permissions. even though they are different unrelated files. however fixing the permissions issue did not fix the unrenamed .srt so this shouldn't be a permissions issue. That said, you are right that there is no reason to use that feature of changing permissions automatically. so I disabled it. I also tested a brand new install and it does not enable this setting by default. meaning I must have set it myself at some point.