[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