SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Update metadata without changing file modified time

Every update to a file usually updates the timestamp that indicates the time a file was last modified. This is usually a good thing, however, Roon will treat a file with an updated modified timestamp as a newly added file (

Is there an option (and if not, can one please be added) to preserve the file modification information? (I am aware this would mean I’d need to manually update Roon to force a re-scan to pick up the new metadata, that’s fine, it’s preferable to have many “newly added” albums).

1 Like

Hi, I’m not convinced that roon shows album as a newly added album if you simply modify the metadata of songs already under roons control. Does the problem only occur if either the files are renamed, or if the files metadata changes so that the value of album field changes?

Jaikoz itself loads files into internal database, when run over files previously processed it makes use of file modification date to decide if need to reread metadata from file itself or if it can just use existing info in database. So not modifying the file modification date could cause issues for Jaikoz, its certainly not a trivial change.

And making this change would certainly cause problems for users using Jaikoz and SongKong because then one application would not be aware when the other application had made changes.

My feeling is that if there is an issue here with roon then roon needs to act more sensibly.

Yes simply changing the metadata of songs under Roons control, caused it to decide they are new, even if the Album field doesn’t change. Other tagging tools provide a “preserve modification time” option to avoid this. I also don’t think this is just Roon.

I’m not asking it to be the default, just an option.

But my point is why is roon listing a new album, if it isn’t new. Is it listed twice or just the existing album marked as new?

I will have to experiment with roon to see exactly what happens. But no other roon users have complained about this issue.

But I generally don’t like the idea of modifying files and then tricking the filesystem into thinking they have not been modified.

To make a clearer test, I updated just the genre for an album… and same behaviour.

The added date is updated, and it is shown as a new album. It is a kinda crap, I agree, and I’ll post on their forums, but based on previous similar posts, they aren’t going to change it.

I don’t end up with a duplicate, just an album listed as new. It is the original entry, because it retains the play counts, it’s mainly that the added date seems tied to the file mtime.

EDIT: Innnnteresting. So, Roon actually has a setting for this, and you can choose between ctime, mtime and “roon import timestamp” (whatever that is). I have mine set for mtime, Jaikoz is adjusting the mtime and ctime remains constant… and Roon seems to still be using mtime.

Given this new (to me!) information, I think I retract this whole request, hang my head in shame for not knowing what i’m talking about, and go complain on the Roon forums :smiley:

Okay, I’m back here. This is a ridiculous rabbit hole, but as far as I can tell, this is the state:

  1. Windows updates the file (Jaikoz) and correctly updates the modified time
  2. FreeBSD via CIFS correctly updates BSD’s “birth time” for that file
  3. Linux (where Roon Server is running) does NOT see the birth time, because birth time is not POSIX, and instead they have crtime. Linux then uses the modified time as the birth time.

This is validated by running stat (or viewing properties) in Roon client, Windows Explorer, Linux w/ stat, BSD w/ stat.

Frankly, it’s a mess… and the easiest way to solve it actually seems to be my original request to preserve modified times :-/

This isn’t a Roon bug, but rather an incompatibility between BSD/Windows and Linux around creation time… at least AFAICT.

EDIT for reference:

EDIT 2: Using a Linux VM, and mounting via CIS I do see the expected create time. So… this is back to a Roon problem :frowning: