Jump to content

ApiClient; Server 3.2.30; Cannot reindex the backdrop image of a movie


Sludge Vohaul

Recommended Posts

Sludge Vohaul

Hi,

I am having problems with reindexing a movie's backdrop image programmatically.

The beginning of this started in thread

 

https://emby.media/community/index.php?/topic/50735-cannot-change-the-backdrop-image-of-a-movie

 

I have two image URLs, one for the Primary image and one for the Backdrop image, which I want to display in Emby for a movie id.

My code makes Emby download the image and reindex it to index=0 if necessary (i.e. only neccessary for the Backdrop image)

This does not work when the code is called asynchronously for both images

 

This is the simplified code:

 

async Task AddImageToMovieAsync(ImageType imageType, Uri imageUrl, string movieId)
{
  var args = new Dictionary<string, string>
  {
    {"Type", imageType.ToString()},
    {"ImageUrl", imageUrl.AbsoluteUri}
  };

  var url = client.GetApiUrl($"Items/{movieId}/RemoteImages/Download");
  await client.PostAsync<EmptyRequestResult>(url, args);

  if (needsReindexing == false) return;

  var index = 3;
  args = new Dictionary<string, string>
  {
    { "NewIndex", "0"}
  };

  url = client.GetApiUrl($"Items/{movieId}/Images/{imageType}/{index}/Index");
  await client.PostAsync<EmptyRequestResult>(url, args);
}
When I invoke the above method like this:

var addTasks = new []
{
  AddImageToMovieAsync(ImageType.Primary, primaryUrl, movieId),
  AddImageToMovieAsync(ImageType.Backdrop, backdropUrl, movieId)
};
await.Task.WhenAll(addTasks);
the backdrop image is not reindexed.

 

When I invoke the above method like this:

var addTasks = new []
{
  AddImageToMovieAsync(ImageType.Backdrop, backdropUrl, movieId)
};
await.Task.WhenAll(addTasks);
The backdrop image is reindexed.

 

In both cases the server replies with HTTP 204 to each re-index request, which seems ok to me.

 

 

A (at least to me) similar issue is described in

 

https://emby.media/community/index.php?/topic/50493-apiclient-getting-a-boxsets-collection-metadata-programmatically/?p=483388

 

where a collection's metadata is not retrieved under certain conditions.

 

Any ideas?

Link to comment
Share on other sites

Without fully diving into it I don't have any idea. All I can tell you is that I don't think these functions have ever been used by the c# apiclient, and therefore they are either out of date with the api or are not consistent with what the javascript version is doing.

Link to comment
Share on other sites

Sludge Vohaul

Ok, I'll sniff the HTTP communication for adding and reindexing and try to issue both requests with curl or something...

 

On the other hand, one can see it positively - we're not controlling a nuclear plant or something :)

Link to comment
Share on other sites

Sludge Vohaul

I think Emby server (this is again 3.2.27, sorry) has an issue when dealing with ImageInfo items.

 

See this Wireshark dump:

GET /emby/Items/5710ceac93cb3cd7728a0bbe6908b208/Images?format=json HTTP/1.1
X-MediaBrowser-Token: 19e03efced1c42edbe9fb1f942278090
X-Emby-Authorization: MediaBrowser Client="P2EApp", DeviceId="000C29C766D8", Device="VM-WIN7-1", Version="0.1.5.0", UserId="32781c844e234b41a6e39399d0233f55"
Host: 192.168.1.68:8096
Accept-Encoding: deflate
Connection: Keep-Alive

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, 
Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, 
Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, 
Range, Slug, Transfer-Encoding, Want-Digest, X-MediaBrowser-Token, X-Emby-Authorization
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Server: Microsoft-NetCore/2.0
Date: Tue, 12 Sep 2017 00:52:54 GMT
Content-Length: 466

[{"ImageType":"Primary","Path":"/var/emby/emby_server/metadata/library/57/5710ceac93cb3cd7728a0bbe6908b208/
poster.jpg","Height":2100,"Width":1400,"Size":711258},
{"ImageType":"Backdrop","ImageIndex":0,"Path":"https://image.tmdb.org/t/p/original/ayj8gjgVm2e1Ey8WFniz8AOGitw.jpg","Size":0},
{"ImageType":"Backdrop","ImageIndex":1,"Path":"/var/emby/emby_server/metadata/library/57/5710ceac93cb3cd7728a0bbe6908b208/backdrop1.jpg","Height":1080,"Width":1920,"Size":649802}]
I don't know yet whether it is related to my problem yet, but the Backdrop at index=0 is the one Emby got "on it's own" from tmdb. Size is 0, width and height are missing completely.

 

The backdrop at index=1 is the image i've added.

 

Will continue investigating tomorrow...

Link to comment
Share on other sites

  • 2 weeks later...
Sludge Vohaul

@@Luke

 

Luke,

 

I've spent some time investigating the reindexing failures, and it seems that it's an issue in the server code.

To eliminate any side effects induced by the apiclient I've dropped it and rewrote the workflow in python using the cURL api.

The script imitates what apiclient does: persistent HTTP connection, parameters in the body, headers generally equal.

 

The results are the same - sometimes the image is reindexed, sometimes not, the server is always happy (HTTP 20x), the logs look fine, too.

The workflow is the following (always starting with a new library (4 movies), default creation settings):

1. Download primary image movie1 request (POST)

2. ImageInfo movie1 request (GET)

3. Download backdrop image movie1 request (POST)

4. ImageInfo movie1 request (GET)

5. Reindex backdrop at index=1 to index=0 movie1 request (POST)

6. Download primary image movie2 request (POST)

7. ImageInfo movie2 request (GET)

8. Download backdrop image movie2 request (POST)

9. ImageInfo movie2 request (GET)

10. Reindex backdrop at index=1 to index=0 movie2 request (POST)

 

The wireshark dump (HTTP) of a failing run of the python script is here:

https://pastebin.com/QzaqDSv6

 

The python script is here:

https://gist.github.com/SludgeVohaul/c6bc104f2ce030750a305b1b6c7bdb74

 

Compared to what the WebUI (browser) does, the sript has 2 differences:

1. The "X-Emby-Authorization" header is different.

2. WebUI posts the parameters in the URL not in the body.

 

I'll rewrite the script to match WebUI requests, and report...

Edited by Sludge Vohaul
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...