added Created/Modified fields (closes #1701) #1705

0000xFFFF · 2025-12-03T11:25:48Z

(closes #1701)

before merging:
- needs testing on windows (idk how to compile lol)
- info-widget.cc needs to be finished, it's not populating (or just remove the file date-times from there idk, but it seems like it should be in the Technical section)

works:

sorting works
qt adding columns with right click works
gtk adding columns works

arch linux 6.17.9-arch1-1

…ing on win) added new datetime type need to copare dates compare datetime using int64 for datetimes added get set dt (datetime) using time_t adding win support fix tuple to_filed_map match date ignore build dir ignore compile commands defaults to -1 ignore .cache remove debug print

radioactiveman · 2025-12-10T21:44:33Z

It's always nice to see a pull request for a feature from the same person who requested it. Thanks for working on this. 👍

I agree it would be nice to show the dates in the technical section in the Qt info dialog. Formatted though would be better in my opinion. And yes, it is buggy right now. The value changes every time when reopening the dialog and can even show negative values.

The timestamps should also be persisted. After restarting Audacious they are gone (playlist column is empty) and you need to refresh the files manually.

The code changes look fine to me from a first glance. Things to consider:

Is dt common or should we just write out datetime for public API functions?
The enum values Created and Modified are ambiguous, especially for Playlist as seen in your PR for audacious-plugins:

Playlist::Created,        // created
Playlist::Modified,       // modified

When shown in the UI, the date format should follow the locale preferences.

@jlindgren90: Could you please review the changes as well? Especially since they affect the fundamentals of Audacious. Testing on Windows would of course be nice too. Thanks in advance.

0000xFFFF · 2025-12-10T22:28:10Z

Yeah I called it set_dt, I was blindly following the neighboring function naming conventions (... set_str rather then set_string...) that is the only reason, I see how that would be ambiguous now, sorry... also what should the Created, Modified enums be called? maybe something like FileCreated, FileModified, yeah same thing happened, I kept it simple since there was a Path enum and not a FilePath or FileName...

I did see that playlists don't persist datetimes when you reopen, I'll take some time adding that when I learn how audacious saves them...

Also following locale preferences might be my biggest priority first.

Thanks for the review.

radioactiveman · 2025-12-10T23:42:52Z

Reading more about creation dates, this seems to be more complicated than expected.
stat.st_ctime is not the creation date. It is the last time the file’s metadata was changed.

https://lwn.net/Articles/397442/
https://itsfoss.gitlab.io/post/how-to-find-out-file-creation-date-and-time-in-linux/
https://unix.stackexchange.com/questions/91197/how-can-get-the-creation-date-of-a-file

My impression is that we should not write custom and platform dependent code for this. Using GIO instead could be an option but a) it is not available yet in libaudcore
b) it requires a rather new version of GLib
https://docs.gtk.org/gio/method.FileInfo.get_creation_date_time.html

Let's wait for John's response and recommendations on this matter.

jlindgren90 · 2025-12-12T05:32:15Z

This looks like a good start, thanks. Some thoughts:

Even though 32-bit systems are rare now, I think we should still avoid time_t in libaudcore API and add tuple_get/set_int64 instead. It could be useful for other fields in future.
I don't mind platform-specific functions where it makes sense, e.g. I think it's okay to use statx to get creation time on Linux rather than adding a hard gio dependency. FreeBSD and macOS support would be nice-to-haves but I don't think we need to block the feature for them.
Let's please hide the platform specific stuff behind the existing VFS layer though. See vfs_stdio.cc.
The audpl plugin should be updated to read/write the new tuple fields. It should be straightforward.

0000xFFFF · 2025-12-12T06:38:43Z

So keep the DateTime type or replace it with Int64... or have both that represent the same thing (int64_t)?
I'm not sure how I'll draw the date time int64 in qtui/playlist_model.cc without the DateTime type,
since if Tuple::Int64, like you said, could be used to represent something other than datetimes in the future.

I guess keep both?

…ld linux support)

jlindgren90 · 2025-12-12T14:30:08Z

src/libaudcore/audstrings.cc

+EXPORT StringBuf int64_to_str(int64_t val)
+{
+    StringBuf buf;
+    str_insert_int(buf, 0, val);


This will not work for values >= 2^31

jlindgren90 · 2025-12-12T14:31:22Z

src/libaudcore/playlist-utils.cc

    return str_compare_encoded(get_basename(a), get_basename(b));
 }

