Jump to content

Beta Server - Tags and TagItems


PenkethBoy

Recommended Posts

PenkethBoy

I was wondering why one of my scripts did not work as expected against the beta server when looking at TAGS

 

It appears that in a JSON response the TAGS are always empty and the data is not returned BUT in TAGITEMS instead

 

Also if you try Fields=TagItems (tested with swagger) neither TAGS or TAGITEMS appear - You have to specify Fields=Tags and both appear.

 

I tested this against Series Tags - not looked at other item types - but guess its the same

 

This change although easy enough to fix in my script will stop other users scripts working who depend on TAGS returning results.

  • Like 1
Link to comment
Share on other sites

PenkethBoy

Ok - as you are not providing any backward compatibility - not much point waiting to change over

Link to comment
Share on other sites

  • 10 months later...
PenkethBoy

well this hot mess is still an issue 11 months later - just been tripped up again by this

Link to comment
Share on other sites

PenkethBoy

yes - there is

if you pull back the full item record - the json TAGS data is blank

edit - some other field - other than tags

post the record back and the TAGS are removed - as the api import sees the TAGS as empty even though the TAGITEMS exist

you get a 204 response BUT all TAGS are removed

If you do the same edit via metadata manager - the tags are maintained so you have some differences in the code somewhere

  • Like 2
Link to comment
Share on other sites

The single item API is working just fine. If that were true then the detail screen would not be able to display them. There's nothing different being done in those locations.

Link to comment
Share on other sites

PenkethBoy

no its not - how many more times do i have to post about this

for instance if i add tags to match the tagitems - it works and maintains the TAGS

if they are absent they get deleted

 

sounds like you have not even tried to test it

 

  • Like 1
Link to comment
Share on other sites

No i haven't because we're not going to support multiple ways of doing the same thing. If there were actually a problem then we'd be seeing it in the emby apps as well. Do what the web app is doing, that is the intended api usage. When you pull down a single item you get all fields. When you use the list api, you have to specify the fields that you want, and yes, you have to specify tags to get tagitems, but you make that little change and then move on.

Link to comment
Share on other sites

PenkethBoy

i am chuff'n doing what the web app is doing - been doing it for years - only problem i get it this tag problem since you messed about last december and have done nothing to fix it since

Edited by PenkethBoy
Link to comment
Share on other sites

I don't really understand what your issue is, unless you're referring to the first post :

Quote

You have to specify Fields=Tags and both appear.

although nowadays Tags is deprecated in favor of TagItems. Yes you have to specify field Tags, sorry but that's what it is right now.

Link to comment
Share on other sites

PenkethBoy

ok - let me try and lay it out so its clear to you what the issue is

# requesting the item
2020-11-19 05:01:53.861 Info Server: http/1.1 GET http://192.168.0.56:8096/emby/users/736ea8cea7124fc6a68917a1574d5a40/items/278
2020-11-19 05:05:35.994 Info Server: http/1.1 Response 200 to 192.168.0.56. Time: 2ms. http://192.168.0.56:8096/emby/users/736ea8cea7124fc6a68917a1574d5a40/items/278
# which should pull back all data for the item - as you need this for editing as emby can only update a whole record not partial

But - as we have discussed Tags is returned empty with the tag info just provided in Taglines - see below

255611071_Annotation2020-11-19051034.jpg.99d1071d8c7d0063ad5cf4bb62b2fa0b.jpg

I then update another field and post back the json to Emby

2020-11-19 05:13:12.036 Info Server: http/1.1 POST http://192.168.0.56:8096/emby/Items/278. UserAgent: Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.19041; en-GB) PowerShell/7.1.0
2020-11-19 05:13:12.039 Debug ProviderManager: Saving F:\EmbyCore\programdata\data\collections\47 Ronin Collection [boxset] to Emby Xml.
...
2020-11-19 05:13:12.043 Info Server: http/1.1 Response 204 to 192.168.0.56. Time: 6ms. http://192.168.0.56:8096/emby/Items/278
# So emby is happy with what was returned - 204

