1) What if the server doesn't have that id in the database,
2) or what if you have multiple series folders with the same id.
3) That's why a more primitive approach is better. Just tell the server what files have changed.
To your q:1 why wouldn't it have an id, it always has. Of course, that id is TVDBid, and it is perhaps this id that you are trying to move away from, given recent events. But those recent bumps in the road are now settling and their API is returning more and more data on v3. To the point where we have been able to fully remove v1 support now that finally, v3 carries all of the thumb data. Also, TVDB is still by far the most comprehensive and uptodate source to the majority of shows - in our test results.
To your q:2 not sure why this would occur (hasn't ever here) so maybe this is a hypothetical rather than practical concern, but yeah, perhaps scan all related paths and mapped paths for this use case.
To your 3: I'm not so sure this "more primitive approach" is better than current Emby because it requires Emby to string match a supplied path to a show. A string comparison is more prone to errors and raises other issues (e.g. Lin/Win path differences, Win long paths, mapped paths, network/remote/UNC paths, syncing changes to show path between client and Emby); it's also more processor taxing and way less efficient than the far more direct ID approach.
If the '/Media/Updated' with param 'Path' is pushed and the other endpoint removed, we will fall back to requesting Emby scan the entire library every time a new media file is available, that way, less for us to worry over - of course this means a substantial backstep in terms of performance as SSDs/HDDs will be far more busy - but a reliable trusted outcome is the key priority over struggling with inevitable path matching issues.
Series id isn't a great way of doing it.
Up to now, `/Library/Series/Updated` using TvdbId POST param has proven flawless for our users, and we can't rock the boat with this big of a change leading up to xmas. The other small issue we found is now handled by using POST for a full library scan instead of GET. I guess, as the docs are not yet clear and binding that things are still subject to change, so we wait for your direction
Edited by JackDandy, 29 November 2019 - 11:00 AM.