+static int tuple_compare_datetime(const Tuple & a, const Tuple & b,


We could just make tuple_compare_int take int64 and avoid duplication

jlindgren90 · 2025-12-12T14:32:24Z

src/libaudcore/probe.cc

-        // cleanly replace existing tuple
        new_tuple.set_state(Tuple::Valid);
+
+        int64_t mtime = 0, ctime = 0;


I think it would be better to avoid using "ctime" naming to avoid confusion

jlindgren90 · 2025-12-12T14:43:26Z

src/libaudcore/vfs_local.cc

+    if (mtime)
+        *mtime = st.st_mtime;
+    if (ctime)
+        *ctime = st.st_ctime;


This isn't creation time. For systems where we don't know how to get creation time, we should just return e.g. -1.

when i google "ctime on windows" it keeps popping up that it actually is creation time??
yeah... idk... Microsoft... -_-

duping functions for int64 from int, we could replace them to accept int64, but not sure if that breaks anything

0000xFFFF · 2025-12-14T10:28:50Z

I have no idea why but Song Info isn't updating at all for me when I change anything and recompile,
it still just shows the original dialog.
Still don't know how to populate that, might try again in the future (still need to study the codebase thoroughly).

That is only thing that is missing qt/gtk fields for date times, other than that I think everything is working properly?

Edit: ~~also sort by ("Playlist -> Sort -> By *") is missing for Created/Modified fields~~
Edit2: ok i added that ^

tuple_compare_date calls get_int64, we need to allow Int types to get/set Int64

radioactiveman requested a review from jlindgren90 December 10, 2025 21:45

fix path -> real_path

4c8dd21

0000xFFFF added 3 commits December 12, 2025 08:00

libaudcore: time_t -> int64_t

647e433

vfs layer: new get_file_timestamps functions (added FreeBSD, MacOS, o…

8f342c0

…ld linux support)

audpl saving int64s & datetimes

210f55e

jlindgren90 reviewed Dec 12, 2025

View reviewed changes

0000xFFFF added 4 commits December 13, 2025 02:03

forgot one arg time_t -> int64_t

5e31812

fix str_insert_int64

b817348

duping functions for int64 from int, we could replace them to accept int64, but not sure if that breaks anything

tuple_compare_int compare int64 (removed compare_datetime)

f8aaa98

not ctime (change time)

9251b56

0000xFFFF force-pushed the master branch 2 times, most recently from 03925d0 to 9251b56 Compare December 13, 2025 02:03

0000xFFFF added 4 commits December 13, 2025 03:45

ctime -> birthtime

bb06be4

todo (still unfinished) (need to fix bug)

e1d8307

fix wrong saving order audpl tuple

5cb1daa

(unfinished) int gets set for some reason instead of int64

3d8da8f

0000xFFFF force-pushed the master branch from ffa10b0 to 3d8da8f Compare December 13, 2025 07:54

0000xFFFF added 4 commits December 13, 2025 08:58

not ctime

c7cc424

fixed the bug (forgot to handle copy constructor)

7b3362e

info-widget.cc: handle Int64 & DateTime

430125d

Created -> FileCreated, Modified -> FileModified

1c23006

fix sorting Tuple::Year (Int), tuple_compare_date

a004402

tuple_compare_date calls get_int64, we need to allow Int types to get/set Int64

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

added Created/Modified fields (closes #1701) #1705

added Created/Modified fields (closes #1701) #1705

Uh oh!

0000xFFFF commented Dec 3, 2025 •

edited

Loading

Uh oh!

radioactiveman commented Dec 10, 2025

Uh oh!

0000xFFFF commented Dec 10, 2025

Uh oh!

radioactiveman commented Dec 10, 2025

Uh oh!

jlindgren90 commented Dec 12, 2025

Uh oh!

0000xFFFF commented Dec 12, 2025

Uh oh!

jlindgren90 Dec 12, 2025

Uh oh!

jlindgren90 Dec 12, 2025

Uh oh!

jlindgren90 Dec 12, 2025

Uh oh!

jlindgren90 Dec 12, 2025

Uh oh!

0000xFFFF Dec 13, 2025

Uh oh!

0000xFFFF commented Dec 14, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

added Created/Modified fields (closes #1701) #1705

Are you sure you want to change the base?

added Created/Modified fields (closes #1701) #1705

Uh oh!

Conversation

0000xFFFF commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

radioactiveman commented Dec 10, 2025

Uh oh!

0000xFFFF commented Dec 10, 2025

Uh oh!

radioactiveman commented Dec 10, 2025

Uh oh!

jlindgren90 commented Dec 12, 2025

Uh oh!

0000xFFFF commented Dec 12, 2025

Uh oh!

jlindgren90 Dec 12, 2025

Choose a reason for hiding this comment

Uh oh!

jlindgren90 Dec 12, 2025

Choose a reason for hiding this comment

Uh oh!

jlindgren90 Dec 12, 2025

Choose a reason for hiding this comment

Uh oh!

jlindgren90 Dec 12, 2025

Choose a reason for hiding this comment

Uh oh!

0000xFFFF Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

0000xFFFF commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

0000xFFFF commented Dec 3, 2025 •

edited

Loading

0000xFFFF commented Dec 14, 2025 •

edited

Loading