[Montellese]

That's very odd. Right after the first log output the code moves to retrieving the value of ctime but looking at the next log output it hasn't changed the value so either I'm blind or there's something wrong with XBMC's stat on that file.

I've added some more debug logging to print mtime, ctime and atime to see if there's a problem with those values compared to your stat output you posted above. You can just add it on top of the other patch I posted earlier: http://pastebin.com/1JGmCP7v

[lastimp]

Modify time in 2016?

Thats the point, for whatever reason (not sure why) the mtime is invalid for this movie and should not be used.

That's very odd. Right after the first log output the code moves to retrieving the value of ctime but looking at the next log output it hasn't changed the value so either I'm blind or there's something wrong with XBMC's stat on that file.

I've added some more debug logging to print mtime, ctime and atime to see if there's a problem with those values compared to your stat output you posted above. You can just add it on top of the other patch I posted earlier: http://pastebin.com/1JGmCP7v

new log http://pastebin.com/pGJXSD45

[Montellese]

Hm really looks like there's something wrong with XBMC's ctime in this case (or with the stat implementation you used in linux). Will have to contact some linux guru on this because I don't have any clue about that part of the code and I can't really test myself. Thanks a lot for your help and for the logs. Looks like the dateadded logic actually works fine but the dates it works with are borked.

[lastimp]

That's very odd. Right after the first log output the code moves to retrieving the value of ctime but looking at the next log output it hasn't changed the value so either I'm blind or there's something wrong with XBMC's stat on that file.

I've added some more debug logging to print mtime, ctime and atime to see if there's a problem with those values compared to your stat output you posted above. You can just add it on top of the other patch I posted earlier: http://pastebin.com/1JGmCP7v

Also here is the stat for one that is working properly:

File: `Iron Sky (2012).mkv'
Size: 4694322286 Blocks: 9161605 IO Block: 16384 regular file
Device: 13h/19d Inode: 3715699 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ lastimp) Gid: ( 1000/ lastimp)
Access: 2012-06-16 14:12:13.156795900 -0700
Modify: 2012-05-28 13:37:08.000000000 -0700
Change: 2012-06-10 10:45:49.442878900 -0700

and the log:
http://pastebin.com/z1a238ph

[Montellese]

@lastimp: Just remembered that you wrote that your files are on a NAS. What OS and filesystem does it use and what do you use to access the files? Maybe it helps narrow down the problem in the code if it's a specific protocol or filesystem.

[lastimp]

@lastimp: Just remembered that you wrote that your files are on a NAS. What OS and filesystem does it use and what do you use to access the files? Maybe it helps narrow down the problem in the code if it's a specific protocol or filesystem.

I am using freenas (FreeBSD based) and samba for sharing, however shouldn't that be irrelevant if ubuntu is showing the proper ctime of "Change: 2010-05-19 04:30:33.326882600 -0700" . Even just doing an "ls -lc" from the command line shows the correct change time that should be used:

lastimp@xbmc:~/Media/Media/Movies/The Book of Eli (2010)$ ls -lc
total 6905218
drwx------ 2 lastimp lastimp 0 2012-04-10 20:10 extrathumbs
-rwx------ 1 lastimp lastimp 424209 2012-05-26 13:29 The Book of Eli-fanart.jpg
-rw-r--r-- 1 lastimp lastimp 7041004012 2010-05-19 04:30 The Book of Eli.mkv
-rwx------ 1 lastimp lastimp 30764 2012-05-26 13:29 The Book of Eli.nfo
-rwx------ 1 lastimp lastimp 63475 2012-05-26 13:29 The Book of Eli.tbn
-rwx------ 1 lastimp lastimp 33304692 2011-12-22 13:39 The Book of Eli-trailer.mp4

Here is the stat when I ssh directly into my server:

[lastimp@nas4free /mnt/tank/Storage/Media/Movies/The Book of Eli (2010)]$ stat -x "The Book of Eli.mkv"
File: "The Book of Eli.mkv"
Size: 7041004012 FileType: Regular File
Mode: (0644/-rw-r--r--) Uid: ( 1001/ lastimp) Gid: ( 31/ guest)
Device: 213,2904424681 Inode: 291259 Links: 1
Access: Sat Jun 16 10:57:55 2012
Modify: Wed Nov 9 15:33:11 2016
Change: Wed May 19 04:30:33 2010

which appears to have the same info from what I can tell.

[Montellese]

Well XBMC generally uses different implementations of Stat() (same with Open/Close etc) based on the protocol and I'm sure ubuntu does the same, you just don't see it. Looked at XBMC's filesystem code it calls _fstat64 or _stat64 for local files but smbc_fstat() for files accessed over samba so might be that the problem is located in the library we use to support samba.

EDIT: On the other hand we also can't be sure that what Ubuntu returns is correct (although it's more likely).

EDIT2: Can you try the same procedure with another file where mtime is valid and ubuntu reports different values for mtime and ctime and check the log if xbmc's output shows equal values for mtime and ctime? Maybe there are just specific files that are troublesome.

[lastimp]

Well XBMC generally uses different implementations of Stat() (same with Open/Close etc) based on the protocol and I'm sure ubuntu does the same, you just don't see it. Looked at XBMC's filesystem code it calls _fstat64 or _stat64 for local files but smbc_fstat() for files accessed over samba so might be that the problem is located in the library we use to support samba.

EDIT: On the other hand we also can't be sure that what Ubuntu returns is correct (although it's more likely).

You noticed my edit in the previous post right, I added the stat info directly from freebsd.

[Montellese]

Yeah just saw it now after my second edit (in case you haven't seen that ) so yeah ubuntu being wrong can be ruled out so it must be a problem in libsmbclient or in how xbmc interprets the results of smbc_stat() but that looks like pretty straight-forward copying of values.

[lastimp]

Yeah just saw it now after my second edit (in case you haven't seen that ) so yeah ubuntu being wrong can be ruled out so it must be a problem in libsmbclient or in how xbmc interprets the results of smbc_stat() but that looks like pretty straight-forward copying of values.

See post #139 for "Iron Sky" which is one that is showing properly and has a valid modified date.

It looks like every file in my debug log all have equal values for ctime and mtime even the ones that are working.

[takoi]

Maybe it has to do with the fact that ctime should, by definition, be at least as big as mtime. So somewhere in the chain some code is interpreting the ctime as invalid and "fixing" it..

[DanLongman]

One thing I have noticed, if you have your files in a RAR container it will not get the date properly and thus recently added doesn't work, If you extract the file that will resolve the issue. I just set the value of dateadded in my advancedsettings to 0 and everything works as it used to now.

[Montellese]

There has been a fix from vdrfan a few days ago which addresses the dateadded bug for RAR archives. XBMC should now properly pick up the mtime/ctime from the archive (not the file within the archive).

[DanLongman]

Awesome, thanks!

[lastimp]

There has been a fix from vdrfan a few days ago which addresses the dateadded bug for RAR archives. XBMC should now properly pick up the mtime/ctime from the archive (not the file within the archive).

Any word on a possible fix for the problem with mtime/ctime on ubuntu/smb?