Automated Tagging

[chef 3746]

Pretty far along now.

Plugin config will have a list of tag rules. They will be editable. You will create tag rules by selecting the pencil button

You can create the conditions of the rules next. If a media item adheres to these conditions tags will be applied.

 

Press the "Add Tags" button, will open the tags dialog. This is where you create the list of tags to add to the rule.

The list will be editable, so you can go back and add or remove tags to your rule condition.

Now that that is almost complete, the next step seems clear. Create a scheduled task which checks through the library for any item which follows the rules, and apply the tags.

Edited January 19, 2021 by chef

[tmb4016 86]

Hi Chef, - looking good. Thanks for the update.

[bakes82 90]

Are you allowing for multi options in years and stuff?

 

Also how are you safely deleting the tags when its modified?  IE you say tag "test" its on PG movies then you change it to only have R movies.  I guess you doing two pulls?  One where tag = "test' and one for the criteria, overlap, remove fall outs?

Edited January 19, 2021 by bakes82

[chef 3746]

1 hour ago, bakes82 said:

Are you allowing for multi options in years and stuff?

 

Also how are you safely deleting the tags when its modified?  IE you say tag "test" its on PG movies then you change it to only have R movies.  I guess you doing two pulls?  One where tag = "test' and one for the criteria, overlap, remove fall outs?

So, I haven't got to tag removal yet. Automatically adding tags is the easy part. Removing and ignoring tags is a whole other thing.

There are a couple things we have to look out for.

One thing is in the scheduled task.

Example: You run the task, and it tags 14 movies, then you change the tags in the rule (by either adding to the tags, or removing a tag) each item the rule has touched in the past will have to be read and changed.

I haven't quite figured out how to handle cases where we need to ignore a tag which was added to the baseItem independently outside the plugin. I'm up for any ideas.

 

Simplest and quickest way to do this, is to over write all the tags on a baseItem when our rule condition is met,  and the tag array is different. Something tells me people won't like that idea... ...

 

The other big thing to look at is when a rule is removed.

If an entire rule is removed, at that moment, we need to move through the libraries (like we did when we created the tags on the baseItems) and remove all tags that were added to the baseItems by  that rule.

When the rule is deleted, it would  be the last time we would have the tag data which needs to be removed. 

 

It is still complicated, and it's definitely on the edge of that rabbit hole. 

 

Perhaps, (just an idea) either you are "all in" on the automatic tagging,  or you are not. Either the plugin runs and handles the tagging of baseItems, or you do it yourself. By using the plugin, it renders the rest of the tagging in emby useless (because it would over write any tags added anywhere else in Emby). 

 

Or, someone else has some good ideas...

 

Oh man, Ive been also wondering about how to add genres to the conditions to best target specific types... It starts to get very complicated quickly.

 

We'll check the saved rules to see if the rule is set already with the conditions applied in the editor.

 

 

 

 

Edited January 19, 2021 by chef

[roaku 795]

A small compromise could be for the plugin to prefix all of its tags with an identifier like 'auto' or something shorter. Maybe even user configurable (edit: although that would require a mass tag update if they ever changed it so nevermind).

That would simplify the plugin maintaining the tags it's responsible for without touching any others.

The cost would be that users would need to remember to include the prefix when using the tags in other contexts like blacklisting.

 

Edited January 19, 2021 by roaku

[ebr 14921]

1 minute ago, roaku said:

A small compromise could be for the plugin to prefix all of its tags with an identifier like 'auto' or something shorter. Maybe even user configurable.

That would simplify the plugin maintaining the tags it's responsible for without touching any others.

The cost would be that users would need to remember to include the prefix when using the tags in other contexts like blacklisting.

 

That would be an extremely messy approach IMO and I wouldn't pursue it.

You are finding out why this isn't in the core yet. It gets complicated fast.

[roaku 795]

17 minutes ago, ebr said:

That would be an extremely messy approach IMO and I wouldn't pursue it.

You are finding out why this isn't in the core yet. It gets complicated fast.

Beyond the user configurable part, which I retracted, I'm not sure what the extra mess is that isn't already inherent to the idea of bulk tagging.

Or put another way, I don't see how any other solution avoids the mess of a system that would support both auto-bulk tagging *and* manual tagging to the same data property. At least with the prefix, there's some indication to the user what the source of the tag is.

Edited January 19, 2021 by roaku

[chef 3746]

12 minutes ago, roaku said:

A small compromise could be for the plugin to prefix all of its tags with an identifier like 'auto' or something shorter. Maybe even user configurable (edit: although that would require a mass tag update if they ever changed it so nevermind).

That would simplify the plugin maintaining the tags it's responsible for without touching any others.

The cost would be that users would need to remember to include the prefix when using the tags in other contexts like blacklisting.

 

 

9 minutes ago, ebr said:

That would be an extremely messy approach IMO and I wouldn't pursue it.

You are finding out why this isn't in the core yet. It gets complicated fast.

If the plugins tags looked like: "auto_4k" or even just "_4k"

