Mailing List Archive

On 08/10/2020 15:15, Roland Ernst wrote:
>
>
> On Thu, Oct 8, 2020 at 2:03 PM Paul Gardiner <lists@glidos.net
> <mailto:lists@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/
>
> 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.

On Thu, Oct 8, 2020 at 5:01 PM Paul Gardiner <lists@glidos.net> wrote:

> On 08/10/2020 15:15, Roland Ernst wrote:
> >
> >
> > On Thu, Oct 8, 2020 at 2:03 PM Paul Gardiner <lists@glidos.net
> > <mailto:lists@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/
> >
> > 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?

Roland

On 08/10/2020 16:21, Roland Ernst wrote:
>
>
> On Thu, Oct 8, 2020 at 5:01 PM Paul Gardiner <lists@glidos.net
> <mailto:lists@glidos.net>> wrote:
>
> On 08/10/2020 15:15, Roland Ernst wrote:
> >
> >
> > On Thu, Oct 8, 2020 at 2:03 PM Paul Gardiner <lists@glidos.net
> <mailto:lists@glidos.net>
> > <mailto:lists@glidos.net <mailto:lists@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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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

> On 08/10/2020 16:21, Roland Ernst wrote:
> >
> >
> > On Thu, Oct 8, 2020 at 5:01 PM Paul Gardiner <lists@glidos.net
> > <mailto:lists@glidos.net>> wrote:
> >
> > On 08/10/2020 15:15, Roland Ernst wrote:
> > >
> > >
> > > On Thu, Oct 8, 2020 at 2:03 PM Paul Gardiner <lists@glidos.net
> > <mailto:lists@glidos.net>
> > > <mailto:lists@glidos.net <mailto:lists@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

On 08/10/2020 19:40, Roland Ernst wrote:
> 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?

nfsv4

>  - export options on server?

Here's the client line from /etc/exports:
/tftpboot/ptang-mythtv *(rw,root_squash,sync,no_subtree_check)

>  - mount options on client?

Here's the server line from /etc/mtab:
glidos.site:/tftpboot/ptang-mythtv /home/mythfrontend/.mythtv nfs4
rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.4,local_lock=none,addr=10.0.0.5
0 0

> Do you have SELinux installed or is AppArmor running ?

No, neither of those.

> >> 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

No, thank you! :-)
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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

>
> 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.
>

Paul,
I missed that, sorry.

I've pushed all changes now to fixes/31. The timeout is now limited to 120
secs.

Could you please give it another try?

Thx,
Roland

On 11/10/2020 18:31, Roland Ernst wrote:
>
>
> On Thu, Oct 8, 2020 at 7:11 PM Paul Gardiner <lists@glidos.net
> <mailto:lists@glidos.net>> wrote:
>
>
> 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.
>
>
> Paul,
> I missed that, sorry.
>
> I've pushed all changes now to fixes/31. The timeout is now limited to
> 120 secs.
>
> Could you please give it another try?

It works!!! :-) Interstellar now fetches. Great job Roland. Much
appreciated.


I'm suspicious there's still something not quite right about my nfs set
up. The "-D" step of the fetch took nearly 3 minutes, and all the time I
could hear my server disc being accessed, but the current timeouts seem
long enough to cope.

