[rschiks]

Both in gotham and kodi I have tried to set a new runtime using the methods VideoLibrary.SetMovieDetails and VideoLibrary.SetEpisodeDetails. It gets completely ignored. It returns an OK message. Other items (like plot and title) I can successfully set.

Anyone experienced the same? (before I create a ticket)

[mkortstiege]

Without looking at the code i think it's because we always prefer extraced streamdetails runtime over video infotag value.

[rschiks]

Without looking at the code i think it's because we always prefer extraced streamdetails runtime over video infotag value.

When getting your library using videolibrary.getmovies it doesn't get realtime runtime numbers doesn't it? I thought it would get it once when adding a movie to the library. The runtime is added to the database and using videolibrary.setmoviedetails you can modify database values. Or am I mistaken?

[mkortstiege]

AFAIK you can specify whether or not to get additional information (cast, showlinkg, tag or streamdetails) with getmovies.
I can recall code that always prefers real values from the actual media file so passing runtime via API is kinda useless as it will get replaced anyways. @Montellese will know for sure.

[rschiks]

AFAIK you can specify whether or not to get additional information (cast, showlinkg, tag or streamdetails) with getmovies.
I can recall code that always prefers real values from the actual media file so passing runtime via API is kinda useless as it will get replaced anyways. @Montellese will know for sure.

[rschiks]

AFAIK you can specify whether or not to get additional information (cast, showlinkg, tag or streamdetails) with getmovies.
I can recall code that always prefers real values from the actual media file so passing runtime via API is kinda useless as it will get replaced anyways. @Montellese will know for sure.

Thx for your speedy replies. If it's replaced then you are right.
Maybe a strange scenario in which I use this for. I leave empty files for movies I have watched. The files are 0 bytes, so 0 minutes of runtime. All other info is correct, except the runtime :-(
Because it's still in the library I can also mark it as watched (and filter on it).

[Tolriq]

The problem of the API is that there's 2 different runtime

From JSON the runtime is not the stream runtime, the stream runtime is when asking for streamdetails.

API should be able to update the normal runtime field even if not used when displayed after in the interface as it's available via JSON too.

[rschiks]

The problem of the API is that there's 2 different runtime

From JSON the runtime is not the stream runtime, the stream runtime is when asking for streamdetails.

API should be able to update the normal runtime field even if not used when displayed after in the interface as it's available via JSON too.

:-)
As mkortstiege wrote, I will send Montellese a message.

[Montellese]

I don't really have the full overview over all the different cases for runtime handling either but this is what I remember

• If an item doesn't have streamdetails or the streamdetail runtime is considered invalid (if it's less than 60% of the scraped value) we use whatever value is stored in the runtime database field. That value most likely comes from an NFO or from a scraper. This should be overwritable through JSON-RPC API.
  
• If an item has streamdetails and the runtime is considered valid we overwrite the runtime database field value with the runtime extracted from streamdetails (this has been changed recently). That value is not really overwritable by JSON-RPC because we automatically overwrite it again with the value from streamdetails.
  

The behaviour of the latter case has changed since Helix concerning JSON-RPC. In Helix the value of the runtime field depended upon whether the JSON-RPC client also retrieved the streamdetails property or not. If the streamdetails were not retrieved we returned the runtime database field value. If streamdetails were retrieved we returned the runtime extracted from those streamdetails. In Isengard during a video scan we write the runtime extracted from streamdetails into the runtime database field if streamdetails are available. But changing the value through JSON-RPC should still be possible if you don't also retrieve the streamdetails.

[rschiks]

I don't really have the full overview over all the different cases for runtime handling either but this is what I remember

• If an item doesn't have streamdetails or the streamdetail runtime is considered invalid (if it's less than 60% of the scraped value) we use whatever value is stored in the runtime database field. That value most likely comes from an NFO or from a scraper. This should be overwritable through JSON-RPC API.
  
• If an item has streamdetails and the runtime is considered valid we overwrite the runtime database field value with the runtime extracted from streamdetails (this has been changed recently). That value is not really overwritable by JSON-RPC because we automatically overwrite it again with the value from streamdetails.
  

The behaviour of the latter case has changed since Helix concerning JSON-RPC. In Helix the value of the runtime field depended upon whether the JSON-RPC client also retrieved the streamdetails property or not. If the streamdetails were not retrieved we returned the runtime database field value. If streamdetails were retrieved we returned the runtime extracted from those streamdetails. In Isengard during a video scan we write the runtime extracted from streamdetails into the runtime database field if streamdetails are available. But changing the value through JSON-RPC should still be possible if you don't also retrieve the streamdetails.

Thanks for the explanation. I can confirm I have added the streamdetails as a parameter. I will do some testing without it.