However - the Tag "Test Tag" has been removed from the item on import

====

I tried adding Fields=Tags to the full record request and it had no effect in that no Tags data was returned - so the result was the same as above.

====

Doing the same via the metadata editor - in this case just opening the item and saving

020-11-19 05:17:59.486 Info Server: http/1.1 GET http://localhost:8096/emby/Users/736ea8cea7124fc6a68917a1574d5a40/Items/278
...
2020-11-19 05:17:59.490 Info Server: http/1.1 Response 200 to ::1. Time: 4ms. http://localhost:8096/emby/Users/736ea8cea7124fc6a68917a1574d5a40/Items/278
...
020-11-19 05:18:07.244 Info Server: http/1.1 POST http://localhost:8096/emby/Items/278
2020-11-19 05:18:07.246 Debug ProviderManager: Saving F:\EmbyCore\programdata\data\collections\47 Ronin Collection [boxset] to Emby Xml.
...
2020-11-19 05:18:07.249 Info Server: http/1.1 Response 204 to ::1. Time: 4ms. http://localhost:8096/emby/Items/278

This maintains the tags

I also tried editing the item and then saving - this also maintained the Tags

====

attached are a pre edit json file and a post edit json file - only diff is the the Studio data has been removed

the post json file being returned as the Body of the post

Post.jsonPre.json

====

It looks to me that there is some difference in how the post is handled. - or something else is going on - but currently dont have any ideas on that

The json returned is not malformed (as you can see in the attached files) or the rest of the item metadata would be corrupt and its not.

So do you have any ideas why there would be a difference?

  • Like 1
Link to comment
Share on other sites

 

The json coming back from the web client's api request to /Items/{item id} comes back with TagItems populated but Tags as an empty array.

..."TagItems":[{"Name":"no-kids","Id":11187}],..."Tags":[]...

 

 

Here's an excerpt of the request parameters in the web app's POST to /emby/Items/{item id}:

    TagItems    […]
    0    {…}
    1    {…}
    Taglines    […]
    0    "What's slower than a speeding bullet, and able to hit tall buildings at a single bound?"
    Tags    […]
    0    "no-kids"
    1    "test"

 

Looks like the web app populates the 'Tags' property itself with a string array derived from the TagItem values sometime between getting the Item json but before POSTing the updated metadata.

So, what happens if someone POSTs an update to the api but *doesn't* manually generate a string array for Tags first?

Does the API see the empty array for Tags and make it so?

Edited by roaku
  • Like 1
Link to comment
Share on other sites

PenkethBoy

if i understand what you are saying

then code in the web client is adding Tags to the TAGS array prior to the post sending the json back to the client?

If so then i was right there is a difference and Luke needs to fix this mess

  • Like 1
Link to comment
Share on other sites

I'm on the outside looking in, but that's what appears to be happening.

Have you tried POSTing without the Tags parameter in the request body at all?

Link to comment
Share on other sites

PenkethBoy

not tried that - but emby is picky - you have to post a full record - or it has a strop

so would guess it would fail - or delete them anyway

it must internally still look at TAGS and not TAGITEMS and if they are empty nuke all the tags - should have been sorted ages ago - or not half done as it is now - so we get this mess

Link to comment
Share on other sites

On 11/19/2020 at 11:50 AM, PenkethBoy said:

 

then code in the web client is adding Tags to the TAGS array prior to the post sending the json back to the client?

 

that was done at the time to retain compatibility with older servers, so that's why the metadata editor sends both back when you save. it's been long enough that that can probably be changed now.

Link to comment
Share on other sites

PenkethBoy

@Luke

So when you change this - can i assume that TAGS will be replaced by TagItems and TagItems will be removed?

So we only have one array of Tags (including item id) going forward?

Link to comment
Share on other sites

PenkethBoy

so what if anything is getting changed?

 

On 21/11/2020 at 17:36, Luke said:

that was done at the time to retain compatibility with older servers, so that's why the metadata editor sends both back when you save. it's been long enough that that can probably be changed now.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...