[mardukL]

Hi, short Question.

I like to have a info label to show when an album is added to library but

ListItem.DateAdded is always empty for albums/songs.

Is there any equivalent i am missing here ?

wiki:
ListItem.DateAdded         Shows the date the currently selected item was added to the library / Date and time of an event in the EventLog window.

NOTE:

SortMethod 'DateAdded' is valid for artists,albums,songs

ListItem.Label2 shows the wished infolabel BUT JUST IF i force SortMethod  DateAdded

But i need that label also outside of mymusicnav.xml


Edit: for videos, everthing working fine (movies,shows,episodes)

Edit2:
i prefered advancedsettings

xml:
<dateadded>0</dateadded>    <!--0 results in using the current datetime when adding a song; 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 -->

i tried ommit that line in advancedsettings.xml, resteart kodi and add an artist with albums to library, but the result is the same, ListItem.DateAdded remains empty

[moshep15]

Hi, short Question.

I like to have a info label to show when an album is added to library but

ListItem.DateAdded is always empty for albums/songs.

Is there any equivalent i am missing here ?

wiki:
ListItem.DateAdded         Shows the date the currently selected item was added to the library / Date and time of an event in the EventLog window.

NOTE:

SortMethod 'DateAdded' is valid for artists,albums,songs

ListItem.Label2 shows the wished infolabel BUT JUST IF i force SortMethod  DateAdded

But i need that label also outside of mymusicnav.xml


Edit: for videos, everthing working fine (movies,shows,episodes)

try:

working on kodi 19

ListItem.OriginalDate

MusicPlayer.OriginalDate

[mardukL]

Hi, short Question.

I like to have a info label to show when an album is added to library but

ListItem.DateAdded is always empty for albums/songs.

Is there any equivalent i am missing here ?

wiki:
ListItem.DateAdded         Shows the date the currently selected item was added to the library / Date and time of an event in the EventLog window.

NOTE:

SortMethod 'DateAdded' is valid for artists,albums,songs

ListItem.Label2 shows the wished infolabel BUT JUST IF i force SortMethod  DateAdded

But i need that label also outside of mymusicnav.xml


Edit: for videos, everthing working fine (movies,shows,episodes)

try:

working on kodi 19

ListItem.OriginalDate

MusicPlayer.OriginalDate

Thanks, but thats not the wished label.
Your suggested label shows the Original Release Dates.

I need/want the Label for the Date an item is added to Library


video example using debugoverlay in a list view https://streamable.com/fwowth

[ronie]

perhaps @DaveBlake knows if we have a DateAdded infolabel for albums/songs.

[mardukL]

perhaps @DaveBlake knows if we have a DateAdded infolabel for albums/songs.

Thx. for take look.

As i am not very familiar with programing languages i just track down to look at some files to track down the 'issue' (but i am lost here and i got no idea)

e.g.
XBDateTime.h
https://github.com/xbmc/xbmc/blob/master...DateTime.h
...
void GetAsTimeStamp(KODI::TIME::FileTime& time) const;
...

MusicDatabase.cpp
https://github.com/xbmc/xbmc/blob/master...tabase.cpp
bool CMusicDatabase::AddAlbum(CAlbum& album, int idSource)
   ...   
    // Add dateAdded, dateNew, dateModified to album table
   ...
   ...
