Posts: 126
Joined: Aug 2009
Reputation:
0
Hey ventech who hell ask your opinion? If you'r in disaccord with this 3d don't write again here. Not all are programmers! You are a programmer? So try you to rewrite the db! Insted shut up! No one called you there!
Posts: 26,215
Joined: Oct 2003
Reputation:
187
@BigBlack: Keep things civil please, else you'll just come off looking like an ass.
Posts: 102
Joined: Jan 2010
Reputation:
0
2010-10-04, 08:01
(This post was last modified: 2010-10-04, 08:06 by galvanash.)
I think some of the posts on this thread read a bit on the rude and whiny side... But regardless, this is my (hopefully) rational interpretation of the current state of things and what is being asked for. I'm not for or against it myself, and have no say in it anyway, just documenting it for further discussion...
Currently xbmc does not store last modified or date-scanned-in dates for items. When constructing a recently added view, it simply orders the items by id desc. Recently added in terms of the current feature represents the order in which items were scanned into the library and nothing else.
Pros to this approach:
1. Its simple.
2. It is temporally consistent - changes to the underlying file item over time do not logically affect it, other than removal.
3. Its what everyone is used to up to this point.
4. It does exactly what it says it does.
Cons to this approach:
1. It is self invalidating - if you rescan an item it becomes "newer". That is rarely the desired outcome in practice.
2. For those with multiple installs sharing a media library - it is not consistent across installations.
What is being suggested (I think) by most people on this thread is to instead of track recently added by insertion order track it by the file(s) last modified date (I frankly see no point in keeping a date for when it was scanned in - its not terribly useful and the practical result would be the same).
Pros to this approach:
1. Although it changes the meaning of "recent", in practice both approaches would generate the same result the majority of the time, assuming items were being scanned in the order they were added to the library's source. There are exceptions though...
2. It would be consistent across installations.
3. It would not be affected by rescans or even complete rebuilds of the library.
Cons to this approach:
1. Last modified dates are not reliable. Depending upon how an item is added to a source folder, it may or may not have a last modified date that is consistent with what people would expect it to be (i.e. the date the file was placed in the source folder). This is a pretty big con imo. I just checked my media libarary - I have 6 files with last modified dates in 2014 - don't ask me how but I do...
2. The library would have to be updated when a files last modified date is changed to remain consistent - this would add complexity that doesn't currently exist.
3. It changes the meaning of "recently added" to "recently acquired" or something along those lines. I think those wanting this feature are saying they prefer the later - but it is a rather significant semantic change.
Anyways there it is... I miss anything?
ps. MacGyver's idea sounds really good to me as a compromise... that has my vote.
Posts: 94
Joined: Jul 2009
Reputation:
15
Good points.
The only problem with MacGyver's approach is that it doesn't do much for new users with a large set of media spread out over multiple disks.
Also "recently added" could be left as it is by default, with an option added (you could stick the variable in advancedsettings to avoid cluttering the GUI) to toggle "recently added" to "recently acquired".
Posts: 126
Joined: Aug 2009
Reputation:
0
No galvanash You don't understand.... I say "creation date" not "last modified date". Creation date doesn't change, and it's the time in which the file appear on the hard disk. So like that, nothing change... Library it's always the same on multiple pc users... No problem scanning library after a month or 2... All movies always ordered in the right way.
2 Days ago my database was deleted, by something I don't know... I needed to uninstall XBMC, delete user folders anda re install all, rescan my movies library and now the first new added movie it's one of 2 years ago.... So in this case this was the only solution, and there's no way to solve this order issue with actual XBMC fuction...
And I notice that this is the 4th or 5th time that's appen on my 5 net pc.... And this is the first reason because I need that fuction...
Posts: 126
Joined: Aug 2009
Reputation:
0
But windows user are surely the great part... So they can create that fuction for windows users.. the other will not have this fuction... I don't see this like a real trouble.
Posts: 1,012
Joined: Jan 2007
Reputation:
32
I'll be more clear.
Pre-scan all media to be added to the library, and sort this pre-scan queue by created or modified date, then add them to the library by oldest first.
It would allow the library db to remain the same, but sorting by "Date Added" would appear to sort by creation/modified date. Only a change to the scan/import portion would be needed not the database. Unless they also added an extra setting to "Video Settings" to choose how the pre-scan sort is done ie. "Import by: Date Created" or "Import by: Date Modified", and have the sort label "Date Added" reference whatever sort method was selected in the import settings.
Using a NUC7PJYHN and a 2820FYKH0 Intel NUC running LibreELEC, and two FireTVs.:)
Posts: 1,265
Joined: Oct 2009
Reputation:
29
takoi
Team-Kodi Member
Posts: 1,265
Soring by date added in library mode is now added. In file mode its already there, and it sorts by modified date. Sorting in the import/export process will probably be added soon
Posts: 824
Joined: Jun 2005
Reputation:
6
ventech: Do I understand correctly that your patch currently sorts by ID which is same as it's done in Recently added view, therefore it doesn't solve much what's discussion here about? Guess it will help if ID could be included in nfo file, but how it will behave if there is already existing ID in database? Sorry if I got it wrong, but just wondering...