Cheers,
Paul.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 26 Sep 2020, at 11:44 pm, Paul Gardiner <lists@glidos.net> wrote:
>
> On 23/09/2020 09:10, Paul Gardiner wrote:
>> On 20/09/2020 18:53, Paul Gardiner wrote:
>>> On 20/09/2020 17:11, Peter Bennett wrote:
>>>> On 9/20/20 11:54 AM, Paul Gardiner wrote:
>>>>> On 20/09/2020 10:05, Paul Gardiner wrote:
>>>>>> On 20/09/2020 00:28, jam@tigger.ws wrote:>> On 20 Sep 2020, at 1:57 am, Paul Gardiner <lists@glidos.net> wrote:
>>>>>>>>
>>>>>>>> I've recently updated to 31 from 29.1 and so far run into just one problem. Metadata looked up from within the video player is now generic to the series rather than specific to the episode, so I don't see the episode title or the description of what happens in the episode. There also seems to be a problem with downloading artwork.
>>>>>>>>
>>>>>>>> Anyone else seen similar?
>>>>>>>
>>>>>>> Paul great confusion here. It seems the movie grabber gets different data at different times.
>>>>>>> Also I find (and this must be myth)
>>>>>>>
>>>>>>> I->Change Video->Retrieve
>>>>>>> gets generic metadata
>>>>>>>
>>>>>>> Whereas menu->scan
>>>>>>> retrivies specific data
>>>>>>>
>>>>>>> but the scan way leaves out some movies and the I way is needed. Also the I way does not log what it is doing. I'll play with the logging to see if I can make sense here.
>>>>>>>
>>>>>>> What we need is the developer[s] who crafted this feature to spend a little time polishing the debugging so we can unravel what is happening. The code is complicated and python is alien as it contavenes my personal ethos.
>>>>>>
>>>>>> This may be wrong, but the package dependency changes suggest that there may have been a rework of the xml parsing, using a different API. When I get a chance, I'll see if I can find a corresponding commit and try to find anything that looks dodgy.
>>>>>
>>>>> Looks like the API change was 3 years ago, so I doubt that's what caused the problem: I can't see it staying broken for 3 years.
>>>>>
>>>> Using V31, I have "Preform metadata update after video scan" enabled. After putting video files into the videos storage group on the backend, I run mythutil --scanvideos. It reliably gets the descriptions of each episode for the series I have loaded into videos. Do you have the file names set up correctly? I use a directory name that is the series name and file names that start SnnEnn for example S01E01. Sometimes it gets the same artwork for the whole series and sometimes it gets different artwork for each season. It rarely finds preview images.
>>>
>>> Actually, it works fine for me if I perform a scan, just as Jam claimed earlier. I get the generic data only if I try to retrieve via
>>> Info->Change Video->Retrieve: A choice of program matches is displayed,
>>> and I can choose the correct one (there is only one exact title match). Then, I'd expect to be given the chance to choose Artwork etc., but that
>>> bit of UI never appears. Could I have part of the installation missing,
>>> or might the theme have something missing? I'm using Stepps.
>> I suspect this issue as the cause: https://code.mythtv.org/trac/ticket/13518. I see the problem mentioned in this issue in my logs, and I think the failure to fetch thumbnails may be shortcircuiting some of the code used in selecting best match.
>> As a cause of the issue, I'm suspicious of: https://github.com/MythTV/mythtv/commit/49e987798ace7d125496cbf874b6bcf43791c8fa. In theory, such a change shouldn't cause change in behaviour, but is const foolproof?
>
> I was wrong on both accounts, but I have a partial fix now. This pull request restores the thumbnail and artwork download from ttvdb when manually searching from the Info menu: https://github.com/MythTV/mythtv/pull/235

