[mythtv-users] Metadata is generic in v31

[Paul Gardiner]

On 08/10/2020 16:21, Roland Ernst wrote:
> 
> 
> On Thu, Oct 8, 2020 at 5:01 PM Paul Gardiner <lists at glidos.net 
> <mailto:lists at glidos.net>> wrote:
> 
>     On 08/10/2020 15:15, Roland Ernst wrote:
>      >
>      >
>      > On Thu, Oct 8, 2020 at 2:03 PM Paul Gardiner <lists at glidos.net
>     <mailto:lists at glidos.net>
>      > <mailto:lists at glidos.net <mailto:lists at glidos.net>>> wrote:
>      >
>      >
>      >      >> Maybe you are hit because of a too small timeout ?
>      >      >> See https://github.com/MythTV/mythtv/pull/199
>      >      >> This is currently only on master fixed.
>      >      >
>      >      > I wondered that too. I'll take that commit on too and see
>     if it
>      >     helps.
>      >      >
>      >      > I'll get those logs beforehand in any case.
>      >
>      >     Here's the log.
>      >
>      >
>      > The execution of tmdb3.py from the provided log file took 43 secs
>     on my
>      > side.
>      > So it is enough to change line 292 in that file to the same value
>      > fixes/31 is using:
>      >
>      > /signal.alarm(60)/
>      >
>      > Then do a
>      >
>      > /sudo python3 -m compileall
>     /usr/share/mythtv/metadata/Movie/tmdb3.py/ <http://tmdb3.py/>
>      >
>      > and it should work.
>      >
>      > Do not forget to clear the tmdb3 cache:
>      >
>      > /rm ~/.mythtv/cache/pytmdb3.cache/
>      >
>      > If it works, I will merge all the changes to the fixes/31 branch
>     asap.
> 
>     No, that didn't work, but it did add an extra line to the logs
>     (attached) Child killed with Terminated. I wonder whether the C also
>     has
>     a timeout.
> 
> 
> Since it terminated the call to tmdb3.py in the same second, I wonder what
> it does if you call it directly from the terminal:
> Clear the tmdb3 cache as outlined above and run
> /usr/share/mythtv/metadata/Movie/tmdb3.py -l en -a GB -D 157336
> 
> Does this return a valid and complete xml?

Actually, that's not in the same second: it's exactly 60s later, and it 
does that even if I make the timeout in the python code 120s.

Regardless, I performed the experiment you suggested. The command seems 
to return valid and complete xml as far as I can see. It even does so 
with the timeout at 30s, but then not reliably. Works sometimes not others.

Also, if after a successful run, I leave the cache unchanged and do a 
Retrieve from mythfrontend, it works (probably not surprisingly), but 
even with 120s timeout in the python code, if I blow the cache, the 
frontend cannot retrieve.

This is all running on an Atom CPU, and the cache is on an NFS share, 
albeit across a 1000base-T network, in case that's relevant.

Paul.