(2012-08-01 21:30)edrikk Wrote: Exactly!
As I posted in another thread:
The current implementation from Montellese is perfect.
The 2009 movie issue being brought forth is not actually a 'normal' use case either... In that event, the user must have had a movie sitting on their PC, added some/many newer movies to their PC (i.e. create new file, could be a 2007 movie), THEN decide to add the 2009 movie to XBMC.
In reality, the users will 99% of the time obtain a movie (i.e. cdate/mdate is 'now') and add that to XBMC. This change also has benefit of allowing the devs and users a means to always have a consistent 'looking' order of movies, even if they blow the db away. The first time the users need to blow away a DB, they'll be happy for the cdate/mdate method.
Finally, if that 1% really wants the date of movie added to LIBRARY to be used for ordering, then the value of the dateadded parameter simply has to be set to 0, and the 'old' behaviour will continue...
<!-- 0 results in using the current datetime when adding a video;
1 (default) results in prefering to use the files mtime (if it's valid) and only using the file's ctime if the mtime isn't valid;
2 results in using the newer datetime of the file's mtime and ctime -->
You're making some assumptions there that I'm not sure are really true. I actually thought this new feature was a bug, and had been waiting for it to be fixed! I finally became frustrated enough to "dig into it" (The "you can always fix it yourself and contribute mantra") when I came across all of this -- apparently it's intentional. The new behavior seems to benefit development more then actual usage in my eyes, is it really normal usage for someone to continually rebuild their database from scratch?
(2012-08-01 21:30)edrikk Wrote: In reality, the users will 99% of the time obtain a movie (i.e. cdate/mdate is 'now') and add that to XBMC.
That really depends on your setup and how you go about things. My setup (which isn't all that abnormal -- couchpotatoserver and sickbeard on linux) preserves the filedates, and the dates end up being when the file was originally created and that gets preserved all the way up until it gets added to the library.
Luckily it would appear that its possible to restore the old behavior via a simple advancedsettings change, so, that works out for me anyway.
(2012-08-01 21:30)edrikk Wrote: The first time the users need to blow away a DB, they'll be happy for the cdate/mdate method.
I suppose that's true, but honestly, blowing away a DB happens a lot less often (for HTPC/normal usage) then the pain-staking process of rebuilding a new DB.
Anyway, just trying to offer another point of view on the matter. Instead of using the new setting, I think I might just create a postprocessing script for sickbeard that simply touches the files, since that usage scenario seems to mesh the best. I do want to stress that my setup doesn't seem abnormal to me, and anyone with the same or similar is going to have to use either advancedsettings or a similar "workaround" to get what seems pretty likely to be desired behavior.
May I suggest merely changing the default to the old behavior, instead of defaulting to the new? Seems more likely to me that those that would benefit most from the change are in the minority compared to those that would prefer the old behavior.