Being a bear of little brain I do not understand the pull request, and certainly the video metadata is very messed-up, and worse than it was when I wrote the above.
Of the last dozen videos I tried to update, 1 worked om scan, the rest do not retrieve any data (I->change->retrieve)

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 12/06/2021 03:27, James Linder wrote:
>
>
>> On 26 Sep 2020, at 11:44 pm, Paul Gardiner <lists@glidos.net> wrote:
>>
>> On 23/09/2020 09:10, Paul Gardiner wrote:
>>> On 20/09/2020 18:53, Paul Gardiner wrote:
>>>> On 20/09/2020 17:11, Peter Bennett wrote:
>>>>> On 9/20/20 11:54 AM, Paul Gardiner wrote:
>>>>>> On 20/09/2020 10:05, Paul Gardiner wrote:
>>>>>>> On 20/09/2020 00:28, jam@tigger.ws wrote:>> On 20 Sep 2020, at 1:57 am, Paul Gardiner <lists@glidos.net> wrote:
>>>>>>>>>
>>>>>>>>> I've recently updated to 31 from 29.1 and so far run into just one problem. Metadata looked up from within the video player is now generic to the series rather than specific to the episode, so I don't see the episode title or the description of what happens in the episode. There also seems to be a problem with downloading artwork.
>>>>>>>>>
>>>>>>>>> Anyone else seen similar?
>>>>>>>>
>>>>>>>> Paul great confusion here. It seems the movie grabber gets different data at different times.
>>>>>>>> Also I find (and this must be myth)
>>>>>>>>
>>>>>>>> I->Change Video->Retrieve
>>>>>>>> gets generic metadata
>>>>>>>>
>>>>>>>> Whereas menu->scan
>>>>>>>> retrivies specific data
>>>>>>>>
>>>>>>>> but the scan way leaves out some movies and the I way is needed. Also the I way does not log what it is doing. I'll play with the logging to see if I can make sense here.
>>>>>>>>
>>>>>>>> What we need is the developer[s] who crafted this feature to spend a little time polishing the debugging so we can unravel what is happening. The code is complicated and python is alien as it contavenes my personal ethos.
>>>>>>>
>>>>>>> This may be wrong, but the package dependency changes suggest that there may have been a rework of the xml parsing, using a different API. When I get a chance, I'll see if I can find a corresponding commit and try to find anything that looks dodgy.
>>>>>>
>>>>>> Looks like the API change was 3 years ago, so I doubt that's what caused the problem: I can't see it staying broken for 3 years.
>>>>>>
>>>>> Using V31, I have "Preform metadata update after video scan" enabled. After putting video files into the videos storage group on the backend, I run mythutil --scanvideos. It reliably gets the descriptions of each episode for the series I have loaded into videos. Do you have the file names set up correctly? I use a directory name that is the series name and file names that start SnnEnn for example S01E01. Sometimes it gets the same artwork for the whole series and sometimes it gets different artwork for each season. It rarely finds preview images.
>>>>
>>>> Actually, it works fine for me if I perform a scan, just as Jam claimed earlier. I get the generic data only if I try to retrieve via
>>>> Info->Change Video->Retrieve: A choice of program matches is displayed,
>>>> and I can choose the correct one (there is only one exact title match). Then, I'd expect to be given the chance to choose Artwork etc., but that
>>>> bit of UI never appears. Could I have part of the installation missing,
>>>> or might the theme have something missing? I'm using Stepps.
>>> I suspect this issue as the cause: https://code.mythtv.org/trac/ticket/13518. I see the problem mentioned in this issue in my logs, and I think the failure to fetch thumbnails may be shortcircuiting some of the code used in selecting best match.
>>> As a cause of the issue, I'm suspicious of: https://github.com/MythTV/mythtv/commit/49e987798ace7d125496cbf874b6bcf43791c8fa. In theory, such a change shouldn't cause change in behaviour, but is const foolproof?
>>
>> I was wrong on both accounts, but I have a partial fix now. This pull request restores the thumbnail and artwork download from ttvdb when manually searching from the Info menu: https://github.com/MythTV/mythtv/pull/235
>
> Being a bear of little brain I do not understand the pull request, and certainly the video metadata is very messed-up, and worse than it was when I wrote the above.
> Of the last dozen videos I tried to update, 1 worked om scan, the rest do not retrieve any data (I->change->retrieve)

I can explain what was happening and why I made the change. I was never
sure the change was altogether correct but, at the time, it certainly
had positive effects. This change alone was not the final fix for the
problems. It was merged with a whole set of other related changes.
Those, at least for a while, made metadata work well. Possibly, ttvdb
has changed since then.

Before the change, we were wrongly generating image urls of the form

http://www.thetvdb.com/banners/banners/xxxxx

and thumb urls of the form

http://www.thetvdb.com/banners/_cache/banners/xxxxx

To work, they needed to be:

http://www.thetvdb.com/banners/xxxxx

and

http://www/thetvdb.com/banners/_cache/xxxxx


I could have corrected that by just removing "banners/" from second
argument of the concat in both cases, but then the image case would have
involved removing that string and adding it back, which is sort of odd,
so I took the view that the image case should be a simple concat and the
thumb should be achieved by altering the second argument to concat.

I've noticed some problems with metadata just recently, so I wonder if
the site has changed again lately.

