[kricker]

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.

[edrikk]

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>

[garretn]

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?

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.

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.

[Montellese]

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.

[garretn]

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.

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.

[garretn]

Sorry for replying to myself, I realize my thoughts were all over the place in my last reply, and thought a major edit to my reply wouldn't work in this case.

I was just digging through the code, and my earlier suggestions aren't terribly reasonable based on how many things depend on dateadded and how that all works, so the only reasonable solution was the one Montellese already implemented -- reducing the debate to pretty much what should be the default, which I'm not terribly interested in debating (It's a setting, that's easily enough set, so I'm good). Something like a default is easily enough changed over time if usage patterns clarify normal usage and whatnot.

That said, I withdraw for now and thank you and the other XBMC devs for the awesome work. I intend to research and possibly contribute if I can actually think of something better, which at the moment, the 8-ball returns hazy.

[deuch]

Is it not more simple to let the classical way to order the video (aka in EDEN by dateadded=0) and put some options in the settings menu to let the choice to people ?

[Memphiz]

Nope its not more simple. Each gui setting makes XBMC more complex.

[deuch]

So let the default mode (aka EDEN) as before. Why change it ? I mean, it's more logical that the order is dateadded=0 because it's the date of the insertion in the database/librairie and not the date of creation or modification of the file.

Why change the previous behaviour and force people to create xml file fot that ? It's not very user friendly. Again, i think it's more a setting to add in the menu instead of modify a file.

[Martijn]

So let the default mode (aka EDEN) as before. Why change it ? I mean, it's more logical that the order is dateadded=0 because it's the date of the insertion in the database/librairie and not the date of creation or modification of the file.

Why change the previous behaviour and force people to create xml file fot that ? It's not very user friendly. Again, i think it's more a setting to add in the menu instead of modify a file.

Because the majority wants it that way and for every setting added to the GUI an innocent endangered animal dies .

[deuch]

I don't understand .... This order it's not logical. If i create a film for 2010 for example, and add it to the library, i will never see it because of the file created after it and inserter in the database like 6 months ago.

What's the point ? Who is the majority ? 2 people in a forum ?

"for every setting added to the GUI an innocent endangered animal dies ." --> Maybe it's time to change the way to map settings in the menu to the content of the xml file don't you think ? Or find something else to be able to do it easily ?

[kricker]

Because when you refresh an old library item it then becomes new in the DB and gets put to the top of the list. Going by the files created date means it will not do that. If you buy a new old movie from 2010 and rip it to your collection, the created date will be the date you ripped it not 2010. There are a whole lot more people behind this change than just 2.

[Martijn]

I don't understand .... This order it's not logical. If i create a film for 2010 for example, and add it to the library, i will never see it because of the file created after it and inserter in the database like 6 months ago.

What's the point ? Who is the majority ? 2 people in a forum ?

"for every setting added to the GUI an innocent endangered animal dies ." --> Maybe it's time to change the way to map settings in the menu to the content of the xml file don't you think ? Or find something else to be able to do it easily ?

Work is being done on settings but don't expect anything soon

[deuch]

So the question : What people do more often : add entry in the library or refresh one ? You ca do that too : If you refresh a existing entry (update instead of insert in a database), do not modify the date, just the content and the order will not change ... Problem solved ...

[Montellese]

If i create a film for 2010 for example

I don't understand. Create a film "for 2010"?

What's the point ? Who is the majority ? 2 people in a forum ?

There are two big advantages with this behaviour that the old behaviour doesn't have:

• Refreshing the information of an old movie (maybe there's a better cover or whatever) within XBMC doesn't make it show up in recently added even though it has been in your library for many years.
  
• If you ever have to rebuild your library because it got messed up or you lost it (harddisc crash or whatever) you're recently added list will have the exact same order after re-creating the library as it had before. With the old behaviour the order was pretty much random or rather it was the order the videos appeared in the filesystem (which has definitely nothing to do with when it was added to the library).
  

In the end nobody knows what the majority wants because the majority of xbmc users never makes it into this forum, they just install xbmc and use it. AFAICT the majority of developers in the team prefer the new behaviour so that's what it's gonna be.
I don't really understand why people put so much effort into complaining about having to create an XML. It takes far more time to complain than to create the XML.