[zachmorris]

As an aside, for these properties I think a future Kodi version could clean this up more.
date
InfoTagVideo has SetPremiered, setFirstAired, setYear
InfoTagMusic has setReleaseDate and setYear
InfoTagPicture has setDateTimeTaken but not setYear
InfoTagGame has setYear, but not setReleaseDate

date seems like it could go away completely assuming the tags for each InfoTag type are cleaned up and more or less common.
In general, it seems like a setPremeriedYear can be abstracted from SetPremiered and a setFirstAiredYear could be abstracted from setFirstAired (i.e you set one and they're both set, but you also have the ability to seperately set just the *Year assuming the *Premiered or *FirstAired is unknown).

count
InfoTagVideo has setPlaycount
InfoTagMusic has setPlaycount
InfoTagPicture has nothing equivalent
InfoTagGame has nothing equivalent

count seems like it could go away completely assuming the tags for each InfoTag type are cleaned up and all have an equivalent setPlaycount

overlay
Nothing has an equivalent, but looking at the docs I dont even understand what this is used for

size
Nothing has an equivalent, but I think this is pretty obviously a good thing to be able to tag for each type of item to identify it's size (in bytes)

[jbinkley60]

size
Nothing has an equivalent, but I think this is pretty obviously a good thing to be able to tag for each type of item to identify it's size (in bytes)

I am curious on this one.  I have never set the size value on a listitem and from everything I can see there is no Kodi database value for it in any table.  The Kodi players don't require it for playing an item and things like streams won't have a size value.  I agree it seems like it should be something of value but it isn't even a Kodi smart playlist variable to filter on.  I am missing the use case but it feels like it should be obvious.


Thanks,

Jeff

[zachmorris]

size
Nothing has an equivalent, but I think this is pretty obviously a good thing to be able to tag for each type of item to identify it's size (in bytes)

I am curious on this one.  I have never set the size value on a listitem and from everything I can see there is no Kodi database value for it in any table.  The Kodi players don't require it for playing an item and things like streams won't have a size value.  I agree it seems like it should be something of value but it isn't even a Kodi smart playlist variable to filter on.  I am missing the use case but it feels like it should be obvious.


Thanks,

Jeff

I currently use it in IAGL so the user can sort by size if they like (xbmcplugin.SORT_METHOD_SIZE), and use a custom window that will show the user the size of the file before they download it. Coincidentally, i shoe horn the addon to show the listitems as video's mainly because the InfoTags that are available for videos are more plentiful, and many of them fit right in with Games, and because Games are not in the Kodi database (yet? One can dream).

[jbinkley60]

I currently use it in IAGL so the user can sort by size if they like (xbmcplugin.SORT_METHOD_SIZE), and use a custom window that will show the user the size of the file before they download it. Coincidentally, i shoe horn the addon to show the listitems as video's mainly because the InfoTags that are available for videos are more plentiful, and many of them fit right in with Games, and because Games are not in the Kodi database (yet? One can dream).

Thanks for curing my curiosity.  I normally add sort methods like date, title (ignore the), duration etc.  I have never considered size and since I don't populate it in the listitems it wouldn't have worked anyway


Jeff

[jurialmunkey]

@zachmorris

Date I currently already redirect to setPremiered etc on this assumption

Count != playcount. As far as I understand count is used as a positioning ID for sorting purposes (eg a sort of "rank" value). There's no equivalent.

Size obviously no equivalent.

Overlay *used to* be used to set watched status in Listitem.Overlay (value 4&5 was OverlayWatched.png and OverlayUnwatched.png). However I'm fairly sure this is now depreciated and does nothing in Nexus. The listitem.overlay icon appears to be now solely determined by playcount for episodes/movies/videos mediatype and by unwatchedepisodes count for tvshows/seasons mediatype. Which is how it should be imho.

[jurialmunkey]

@jurialmunkey i have another deprecated message which is not implemented in your script:

Code:


"resumetime" in ListItem.setProperty() is deprecated and might be removed in future Kodi versions. Please use InfoTagVideo.setResumePoint()


can you pls implemented it?

@bbaron - I ended up deciding to implement something for resume_time which will be in update to next version v0.0.5

https://github.com/jurialmunkey/script.m...4c0a551e11

Should be fairly straight forward. It requires your infoproperty key names to be named "ResumeTime" and "TotalTime" (case sensitive).

python:


# Set resume point by popping ResumeTime and TotalTime keys from infoproperties

info_tag.set_resume_point(infoproperties)

However, there is an option to change these key names if your infoproperties dictionary uses lowercase or camelCase instead. You can also change pop_keys to False if you don't want to pop them for whatever reason.

python:


# Set resume point by popping resumetime and totaltime keys from infoproperties

info_tag.set_resume_point(infoproperties, resume_key='resumetime', total_key='totaltime')



# Set resume point by getting keys instead of popping

info_tag.set_resume_point(infoproperties, pop_keys=False)

I'll make a PR for official repo once I sort out a solution for the above discussion with Zach about count/size/date etc.

[jbinkley60]

Has anyone looked at the differences between listitem.setInfo for pictures and InfoTagPicture ?    There doesn't seem to be much, if any, correlation between the two.  For instance setInfo has  title, picturepath and exif.  InfoTagPicture has setResolution and setDateTimeTaken.  So like setArt it can be combination of the two methods under Kodi 20 or leave as setInfo until additional tags are implemented in the future for InfoTagPicture. 


Thanks,

Jeff

[zachmorris]

I'll make a PR for official repo once I sort out a solution for the above discussion with Zach about count/size/date etc.

I tried modifying your script in a similar way for size/date but couldn't figure out a pythonic way to add a custom attribute to the builtin getVideoInfoTag/getMusicInfoTag/getGameInfoTag, or to reroute the setting of those specific keys back to the listitem directly. It seems like we'd have to add a custom attribute to the builtin, and in my googling / stackexchanging I couldn't figure it out.

[jurialmunkey]

I'll make a PR for official repo once I sort out a solution for the above discussion with Zach about count/size/date etc.

I tried modifying your script in a similar way for size/date but couldn't figure out a pythonic way to add a custom attribute to the builtin getVideoInfoTag/getMusicInfoTag/getGameInfoTag, or to reroute the setting of those specific keys back to the listitem directly. It seems like we'd have to add a custom attribute to the builtin, and in my googling / stackexchanging I couldn't figure it out.

@zachmorris

Sorry it took me a while to get to this. v0.0.7 of infotagger is now in the official repo.

I ended up going with a slightly different approach that collects up these old infolabels into a dictionary so they can be set in one go via setInfo rather than individually manage them.

If you just use the ListItemInfoTag like previously then it will simply skip count/size/date. However, there's also a new "set_info_tag()" method which handles creating ListItemInfoTag object, setting count/size/date via listitem.setInfo(), and then setting other infolabels via new methods. It returns the ListItemInfoTag object so that you can use it to set other things like cast or stream details rather than needing to remake it.

Usage:

python:


from infotagger.listitem import set_info_tag



# Generate class object and set infolabels # Replaces using ListItemInfoTag()

info_tag = set_info_tag(listitem, infolabels, tag_type='video')  # tag_type optional and defaults to 'video'



# Set other methods like cast

info_tag.set_cast(cast)

See here for how it works: https://github.com/jurialmunkey/repo-scr....py#L9-L20

[zachmorris]

Thanks, I'll give it a try. Also take note that another PR for infotags has been added that may effect infotagger:
https://github.com/xbmc/xbmc/pull/23055

[jurialmunkey]

Thanks, I'll give it a try. Also take note that another PR for infotags has been added that may effect infotagger:
https://github.com/xbmc/xbmc/pull/23055

Ah that's interesting. If I'm reading it correctly, I don't think it'll affect infotagger too much though.

As far as I gather, that's about setting the full info tag back to an existing listitem to ensure it updates in memory.

You can always get the info tag from infotagger by the _info_tag internal attribute. So then you simply pass it back to that setter ie

li.setVideoInfoTag(info_tag._info_tag)