PenkethBoy 2063 Posted December 17, 2019 Share Posted December 17, 2019 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. 1 Link to comment Share on other sites More sharing options...
Luke 37057 Posted December 17, 2019 Share Posted December 17, 2019 Thanks for the info. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted December 18, 2019 Author Share Posted December 18, 2019 Thanks - so you will amend then? @@Luke Link to comment Share on other sites More sharing options...
Luke 37057 Posted December 18, 2019 Share Posted December 18, 2019 No, ideally eventually we'd just rename tagitems to tags. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted December 18, 2019 Author Share Posted December 18, 2019 Ok - as you are not providing any backward compatibility - not much point waiting to change over Link to comment Share on other sites More sharing options...
Luke 37057 Posted December 18, 2019 Share Posted December 18, 2019 For this no because we were never really doing much with tags prior to recent development. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted November 18, 2020 Author Share Posted November 18, 2020 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 More sharing options...
Luke 37057 Posted November 18, 2020 Share Posted November 18, 2020 What's the issue? There's nothing to do here. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted November 18, 2020 Author Share Posted November 18, 2020 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 2 Link to comment Share on other sites More sharing options...
Luke 37057 Posted November 18, 2020 Share Posted November 18, 2020 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 More sharing options...
PenkethBoy 2063 Posted November 18, 2020 Author Share Posted November 18, 2020 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 1 Link to comment Share on other sites More sharing options...
Luke 37057 Posted November 18, 2020 Share Posted November 18, 2020 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 More sharing options...
PenkethBoy 2063 Posted November 18, 2020 Author Share Posted November 18, 2020 (edited) 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 November 18, 2020 by PenkethBoy Link to comment Share on other sites More sharing options...
Luke 37057 Posted November 18, 2020 Share Posted November 18, 2020 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 More sharing options...
PenkethBoy 2063 Posted November 19, 2020 Author Share Posted November 19, 2020 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 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? 1 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted November 19, 2020 Author Share Posted November 19, 2020 And to confirm the issue if i add in the Tags then the tags are maintained using this json Post.json Link to comment Share on other sites More sharing options...
CBers 6771 Posted November 19, 2020 Share Posted November 19, 2020 7 hours and no response. I think you've stumped him 1 Link to comment Share on other sites More sharing options...
roaku 795 Posted November 19, 2020 Share Posted November 19, 2020 (edited) 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 November 19, 2020 by roaku 1 Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted November 19, 2020 Author Share Posted November 19, 2020 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 1 Link to comment Share on other sites More sharing options...
roaku 795 Posted November 19, 2020 Share Posted November 19, 2020 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 More sharing options...
PenkethBoy 2063 Posted November 19, 2020 Author Share Posted November 19, 2020 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 More sharing options...
Luke 37057 Posted November 21, 2020 Share Posted November 21, 2020 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 More sharing options...
PenkethBoy 2063 Posted November 23, 2020 Author Share Posted November 23, 2020 @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 More sharing options...
Luke 37057 Posted November 23, 2020 Share Posted November 23, 2020 No that's not getting changed because that would be a breaking API change that would require app updates. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted November 23, 2020 Author Share Posted November 23, 2020 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now