Cheers,
Paul.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 12 Jun 2021, at 8:04 pm, Paul Gardiner <lists@glidos.net> wrote:
>
> On 12/06/2021 03:27, James Linder wrote:
>>> On 26 Sep 2020, at 11:44 pm, Paul Gardiner <lists@glidos.net> wrote:
>>>
>>> On 23/09/2020 09:10, Paul Gardiner wrote:
>>>> On 20/09/2020 18:53, Paul Gardiner wrote:
>>>>> On 20/09/2020 17:11, Peter Bennett wrote:
>>>>>> On 9/20/20 11:54 AM, Paul Gardiner wrote:
>>>>>>> On 20/09/2020 10:05, Paul Gardiner wrote:
>>>>>>>> On 20/09/2020 00:28, jam@tigger.ws wrote:>> On 20 Sep 2020, at 1:57 am, Paul Gardiner <lists@glidos.net> wrote:
>>>>>>>>>>
>>>>>>>>>> I've recently updated to 31 from 29.1 and so far run into just one problem. Metadata looked up from within the video player is now generic to the series rather than specific to the episode, so I don't see the episode title or the description of what happens in the episode. There also seems to be a problem with downloading artwork.
>>>>>>>>>>
>>>>>>>>>> Anyone else seen similar?
>>>>>>>>>
>>>>>>>>> Paul great confusion here. It seems the movie grabber gets different data at different times.
>>>>>>>>> Also I find (and this must be myth)
>>>>>>>>>
>>>>>>>>> I->Change Video->Retrieve
>>>>>>>>> gets generic metadata
>>>>>>>>>
>>>>>>>>> Whereas menu->scan
>>>>>>>>> retrivies specific data
>>>>>>>>>
>>>>>>>>> but the scan way leaves out some movies and the I way is needed. Also the I way does not log what it is doing. I'll play with the logging to see if I can make sense here.
>>>>>>>>>
>>>>>>>>> What we need is the developer[s] who crafted this feature to spend a little time polishing the debugging so we can unravel what is happening. The code is complicated and python is alien as it contavenes my personal ethos.
>>>>>>>>
>>>>>>>> This may be wrong, but the package dependency changes suggest that there may have been a rework of the xml parsing, using a different API. When I get a chance, I'll see if I can find a corresponding commit and try to find anything that looks dodgy.
>>>>>>>
>>>>>>> Looks like the API change was 3 years ago, so I doubt that's what caused the problem: I can't see it staying broken for 3 years.
>>>>>>>
>>>>>> Using V31, I have "Preform metadata update after video scan" enabled. After putting video files into the videos storage group on the backend, I run mythutil --scanvideos. It reliably gets the descriptions of each episode for the series I have loaded into videos. Do you have the file names set up correctly? I use a directory name that is the series name and file names that start SnnEnn for example S01E01. Sometimes it gets the same artwork for the whole series and sometimes it gets different artwork for each season. It rarely finds preview images.
>>>>>
>>>>> Actually, it works fine for me if I perform a scan, just as Jam claimed earlier. I get the generic data only if I try to retrieve via
>>>>> Info->Change Video->Retrieve: A choice of program matches is displayed,
>>>>> and I can choose the correct one (there is only one exact title match). Then, I'd expect to be given the chance to choose Artwork etc., but that
>>>>> bit of UI never appears. Could I have part of the installation missing,
>>>>> or might the theme have something missing? I'm using Stepps.
>>>> I suspect this issue as the cause: https://code.mythtv.org/trac/ticket/13518. I see the problem mentioned in this issue in my logs, and I think the failure to fetch thumbnails may be shortcircuiting some of the code used in selecting best match.
>>>> As a cause of the issue, I'm suspicious of: https://github.com/MythTV/mythtv/commit/49e987798ace7d125496cbf874b6bcf43791c8fa. In theory, such a change shouldn't cause change in behaviour, but is const foolproof?
>>>
>>> I was wrong on both accounts, but I have a partial fix now. This pull request restores the thumbnail and artwork download from ttvdb when manually searching from the Info menu: https://github.com/MythTV/mythtv/pull/235
>> Being a bear of little brain I do not understand the pull request, and certainly the video metadata is very messed-up, and worse than it was when I wrote the above.
>> Of the last dozen videos I tried to update, 1 worked om scan, the rest do not retrieve any data (I->change->retrieve)
>
> I can explain what was happening and why I made the change. I was never sure the change was altogether correct but, at the time, it certainly had positive effects. This change alone was not the final fix for the problems. It was merged with a whole set of other related changes. Those, at least for a while, made metadata work well. Possibly, ttvdb has changed since then.
>
> Before the change, we were wrongly generating image urls of the form
>
> http://www.thetvdb.com/banners/banners/xxxxx
>
> and thumb urls of the form
>
> http://www.thetvdb.com/banners/_cache/banners/xxxxx
>
> To work, they needed to be:
>
> http://www.thetvdb.com/banners/xxxxx
>
> and
>
> http://www/thetvdb.com/banners/_cache/xxxxx
>
>
> I could have corrected that by just removing "banners/" from second argument of the concat in both cases, but then the image case would have involved removing that string and adding it back, which is sort of odd, so I took the view that the image case should be a simple concat and the thumb should be achieved by altering the second argument to concat.
>
> I've noticed some problems with metadata just recently, so I wonder if the site has changed again lately.

Paul thanks!
I’ve just been reading what Leslie wrote, and while I’m happy to (and do) build myth from src, I emphasize with the ‘just works’ idea particually with respect to meta data. I’ll pull the latest and see if that affects, but then I’m at a loss of what to do. Hacking the DB springs to mind, maybe even a GUI with the specific aim of dealing with metadata, but that puts me firmly back in the hobbey category.
Cheers
James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org