It would allow the plugin to manage it's own tagging structure a bit better. You'd certainly know which tags in the list to target for removal, and how to ignore tags that would have been added independently from the plugin.

Edited January 19, 2021 by chef

[rbjtech 4283]

I'm ok with the plugin potentially overwriting any manual tags. 

The truth is I have only set a couple to test how it worked - when I realised that I could not set these on mass, nor easily automate it - then frankly I abandoned the idea as with any sizeable library - manual entry/maintenance is simply not workable.

I don't think prefixing the tag is strictly necessary, but useful to identify what added the tag should the need arise. 

 

[ebr 14921]

If I were doing this, I would have a single option when executing an update - merge (add these if they don't exist) or replace (all tags with these).  When you get to the user interface, having tags labeled "auto-xxx" aren't going to make any sense.

Edit: Perhaps a third option of "delete" would make sense as well for if you wanted to remove a given tag from a group of items.

[roaku 795]

27 minutes ago, ebr said:

If I were doing this, I would have a single option when executing an update - merge (add these if they don't exist) or replace (all tags with these).  When you get to the user interface, having tags labeled "auto-xxx" aren't going to make any sense.

Edit: Perhaps a third option of "delete" would make sense as well for if you wanted to remove a given tag from a group of items.

The flipside is that without a prefix, a user might unknowingly remove an automatic tag through the standard interface, and that item will be 'wrong' until the auto tagging task is re-run.

[bakes82 90]

Make a table for tags, and a junction table between tags and items :P.   Isnt relational data easy?

[chef 3746]

2 hours ago, roaku said:

The flipside is that without a prefix, a user might unknowingly remove an automatic tag through the standard interface, and that item will be 'wrong' until the auto tagging task is re-run.

The task would catch it and out it back. 

 

3 hours ago, ebr said:

If I were doing this, I would have a single option when executing an update - merge (add these if they don't exist) or replace (all tags with these).  When you get to the user interface, having tags labeled "auto-xxx" aren't going to make any sense.

Edit: Perhaps a third option of "delete" would make sense as well for if you wanted to remove a given tag from a group of items.

There is now a 'merge' and a 'replace' option.

Merge is default, but replace can be toggled on.

Looking into a bulk remove option. 

[bakes82 90]

@ebris there not a way to dynamic extend a table with columns a dev or someone wants to add.  Like salesforce, etc.  all you really need is a table of rows with col name. Value.  Table it extends and the pk relationship 

[roaku 795]

23 minutes ago, chef said:

The task would catch it and out it back.

Ya, that's what I said.

There would just be a window of time between the user removing it and the task eventually running again.

But whatever approach is fine. I just wanted to express the pros/cons.

[chef 3746]

This button works now... finally....:

 

On to genres... then this thing is testable.

[ebr 14921]

10 minutes ago, chef said:

On to genres

Not sure how this type of logic would apply to genres...

[chef 3746]

12 minutes ago, ebr said:

Not sure how this type of logic would apply to genres...

I was thinking genres could be used to zero in on baseItems.

But, perhaps the conditions are good the way they are.

We can always add more later, if it is requested.

 

[ebr 14921]

1 minute ago, chef said:

I was thinking genres could be used to zero in on baseItems.

Ah, okay, as a selection criteria.  I thought you were going to make it so it would write genres (instead of tags).

[chef 3746]

On 1/18/2021 at 8:57 PM, bakes82 said:

There is no flag, its based by resolution, and HVEC etc I only found in the "title" if I recall.

This is what I use.

var is4K = mediaSourceItem.VideoStream.Height <= 2160 &&

mediaSourceItem.VideoStream.Width <= 4096 &&

mediaSourceItem.VideoStream.Height > 1080 &&

mediaSourceItem.VideoStream.Width > 1920;

if (!is4K) is4K = mediaSourceItem.VideoStream.DisplayTitle.ToLower().Contains("4k");

@bakes82 where do you find VIdeoStream object? Are you using IMediaSourceManager?

Edited January 22, 2021 by chef

[roaku 795]

If you have a MediaStream, that will have the Width, Height, and DisplayTitles properties on it and you can use its Type to make sure it's a Video.

Edited January 22, 2021 by roaku

[chef 3746]

17 minutes ago, roaku said:

If you have a MediaStream, that will have the Width, Height, and DisplayTitles properties on it and you can use its Type to make sure it's a Video.

Is there a way of requesting the width through the baseItem? I've got a bit caught up on this part

[bakes82 90]

39 minutes ago, chef said:

@bakes82 where do you find VIdeoStream object? Are you using IMediaSourceManager?

https://github.com/bakes82/Emby_KillStreams/blob/b4e276289417f1ad1529232ef67ed22753e331f7/KillStreams/KillStreamScheduledTask.cs#L46

[bakes82 90]

The issue is a base item can have multi sources correct?  720p, 1080p?  So you need to get the info from the media source.

[roaku 795]

2 minutes ago, chef said:

Is there a way of requesting the width through the baseItem? I've got a bit caught up on this part

Call BaseItem.GetMediaStreams(), then pick the Video out of the list.