Opened 11 years ago

Closed 8 years ago

#11678 closed Bug Report - General (Fixed)

Video metadata downloads the least popular fanart from tmdb

Reported by: anonymous@… Owned by: Raymond Wagner
Priority: minor Milestone: 0.27.5
Component: MythTV - General Version: Unspecified
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This is seen with current master. It has been an issue for well over a year as well. I have seen at least one other person mention this on the users list and it was dismissed as a false report.

When a query to tmdb returns multiple rows for fanart, the last one is downloaded and used. This is the lowest rated from tmdb and should not be the one used.

Simply changing tmdp3.py to use m.images.insert(0,{...}) rather than m.images.append({...}) (reverses the sort) for fanart results in the proper image being used. I assume, however, that the fix should actually be in myth's code. Coverart also uses the append method and the first item is downloaded in that case.

On another note, if you reset all metadata for a video, it does not delete the existing fanart. When you then retrieve details, it also does not overwrite the existing image. Unless you manually delete the image, you cannot replace it with an updated one. To refresh an image, one has to both delete the fanart file and clear their themecache entry which is cumbersome.

Change History (7)

comment:1 Changed 11 years ago by Raymond Wagner

Milestone: unknown0.26.1
Owner: set to Raymond Wagner
Status: newaccepted

comment:2 Changed 11 years ago by Raymond Wagner <rwagner@…>

Resolution: fixed
Status: acceptedclosed

In da8ac305c3dbe955459a6a12e646b81109552836/mythtv:

Fix metadata fanart selection.

When artwork is processed from metadata grabber results, the artwork is
put into a QMultiMap, indexed based off the type. When pulling values
back out of a QMultiMap, they are in reverse order from how they were
inserted. Since the grabber is assumed to place the highest rated
artwork at the top of the response list, it must be pulled back out of
the bottom of the QMultiMap.

Commit c3d64c80 made this change for all artwork types by fanart. Fanart
had special handling, to allow it to select different artwork for each
season of a television show. However, the logic used to select the
artwork resulted in being indexed from the beginning of the list, rather
than indexed from the back of the list, thus pulling the lowest rated
artwork rather than the highest.

Fixes #11678

comment:3 Changed 11 years ago by Raymond Wagner <rwagner@…>

In ce8f07005d607d1b6578e1085c796d0eafe490ce/mythtv:

Fix metadata fanart selection.

When artwork is processed from metadata grabber results, the artwork is
put into a QMultiMap, indexed based off the type. When pulling values
back out of a QMultiMap, they are in reverse order from how they were
inserted. Since the grabber is assumed to place the highest rated
artwork at the top of the response list, it must be pulled back out of
the bottom of the QMultiMap.

Commit c3d64c80 made this change for all artwork types by fanart. Fanart
had special handling, to allow it to select different artwork for each
season of a television show. However, the logic used to select the
artwork resulted in being indexed from the beginning of the list, rather
than indexed from the back of the list, thus pulling the lowest rated
artwork rather than the highest.

Fixes #11678
(cherry picked from commit da8ac305c3dbe955459a6a12e646b81109552836)

comment:4 Changed 10 years ago by Raymond Wagner

Resolution: fixed
Status: closednew

There are reports of this issue still existing. I'm re-opening this so I don't forget it when I have a chance to look into it again.

comment:5 Changed 9 years ago by skd5aner@…

Please see #12246 for troubleshooting and solution (essentially, reverting this commit fixes it).

comment:6 Changed 9 years ago by Stuart Auchterlonie

Milestone: 0.26.10.27.6

comment:7 Changed 8 years ago by Karl Egly

Milestone: 0.27.60.27.5
Resolution: Fixed
Status: newclosed

As per comment:5 this has been fixed by reverting the fix that fixed it. (We fixed one wrong of two wrongs that did make one right, thus making it wrong. Oh my this is confusing. The results were being reversed in multiple places.)

Lets track the issue with caching the old image separately, maybe in #12274. The image order issue is confusing enough without it.

Note: See TracTickets for help on using tickets.