Add sort by date added on movies library mode?

No, the problem does not originate in XBMC itself because all it does is copy whatever values libsmbclient provides us with. So chances are that there's some code in libsmbclient which is either bugged or for some reason decides to use the mtime value for ctime as well.

or statfiles is set to false in advancedsettings.xml which would lead to zero reads on ctime/mtime i guess ... (just an unlikly idea)

From samba mailing list:

Quote:> On Tue, Feb 14, 2012 at 11:39:00AM -0700, Christof Schmitt wrote:
> > Jeremy Allison <jra at samba.org> wrote on 02/13/2012 05:59:43 PM:
> >
> > > On Mon, Feb 13, 2012 at 11:23:41AM -0700, Christof Schmitt wrote:
> > > > I am working on a patch to store the ctime with the
> > > > gpfs_set_times() call. While testing setting and storing
> > > > timestamps i discovered that querying the timestamps from a cifs
> > > > client does not return all four timestamps. It seems that the
> > > > mtime is reported for two timestamps and the ctime is being
> > > > discarded:
> > > >
> > > > E.g. in smbd_do_qfilepathinfo():
> > > > mtime_ts = psbuf->st_ex_mtime;
> > > > ctime_ts = get_change_timespec(conn, fsp, smb_fname);
> > > > and get_change_timespec also returns the mtime.
> > > >
> > > > The attached patch changes get_change_timespec to return the
> > > > ctime, so that all timestamps set through the vfs set_times call can
> > > > be queried through the vfs stat calls.
> > >
> > > I don't think this is correct, but you'll have to wait
> > > until I analyse this more in order to be accurate.
> > >
> > > The basic problem is:
> > >
> > > UNIX ctime != Windows change time.
> > >
> > > Jeremy.
> > >
> >
> > Hi Jeremy,
> >
> > thanks for looking into this. Here are some more things in found
> > for this issue:
> >
> > The best testcase seems to be RAW-SFILEINFO in smbtorture: In
> > samba/source4/torture/raw/setfileinfo.c the step "Test basic_info
> > level\n" sets all four Windows timestamps and expects that
> > reading them yields the same values.
> >
> > In Samba, the "change time" is mapped to ctime in
> > smb_set_file_basic_info():
> >
> > /* create time */
> > ft.create_time = interpret_long_date(pdata);
> >
> > /* access time */
> > ft.atime = interpret_long_date(pdata+8);
> >
> > /* write time. */
> > ft.mtime = interpret_long_date(pdata+16);
> >
> > /* change time. */
> > ft.ctime = interpret_long_date(pdata+24);
> >
> > But when reading the timestamps, mtime is mapped to both, "write
> > time" and "change time". It seems odd to me that i can write
> > the "change time" from a client, but this value will never be
> > returned. The patch i submitted seems to be the simplest way to
> > change this.
>
> Yes, but it might break a bunch of Windows apps.
>
> The problem is that UNIX ctime != Windows change time. Yes,
> we treat it inconsistently on set and get (for set we
> pretend it's the same, on get we don't). But that's
> an underlying bug in Samba.
>
> The real fix for this is for us to take control of
> our own create/write/access/change times and reply
> to them with wholely Windows semantics, but that's
> a bigger change than we are willing to do right now.
>
> Look at the definition of st_ctime:
>
> "The field st_ctime is changed by writing or by setting
> inode information (i.e., owner, group, link count, mode, etc.)."
>
> Now look at the definition of LastChangeTime:
>
> "LastChangeTime: The time that identifies when the file
> metadata or contents were last changed"
>
> They're different. LastChangeTime is the greater of
> mtime and ctime (from UNIX). Probably. There's the
> issue of the 2-second granularity we also don't
> fully understand yet.
>
> This isn't the way it works on NTFS. If we pretend it
> is we'll run into a host of time-related problems that
> currently we avoid.
>
> The best way to proceed on this is to add smbtorture4
> tests until we *really* understand the updating of
> timestamps on NTFS, then code this into a completely
> separate timestamp management function within smbd,
> and determine how this maps (mostly) onto ctime,mtime,
> atime and friends.
>
> Jeremy.

Ok, thank you for explaining this. It looks like i mixed up two
things: One is storing the ctime if the filesystem allows this
and the other thing is mapping the ctime back the CIFS
timestamps.

I will drop this patch and discuss internally how we want to
proceed with storing all timestamps in gpfs.

Thanks,

Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
[hidden email] || +1-520-799-2469 (T/L: 321-2469)

Is it possible to coding "movie release date(premiere)" to Eden library now? IMDB have this date for movies, it'll be a popular function for everyone who like hot movies, of course, smart playlist also have to add this item^^.

Hello ,

I have been looking for an answer to the same query. I am a relative newbie with the following setup:

Dell Studio Hybrid 140G running Windows 7 Ultimate 32-Bit. 4GB RAM/40G HDD/Core2Duo 1.6Ghz/Intel 965 GPU. Fresh and clean installed XBMC 11 (the latest available) version from website.

Movie collection on NAS HDDs. The NAS server is a thin client machine(Dell Optiplex FX160) running Windows 7 with two USB harddisk connected shared as windows SAMBA network drives.

The movie structure is that under the root folder, there is one movie folder (by the movie name) for each movie file contained inside.

The video accelerator is a Broadcom BCM70012 with the latest CrystalHD drivers installed.

Wired 1000bps CAT6 network running via a Linksys WRT610N router to connect everything.

Both network drives are mapped on the PC running XBMC as local drives with drive letters W: and X: (instead of giving a UNC path \\192.x.x.x\XYZ)

I also have seen the same behavior, when I created a library in v11 from scratch via rescan and even with the sorting method of "Date Added" in Library mode, I cannot see the most recently added movies on the top (in ascending or descending order). Instead the movies are sorted in a strange and somehow incomprehensible way and mostly they are random with some old movies appearing at the top and so on.

Just for information for someone in the same dilemma, this is how I handled the unwanted updation in the folder modification time.

I exported the NFO files containing the movie URL from Extreme Movie Manager before a rescan of the library in XBMC, this would help the land XBMC on the exact IMDB URL instead of incorrect scraping in case of many common movie names. Since the NFO file was created one per folder, the modification time (or mtime or LastWriteTime in Windows PowerShell) for each folder was updated to the current date/time. This would result in a total disaster since there would be no sorting on the latest added movies. However the created date (or ctime or CreationTime in Windows PowerShell) for every folder was still intact. So I created a powershell script in Windows 7 (with expert help from the relevant forum) to update the modification time of each folder to be equal to the creation time and also a script to update the creation and modification time of the folder with the files contained inside, since the files were untouched. The script did work as intended.

I did all this hoping that XBMC in ver 11 would finally be able to do this in the library view, to sort the movies on the basis of their modification or creation time as saved in the NTFS file system, not on the date when they were added to the XBMC library.

However now I am confused, is this feature available in Eden in the desired way or not. With reference to the thread subject and the discussion over here https://github.com/xbmc/xbmc/pull/1034 so far what I understand is that the XBMC behavior would be controlled via the parameter in the advancedsettings.xml file. Is this now implemented in the current stable Eden V11 release.? If not then is there a better way to achieve the desired sorting in the Library mode as of now.

Apparently the Joe Miller script which did the trick for me in Dharma 10.1 would not work in Eden as mentioned here https://github.com/joemiller/xbmc-script...1b121ba6f9

Appreciate your guidance and clarification.