New tv show episode update getting ignored.

[Samkook 12]

When a new episode of a show that hasn't been added yet is getting called by the api for an update, it gets ignored instead of adding the show and then the episode. A scheduled or manual library update will add the show and then the episode updates through the api will work.

Is that intended behavior or is there something extra required for a new show?

I remember doing a few tests with this while writing a script a while back, but had no time to properly report it and now that I have plenty of time, I can't find where the api documentation for updates are anymore so hopefully what I say is clear enough.

I was doing curl calls with an api key and JSON stuff to update movies(which works fine) and figured I'd look into why sickgear won't update new episodes when it's a new tv show.

Would be nice if TV show not in the database would get checked to get added before the episode updates instead of getting ignored until the next library update call.

[Luke 37095]

Hi there, please provide a specific example:

How to Report a Problem

Thanks.

[Samkook 12]

It's a very generic problem so I didn't think it was necessary to use a specific example, sorry for that.

 

Let's say I have sickgear process the first season of the TV show "The Peripheral". That series hasn't been discovered by emby yet since it's a new one I'm adding.

Once sickgear is done processing the episodes, it sends an update api call to emby to tell it to add the episodes to the emby library.

There's 8 episodes in the season so there's 8 times those 2 lines that appear in the log:

2023-08-20 21:14:31.525 Info Server: http/1.1 POST http://192.168.1.14:8096/emby/Library/Series/Updated. UserAgent: SickGear/(FreeBSD; 13.2-RELEASE; c30acb0b-16bf-11ee-9096-a8a1599b6a25)
2023-08-20 21:14:31.526 Info Server: http/1.1 Response 204 to 192.168.1.14. Time: 1ms. http://192.168.1.14:8096/emby/Library/Series/Updated

In this scenario, nothing happens in emby, the series doesn't show up in the library. If the series would have already existed in emby library, the episodes would appear immediately but since it doesn't, I either need to do a manual library update or wait until the scheduled update runs and then it'll appear.

 

As far as I'm aware, the api cannot create tv shows in the library when asked to update episodes like this which is annoying since it happens to me a lot. It's been a while since I checked the api doc for that kind of update so it might have changed and I'm not aware of it(since I can't find how to do this anymore in the api doc I found a few hours ago), but I would have assumed the sickgear guys would have updated it if they could.

Basically, the problem is that emby doesn't create a series if a new episode update for a new series is asked by api and I don't think that's something that can be verified and done with other api calls either(and would seem unnecessary to me to do it that way anyway).

Edited August 21, 2023 by Samkook

[Samkook 12]

I realize that might have not be specific enough if you don't know sickgear.

Sickgear processing it means create a folder in the tv show library location of emby with the series name and put the episodes there.

If I remember how it works right(from looking at my script for movies), the api can only ask for an update on a specific folder, which would be the newly created one for that series in this case, but since emby doesn't know about that folder yet, it gets ignored(I assume) instead of added to the library and then process the request for an update of that folder.

Edited August 21, 2023 by Samkook

[adminExitium 173]

