starred/Radarr

Fork 0

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

Constant Updates to the Modified Timestamp of Movie Files #7354

New issue

Open

opened 2026-02-19 23:11:05 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-19 23:11:05 -05:00

Owner

Originally created by @darthShadow on GitHub (Apr 18, 2023).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

There seems to be a loop in the implementation which is causing the constant updates:

This checks the date of the file with the actual date and updates the file timestamp if they are not equal:
github.com/Radarr/Radarr@1be450a9d0/src/NzbDrone.Core/MediaFiles/UpdateMovieFileService.cs (L84)

This is the actual function updating the file which checks for pre-epoch values and sets them to epoch:
github.com/Radarr/Radarr@1be450a9d0/src/NzbDrone.Common/Disk/DiskProviderBase.cs (L336)

The above 2 will result in the file never having a time older than epoch which will cause the first if check to always fail and always update the file timestamp to epoch.

Checking through the Sonarr source, it doesn't seem to have any similar check for pre-epoch values so I am not sure if it's even required now or not:
github.com/Sonarr/Sonarr@2303bff205/src/NzbDrone.Common/Disk/DiskProviderBase.cs (L322)

Expected Behavior

The timestamp should be updated only once unless it changes again rather than happening on every scan.

Steps To Reproduce

Import a pre-1970 movie
Change the Change File Date option to In Cinemas Date in the Settings
Refresh the above added movie multiple and see that Radarr tries to constantly update the movie timestamp.

Environment

- OS: Ubuntu 22.02
- Radarr: 4.4.4.7068
- Docker Install: Yes
- Using Reverse Proxy: Yes
- Browser: Microsoft Edge Dev v114.0.1788.0
- Database: Sqlite 3.40.1

What branch are you running?

Master

Trace Logs?

2023-04-18 13:23:36.8|Debug|DiskScanService|Scanning '/home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]' for video files
2023-04-18 13:23:36.8|Trace|DiskScanService|16 files were found in /home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]
2023-04-18 13:23:36.8|Debug|DiskScanService|2 video files were found in /home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]
2023-04-18 13:23:36.8|Trace|DiskScanService|Finished getting movie files for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0049261]
2023-04-18 13:23:36.8|Debug|DiskScanService|[A Foreign Affair (1948)][tt0040367, 61650] Cleaning up media files in DB
2023-04-18 13:23:36.8|Debug|ImportDecisionMaker|Analyzing 0/0 files.
2023-04-18 13:23:36.8|Trace|DiskScanService|Import decisions complete for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0001040]
2023-04-18 13:23:36.8|Debug|ImportApprovedMovie|Decisions: 0
2023-04-18 13:23:36.8|Trace|DiskScanService|Reprocessing existing files complete for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0001040]
2023-04-18 13:23:36.8|Trace|ConfigService|Using default config value for 'deleteemptyfolders' defaultValue:'False'
2023-04-18 13:23:36.8|Info|DiskScanService|Completed scanning disk for A Foreign Affair
2023-04-18 13:23:36.8|Trace|EventAggregator|Publishing MovieScannedEvent
2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent -> MovieScannedHandler
2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent <- MovieScannedHandler
2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent -> UpdateMovieFileService
2023-04-18 13:23:36.8|Debug|UpdateMovieFileService|Date of file [/home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]/A Foreign Affair (1948) [REMUX-1080P 8-BIT H264 DTS-HD MA 2.0]-FRAMESTOR.mkv] changed from '01/01/1970 00:00:00' to '08/20/1948 00:00:00'

