Option to use folder date for recently added movies

(2012-08-01 11:48)Montellese Wrote:  Yes if your "new" movie has an mtime/ctime back in 2009 it's very likely that there are a lot of other movies with an mtime/ctime newer than 2009 so those movies will appear first in the list of recently added movies. And as that list only contains 25 movies by default and there are 25+ movies with a newer mtime/ctime than 2009 your "new" movie will not appear in the list.

Ok, so the only way to solve this currently is to "touch" the file so it gets the current date into mtime/ctime, or changing it with advanced settings, which is fine if you know what you are doing, but lots of our users will have no clue about this and possibly will start to complain about not seeing their "new" movie in the list when they add them.

anyway around this from a programming standpoint ? ie. change the default again , and if you want the "dev. database convenience" set the advanced setting ?
or add more logic somehow ?

lets wait until they start crying ...

(2012-08-01 13:50)Memphiz Wrote:  lets wait until they start crying ...

I'll quote you on that ;-)

(2012-06-09 10:20)Montellese Wrote:  I have merged the pull request with the default value being the behaviour that prefers mtime over ctime or the current time. To get the old (Eden) behaviour back <dateadded> in <videolibrary> needs to be set to 0. To get XBMC to choose the newer date from mtime and ctime <dateadded> needs to be set to 2.

Isn't that what this setting is for?

(2012-08-01 15:24)kricker Wrote:  

(2012-06-09 10:20)Montellese Wrote:  I have merged the pull request with the default value being the behaviour that prefers mtime over ctime or the current time. To get the old (Eden) behaviour back <dateadded> in <videolibrary> needs to be set to 0. To get XBMC to choose the newer date from mtime and ctime <dateadded> needs to be set to 2.

Isn't that what this setting is for?

yeah, I know that, but the default will cause older new movies not to show up (see above story) or to quote Memphiz, let see if users will cry

Oh you mean because the user would have to set an advanced setting to get the old behavior...gotcha. Let them cry if they will (...and some will), but the new default IMHO is far better. Even if I rip an old movie to add to my collection, the file gets the current date and shows up properly using the default behavior.

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...

<dateadded>2</dateadded>
<!-- 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 -->
</videolibrary>

(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...

<dateadded>2</dateadded>
<!-- 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 -->
</videolibrary>

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.

It's not really about rebuilding a database from scratch, it's about updating a single item in the database. I often get a new episode but there's no plot for it yet on the scraper. So later on I manually update the episode's details in XBMC which results in that episode showing up at the beginning of recently added episodes.

And I think we all have to admit that it's pretty hard to guess what the most common use case is here. I for one don't think that many XBMC users have a couchpotate server (or even couchpotate installed at all) or sickbeard or anything like that. If you look at the people coming to this forum you might get the impression that everyone (or most) using XBMC have such a setup but the fact is that only a very few of the XBMC users come to this forum and the ones that do are the ones with special setups and needs and are also the more tech savvy.

(2012-10-10 08:46)Montellese Wrote:  It's not really about rebuilding a database from scratch, it's about updating a single item in the database. I often get a new episode but there's no plot for it yet on the scraper. So later on I manually update the episode's details in XBMC which results in that episode showing up at the beginning of recently added episodes.

I agree with you there, although the way that works doesn't sound like it should be working that way. Should refreshing an episode ever actually be changing dateAdded? Perhaps a lastModified (I have no idea if that exists, probably not or it'd be used I'd assume). It seems like dateAdded should really only be filled in when the entry is created, we're supposed to be refreshing, not recreating, after all.

(2012-10-10 08:46)Montellese Wrote:  And I think we all have to admit that it's pretty hard to guess what the most common use case is here. I for one don't think that many XBMC users have a couchpotate server (or even couchpotate installed at all) or sickbeard or anything like that. If you look at the people coming to this forum you might get the impression that everyone (or most) using XBMC have such a setup but the fact is that only a very few of the XBMC users come to this forum and the ones that do are the ones with special setups and needs and are also the more tech savvy.

That seems just as subjective as the rest of it. The couchpotato thing was really just an example, the point being there are plenty of ways a file could be added that wasn't recently modified or created. Remember that all couchpotato or sickbeard really do is download files and move them to their final destination, and those actions seem common enough to me.

All in all it seems kind of like a point of view deal. For me "recently added" would refer to when something enters the system, where for some others it seems like they see it as "latest updates." I see the reasoning for both, but honestly, they really seem like different things. I have no idea the work involved, but maybe they should be different things? *The whole thing feels like changing the default behavior of ctime to act like mtime, but still calling it ctime.

*: Added that last line, it was not part of my original reply.