The Library/Series/Updated endpoint has been deprecated for a few years now due to exactly this issue (https://github.com/Sonarr/Sonarr/issues/2662#issuecomment-404996917). The Library/Media/Updated is the recommended way for for notifying Emby of any new or updated media.

[Luke 37095]

Right, /library/media/updated is the way to go because then you're just passing in the actual file paths of what was updated.

[Samkook 12]

Huh, I managed to find the doc for it today(I was searching in documentation instead of reference which is why I couldn't find anything yesterday) and it does work which is weird because that's also what I was using. Maybe I assumed it wouldn't back then because of the wording and never actually properly tested it since it says "movies" instead of "media" in "Reports that new movies have been added by an external source". @softworkz

I was wondering if the value for "UpdateType" was this: https://dev.emby.media/reference/pluginapi/MediaBrowser.Controller.Library.ItemUpdateType.html ?

The Doc doesn't link to anything and wrong values(which I'm fairly certain I'm using since I have "Movies" there for my own script) seem to work so I was curious. If the mediabrowser type is right, I'm assuming wrong is the same as none since none of the other options seem to make sense for a new media update.

[Luke 37095]

35 minutes ago, Samkook said:

Huh, I managed to find the doc for it today(I was searching in documentation instead of reference which is why I couldn't find anything yesterday) and it does work which is weird because that's also what I was using. Maybe I assumed it wouldn't back then because of the wording and never actually properly tested it since it says "movies" instead of "media" in "Reports that new movies have been added by an external source".

I was wondering if the value for "UpdateType" was this: https://dev.emby.media/reference/pluginapi/MediaBrowser.Controller.Library.ItemUpdateType.html ?

The Doc doesn't link to anything and wrong values(which I'm fairly certain I'm using since I have "Movies" there for my own script) seem to work so I was curious. If the mediabrowser type is right, I'm assuming wrong is the same as none since none of the other options seem to make sense for a new media update.

It is Created, Modified or Deleted. But it can also be omitted and the server will figure it out.

[Samkook 12]

Thanks. Any way someone can figure that out from the doc? Might be a good idea to add it if not.

Also, what's a 204 response code? It's not listed in the possibilities and it's what emby is logging.

Also, also, just to be sure, can the path value be empty? Sickgear has a fallback to the new api(in case the old one gets removed) that has both values empty but if I try to call it manually, it tells me it cannot be empty so I just wanted to make sure I didn't do something wrong before relaying that information.

It's also information that seems to be lacking in the doc about which parameters are optional or not as well as default values as far as I can tell, unless I haven't looked at anything that has one.

[Luke 37095]

Quote

Also, also, just to be sure, can the path value be empty?

No it's can't. If the value is empty, then how will the server know what files were updated?

204 response code: https://www.webfx.com/web-development/glossary/http-status-codes/what-is-a-204-status-code/

[Samkook 12]

14 minutes ago, Luke said:

No it's can't. If the value is empty, then how will the server know what files were updated?

It could trigger a complete library update, that's what I'd expect.

It would also fix a lot of issues when the calling app doesn't know the actual local path from the machine running emby server.

Edited August 22, 2023 by Samkook

[Luke 37095]

4 minutes ago, Samkook said:

It could trigger a complete library update, that's what I'd expect.

It would also fix a lot of issues when the calling app doesn't know the actual local path from the machine running emby server.

No doubt. The flip side of course is complaints of unexpected full library scans. There is an api to trigger full scans that could be used if that is the intention.

Quote

It would also fix a lot of issues when the calling app doesn't know the actual local path from the machine running emby server.

Yea this is a scenario that needs review and thought.

[Samkook 12]

1 hour ago, Luke said:

There is an api to trigger full scans that could be used if that is the intention.

Would that be /Library/Refresh ?

Says it requires administrator authentication instead of only user though and I don't see any way to specify that when creating api keys. Do the api keys inherit the permission of the user who created them and can normal user actually create api keys(and where would I see that if they did as the admin)?

[Luke 37095]

Currently only admins can create them, therefore they inherit from that. But we plan to make them more granular in future updates.

[Samkook 12]

So I assume /Library/Refresh is the correct one you were talking about?

[Luke 37095]

1 hour ago, Samkook said:

So I assume /Library/Refresh is the correct one you were talking about?

To run a full scan of all libraries, yes.

[adminExitium 173]

You may also want to look into autoscan with its manual trigger and emby target which can rewrite paths so that it's mapped correctly from the caller to the target.

 

https://github.com/Cloudbox/autoscan/#manual

https://github.com/Cloudbox/autoscan/#emby

[Samkook 12]

1 hour ago, adminExitium said:

You may also want to look into autoscan with its manual trigger and emby target which can rewrite paths so that it's mapped correctly from the caller to the target.

Good to know that exists as an option even though I'm failing to see why one would go through the effort of supporting it(I guess it might replace the emby server in those apps config, still unclear how they all talk to each other and if that's how, it wouldn't work with sickgear as it is now) instead of simply implementing path substitution internally since it looks like it's a lot more work for every users to set that up, but it could be that my setup is too simple for me to see the potential benefit.

The grouping of requests feature does sound potentially useful for people without a powerful server or that want to minimize read on discs as much as possible and now has me wondering how emby handles multiple identical calls at roughly the same time.

For my specific setup, it'd be easier to just manually modify sickgear code to use the new api than set it up, but I was hoping to find a solution they could implement which is proving more problematic than expected.

[adminExitium 173]

Yeah, it's probably not of much benefit if you have a single sickgear instance mapped to a single Emby instance.

But I have 2 each of both Sonarr & Radarr (for non-4k & 4k), 2 Emby instances (prod & beta), 2 Plex instances (prod & beta) and also occasionally try out Jellyfin too so it's a lot easier to do it all from a single config. Autoscan handles any retries, in case the targets are down for whatever reason, and also has support for anchor files so no scans are sent in case the storage gets disconnected/unmounted.

[Samkook 12]

So, tried a dev build of sickgear that uses the new api(Library/Media/Updated) and I still get the same result.

The api call sends "/tome/Series/Blue Thunder" as the Path(also tried with a trailing /) and ""(an empty string) as the UpdateType, which is the actual path to the episode I added and then emby receives it fine:

2023-09-16 21:14:13.062 Debug Server: http/1.1 GET http://192.168.1.14:8096/emby/System/Info/Public. UserAgent: SickGear/(FreeBSD; 13.2-RELEASE; d3774b88-54f3-11ee-9096-a8a1599b6a25)
2023-09-16 21:14:13.063 Debug Server: http/1.1 Response 200 to 192.168.1.14. Time: 0ms. http://192.168.1.14:8096/emby/System/Info/Public
2023-09-16 21:14:13.067 Info Server: http/1.1 POST http://192.168.1.14:8096/emby/Library/Media/Updated. UserAgent: SickGear/(FreeBSD; 13.2-RELEASE; d3774b88-54f3-11ee-9096-a8a1599b6a25)
2023-09-16 21:14:13.067 Info Server: http/1.1 Response 204 to 192.168.1.14. Time: 0ms. http://192.168.1.14:8096/emby/Library/Media/Updated

Then nothing but unrelated debug stuff after that in the log.

Edited September 17, 2023 by Samkook

[Samkook 12]

Hmm, figured out it was because they used ip:8096/emby/Library/media/Updated instead of ip:8096/mediabrowser/Library/media/Updated

Spoke too fast, still doesn't work but a manual call does...

Is the root of that call even documented anywhere? I can't really find it in the api doc.

Edited September 17, 2023 by Samkook

[Samkook 12]

All good, the call was missing the Updates[] part.

 

Still unclear why either "emby" or "mediabrowser" works before "/Library/Media/Updated" or how we're supposed to figure out what to write there from the doc.