Originally created by @darthShadow on GitHub (Apr 18, 2023). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior There seems to be a loop in the implementation which is causing the constant updates: This checks the date of the file with the actual date and updates the file timestamp if they are not equal: https://github.com/Radarr/Radarr/blob/1be450a9d0945515f870a722776eae2683803bda/src/NzbDrone.Core/MediaFiles/UpdateMovieFileService.cs#L84 This is the actual function updating the file which checks for pre-epoch values and sets them to epoch: https://github.com/Radarr/Radarr/blob/1be450a9d0945515f870a722776eae2683803bda/src/NzbDrone.Common/Disk/DiskProviderBase.cs#L336 The above 2 will result in the file never having a time older than epoch which will cause the first if check to always fail and always update the file timestamp to epoch. --- Checking through the Sonarr source, it doesn't seem to have any similar check for pre-epoch values so I am not sure if it's even required now or not: https://github.com/Sonarr/Sonarr/blob/2303bff2055d96e49b5a934b8482a1424eb70ae0/src/NzbDrone.Common/Disk/DiskProviderBase.cs#L322 ### Expected Behavior The timestamp should be updated only once unless it changes again rather than happening on every scan. ### Steps To Reproduce 1. Import a pre-1970 movie 2. Change the `Change File Date` option to `In Cinemas Date` in the Settings 3. Refresh the above added movie multiple and see that Radarr tries to constantly update the movie timestamp. ### Environment ```markdown - OS: Ubuntu 22.02 - Radarr: 4.4.4.7068 - Docker Install: Yes - Using Reverse Proxy: Yes - Browser: Microsoft Edge Dev v114.0.1788.0 - Database: Sqlite 3.40.1 ``` ### What branch are you running? Master ### Trace Logs? ``` 2023-04-18 13:23:36.8|Debug|DiskScanService|Scanning '/home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]' for video files 2023-04-18 13:23:36.8|Trace|DiskScanService|16 files were found in /home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367] 2023-04-18 13:23:36.8|Debug|DiskScanService|2 video files were found in /home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367] 2023-04-18 13:23:36.8|Trace|DiskScanService|Finished getting movie files for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0049261] 2023-04-18 13:23:36.8|Debug|DiskScanService|[A Foreign Affair (1948)][tt0040367, 61650] Cleaning up media files in DB 2023-04-18 13:23:36.8|Debug|ImportDecisionMaker|Analyzing 0/0 files. 2023-04-18 13:23:36.8|Trace|DiskScanService|Import decisions complete for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0001040] 2023-04-18 13:23:36.8|Debug|ImportApprovedMovie|Decisions: 0 2023-04-18 13:23:36.8|Trace|DiskScanService|Reprocessing existing files complete for: [A Foreign Affair (1948)][tt0040367, 61650] [00:00:00.0001040] 2023-04-18 13:23:36.8|Trace|ConfigService|Using default config value for 'deleteemptyfolders' defaultValue:'False' 2023-04-18 13:23:36.8|Info|DiskScanService|Completed scanning disk for A Foreign Affair 2023-04-18 13:23:36.8|Trace|EventAggregator|Publishing MovieScannedEvent 2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent -> MovieScannedHandler 2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent <- MovieScannedHandler 2023-04-18 13:23:36.8|Trace|EventAggregator|MovieScannedEvent -> UpdateMovieFileService 2023-04-18 13:23:36.8|Debug|UpdateMovieFileService|Date of file [/home/(removed)/GMedia/Movies/A Foreign Affair (1948) [tt0040367]/A Foreign Affair (1948) [REMUX-1080P 8-BIT H264 DTS-HD MA 2.0]-FRAMESTOR.mkv] changed from '01/01/1970 00:00:00' to '08/20/1948 00:00:00' ```

deekerman added the

Priority: Low

Type: Bug

Type: Enhancement

labels

2026-02-19 23:11:05 -05:00

deekerman commented

2026-02-19 23:11:06 -05:00

Author

Owner

@Qstick commented on GitHub (May 1, 2023):

This would indeed cause a loop, however the epoch check was put into place due to exceptions being thrown when trying to set the file date to a pre-epoch value. We'd need to also check for pre-epoch in update movie file service to avoid the extra write every scan

@Qstick commented on GitHub (May 1, 2023): This would indeed cause a loop, however the epoch check was put into place due to exceptions being thrown when trying to set the file date to a pre-epoch value. We'd need to also check for pre-epoch in update movie file service to avoid the extra write every scan

deekerman commented

2026-02-19 23:11:06 -05:00

Author

Owner

@darthShadow commented on GitHub (May 2, 2023):

The issue (https://github.com/Radarr/Radarr/issues/1913) doesn't seem to have any OS details but it seems weird to have such an issue.

Ideally, setting times older than epoch should be a non-issue in any modern OS / FS combination and, as linked above, Sonarr doesn't have any such check.

Perhaps this could be removed now and see if anything breaks and add the condition only for that OS/FS combination?

@darthShadow commented on GitHub (May 2, 2023): The issue (https://github.com/Radarr/Radarr/issues/1913) doesn't seem to have any OS details but it seems weird to have such an issue. Ideally, setting times older than epoch should be a non-issue in any modern OS / FS combination and, as linked above, Sonarr doesn't have any such check. Perhaps this could be removed now and see if anything breaks and add the condition only for that OS/FS combination?

deekerman commented

2026-02-19 23:11:06 -05:00

Author

Owner

@Qstick commented on GitHub (May 7, 2023):

In terms of FS, this likely happens on FAT file systems which count dates from 1/1/1980

@Qstick commented on GitHub (May 7, 2023): In terms of FS, this likely happens on FAT file systems which count dates from `1/1/1980`