Preserving mtimes not working

[vodkapmp]

I'm on the latest version (3.5.1) on a fresh Ubuntu 24.04 vm. No matter what I do it seems that --preserve-mtimes just wont function.

I've tried using it both with easy and custom by using -p with rsgain custom, and setting PreserveMtimes=true in a .ini file for rsgain easy.

Not entirely sure what logs I could provide, but here's the output of a rsgain custom with stat before and after.

vodka@rsgaintest:~/musictest$ stat redacted.opus   
  File: redacted.opus
  Size: 3467870         Blocks: 6776       IO Block: 4096   regular file
Device: 252,0   Inode: 397839      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   vodka)   Gid: ( 1000/   vodka)
Access: 2024-05-29 07:27:28.000000000 +0000
Modify: 2023-07-30 00:00:00.000000000 +0000
Change: 2024-07-13 00:16:13.529009654 +0000
 Birth: 2024-07-13 00:16:13.201014571 +0000

vodka@rsgaintest:~/musictest$ rsgain custom -s i -c a -o r -p redacted.opus 
[✔] Scanning 'redacted.opus'
[✔] Container: Ogg [ogg]
[✔] Stream #0: Opus, 48,000 Hz, 2 ch
 100% [======================================================================================================================================]

Track: redacted.opus
  Loudness:    -5.71 LUFS
  Peak:     1.000000 (0.00 dB)
  Gain:       -12.29 dB (-3145)

vodka@rsgaintest:~/musictest$ stat redacted.opus   
  File: redacted.opus
  Size: 3467895         Blocks: 6776       IO Block: 4096   regular file
Device: 252,0   Inode: 397839      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   vodka)   Gid: ( 1000/   vodka)
Access: 2024-07-13 00:16:23.551874580 +0000
Modify: 2024-07-13 00:16:22.941881921 +0000
Change: 2024-07-13 00:16:23.551874580 +0000
 Birth: 2024-07-13 00:16:13.201014571 +0000

As can be seen here the only timestamp that doesn't change is Birth, while the important one Modify is changed.

[complexlogic]

I'm unable to reproduce this on my end. When I run stat before and after, the Modify timestamp is preserved. Perhaps this may have something to do with your VM setup?

[vodkapmp]

It could be, but it's a completely stock ubuntu 24.04 VM so I don't really see what would cause this

Using r128gain on the same file with the preserve mtime switch for that works perfectly fine and doesn't change the mtime

[Sammala]

Same issue here, using Windows 10 with rsgain 3.5.2 on .opus files. Not a VM.

My config file looks like this:

[Global] TagMode=i Album=true TargetLoudness=-18 ClipMode=p MaxPeakLevel=0.0 TruePeak=true Lowercase=false ID3v2Version=keep OpusMode=d PreserveMtimes=true

And my command line prompt is: rsgain.exe easy -m 5 -p "C:[full path to ini]" "E:[full path to music folder]"

I also tested it with the following addition for Opus to write R128 tags in the config file but it still doesn't preserve date modified tags:

[Opus] TagMode=i Album=true TargetLoudness=-18 ClipMode=p MaxPeakLevel=0.0 TruePeak=true OpusMode=r PreserveMtimes=true

[phw]

@Sammala What kind of drive is E:? Is this maybe a network share?

[Sammala]

@Sammala What kind of drive is E:? Is this maybe a network share?

It's a local SSD with NTFS formatting. When I get home I'll copy some test files to my C: drive and try again.

[phw]

Thanks. I was just asking because in Picard we experienced the timestamp update on SMB shares not always working as expected, and thought like this could be related and be something similar in rsgain. But with a local drive and NTFS this seems to be something else.

[Sammala]

I tested it on the C: drive just now and the bug still happens. I also did it single-threaded just to see if it would make a difference, but the same thing still happens.

Running it in custom mode with the command rsgain.exe custom -s i -p "C:\[path to file]" also didn't make a difference, as well as running it in an admin command prompt.

Is there anything you would like me to try?

Edit: This seems to only happen with Opus files. I've tried mp3 and flac and they both preserve the date modified time just fine.

[complexlogic]

I have done some investigation, and discovered the root cause of this bug. It only affects Opus files, because it is related to the timing of the Opus header gain writing function and the function that checks the file's modification time. The bug is not caused by using a VM or differences in filesystems.

Thanks to everyone here for the reporting and debugging help. I'm going to push a commit with a fix, and make a new release.