/* Update artist dateAdded values for artists involved in album as song or album artists.
Dateadded does NOT hold when the artist was added to the library (that is dateNew), but is
derived from song dateadded values which are usually file dates (or the last scan).

other CMembers
CAlbum::dateAdded() <Album.h>
void CAlbum::SetDateAdded(const std:tring& strDateAdded)
{
dateAdded.SetFromDBDateTime(strDateAdded);
}

CArtist::dateAdded()  <Artist.h>
https://github.com/xbmc/xbmc/blob/68bf07...Artist.cpp
void CArtist::SetDateAdded(const std:tring& strDateAdded)
{
dateAdded.SetFromDBDateTime(strDateAdded);
}
.....
CSong::dateAdded()  <Song.h>   
https://github.com/xbmc/xbmc/blob/68bf07...c/Song.cpp
   value["dateadded"] = dateAdded.IsValid() ? dateAdded.GetAsDBDateTime() : "";

xbmc/utils/FileUtils.cpp
https://github.com/xbmc/xbmc/blob/68bf07...eUtils.cpp
CDateTime CFileUtils::GetModificationDate(const int& code, const std:tring& strFileNameAndPath)
{
CDateTime dateAdded;
if (strFileNameAndPath.empty())
{
CLog::Log(LOGDEBUG, "{} empty strFileNameAndPath variable", __FUNCTION__);
return dateAdded;
}
try
{
std:tring file = strFileNameAndPath;

[DaveBlake]

perhaps @DaveBlake knows if we have a DateAdded infolabel for albums/songs.

The artist, album and songs items on the music nav screens all have date added data in the music infotag part of the fileitem, I can't see off hand if all of the data in the infotag is accessible to skins but I think it all should be @ronie .

However it looks like this has data has either never been exposed as the ListItem.DateAdded info label (which by default is looking at the fileitem itself and not onto the infotag), or maybe it was lost in the major refactoring of CGUIInfoManager for v18?  Matching new labels have been added for newer fields in the tag structure, but no check done for the original fields. So no, we don't currently return ListItem.DateAdded for albums or songs.

Brave effort looking at the code @mardukL , but those were all the wrong parts for what gets exposed to skins. It is more about xbmc\guilib\GUIListItem.cpp, xbmc\guilib\guiinfo\MusicGUIInfo.cpp etc. if you are curious.

Also note that the value in this field depends on the setting in advancedsettings.xml of <musiclibrary><dateadded>
0 use the current datetime when scanning into library is done
1 use the files mtime (if valid) and only using the ctime if the mtime isn't valid
2 use the newer datetime of the file's mtime and ctime
3 use the older datetime of the file's mtime and ctime

Historically using file modified time (option 1) is the default behaviour, people own music for years and then may start using Kodi what matters to them is how long they had the music not when Kodi scanned it. But that has issues if you fix the tagging of some music that has been in your library for years. Others prefer to use 0 - scanning time, but then rescanning your library will show every song or album as added to the library today. My preference is 3 oldest date, I don't care when I scanned it or edited the file just when I first ripped it.

[mardukL]

Ok, thanks.

It is really a minor 'issue', and the time i had invest to lookup for an solution is not worth in the effort (having such label ).
But i cannot stop, and may i can leran little bit.

I checked.
The suggested files.

I understand in my first files lookup (the wrong approach) that the 'string dateadded' values are stored in database using the 'timestamps' in the db based on song.
at least

cpp:
value["dateadded"] = dateAdded.IsValid() ? dateAdded.GetAsDBDateTime() : "";

Now with your help to lookup in the correct files.

- checked guiinfomanager.cpp DATEADDED is in the const infomap for list item labels (expected, as working in video)
- GUIInfoLabels.h :#define LISTITEM_DATE_ADDED         (LISTITEM_START + 114) (expected, as working in video)
- checked xbmc\xbmc\guilib\guiinfo\MusicGUIInfo.cpp, there case LISTITEM_DATE_ADDED is missing

So, i add, placed at last 'enclosing bracket??' belonging to const CMusicInfoTag*
https://github.com/marduklev/xbmc/commit...fc9156d0d0

cpp:


case LISTITEM_DATE_ADDED:

        if (tag->m_dateAdded.IsValid()) // test DATE_ADDED music , may CDateTime is in need to use instead of tag , strDateAdded

        {

          value = tag->m_dateAdded.GetAsLocalizedDate();

          return true;

        }

        break;

So, should i need to compile it for test and go deeper, or do you think its it ?
I think its just needs , but really unsure.

And again, what i also dont understand where label2 is filled
If i switch sort order - label 2 returns the current value if exist for the method, so i am wondered because i assume listitem.dateadded should exist by default....

e.g.in ui container is using  sortby: dateadded, than  label2 is set/filled with info 'dateadded' ?

looked at (GUIListContainer.cpp|h  ; GUIListItemLayout.cpp|h ; expected i should look here  GUIListItem.cpp but i am to stupid in finding the 'dependencie' when label2 is set/filled with an infolabel based on the current container.sortmethod)

[jjd-uk]

Someone from the Team has taken notice of this thread https://github.com/xbmc/xbmc/pull/20018

To my untrained eye it looks to be similair but slightly different to your commit @mardukL so seems like you may have got very close to understanding the correct fix.

[mardukL]

Someone from the Team has taken notice of this thread https://github.com/xbmc/xbmc/pull/20018

To my untrained eye it looks to be similair but slightly different to your commit @mardukL so seems like you may have got very close to understanding the correct fix.

Woho.thanks i follow the conversation there.
glad it's npt merged yet, otherwise i didnt have 'tracked' it.

Thanks.

[black_eagle]

glad it's npt merged yet, otherwise i didnt have 'tracked' it.

It is now!  I'll go for a backport to v19.2 as well as it's been missing for a long time.

BTW, your fix was almost correct but m_dateAdded is a protected variable so you cannot access it directly, you have to use the getter() (in this case GetDateAdded()) to return the value.  If you compile your change then the compiler should flag up that you cannot access that variable directly.

So that you will know in future,

Wrong way (will give a compile error) if (tag->m_dateAdded.IsValid())
Right way if (tag->GetDateAdded().IsValid())

If you look here, https://github.com/xbmc/xbmc/blob/master...#L197-L263 you can see that the first line there is protected:.  That means you can't access any of the variables following that directly, you have to call one of the set/get routines to set or read them.

[mardukL]

Thanks.For take a look, testing, and also provide the needed infos.

i will test them soon.
Also glad it matching the 'rules' for a backport.

Thanks to all involved.