[mythtv-users] Metadata is generic in v31

Roland Ernst rcrernst at gmail.com
Thu Oct 8 18:40:38 UTC 2020


On Thu, Oct 8, 2020 at 7:11 PM Paul Gardiner <lists at glidos.net> wrote:

> 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.
>
>
Paul,
I run myself multiple Atoms with Nvidia ION Graphics as frontend and
started to test mythtv v31 on that frontends.
I really want to keep them, as long as possible.
Maybe I can reproduce your setup.
Some questions:
 - nfsv3 or nfsv4?
 - export options on server?
 - mount options on client?

Do you have SELinux installed or is AppArmor running ?

>> if I blow the cache, the frontend cannot retrieve.
Please give me some time to reproduce this setup.

Thx for all your effort on supporting this issue,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20201008/813d91be/attachment.htm>


More information about the mythtv-users mailing list