Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#11876 closed Bug Report - General (fixed)

tmdb3.py succeeds, but claims metadata lookup failed (v.27)

Reported by: acorttam@… Owned by: Raymond Wagner
Priority: minor Milestone: 0.27.1
Component: MythTV - Mythmetadatalookup Version: 0.27-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Metadata lookup worked for me before upgrade to 0.27.

Running the grabber CLI results in a few listings, but from the MythVideo interface, retrieval fails. mythfrontend.log shows a valid CLI, but claims lookup failure.

Sep 22 20:19:54 zap mythfrontend.real: mythfrontend[2649]: I MetadataDownload metadatadownload.cpp:280 (runGrabber) Running Grabber: /usr/share/mythtv/metadata/Movie/tmdb3.py -l en -a US -M OBLIVION Sep 22 20:19:54 zap mythfrontend.real: mythfrontend[2649]: I MetadataDownload metadatadownload.cpp:186 (run) Metadata Lookup Failed: No Results OBLIVION 0 0 Sep 22 20:19:54 zap mythfrontend.real: mythfrontend[2649]: I CoreContext videodlg.cpp:3340 (customEvent) No results found for OBLIVION 0 0

Attachments (1)

mythfrontend-version.txt (871 bytes ) - added by Matt R <acorttam@…> 13 years ago.
Mythfrontend version

Download all attachments as: .zip

Change History (21)

by Matt R <acorttam@…>, 13 years ago

Attachment: mythfrontend-version.txt added

Mythfrontend version

comment:1 by Raymond Wagner, 13 years ago

Owner: set to Raymond Wagner
Status: newaccepted

comment:2 by Raymond Wagner, 13 years ago

Works fine here. Perhaps you got some bad data on the first query and now it's cached. Try deleting ~/.mythtv/pytmdb3.cache.

comment:3 by Matt R <acorttam@…>, 13 years ago

Thanks for the pointer to cache... deleting the cache didn't help, but got me looking at it further. I fired up another one of my frontends with 0.27 and it seems to be doing metadata lookups just fine against the same backend.

Any other environmental areas I can look at? Lookups fail for all videos, not just the one example.

comment:4 by Raymond Wagner, 13 years ago

Check to make sure where ever $MYTHCONFDIR/pytmdb3.cache or $HOME/.mythtv/pytmdb3.cache is located, based off the environment the frontend is running within, is writable by the user running the frontend.

comment:5 by acorttam@…, 13 years ago

Permissions look okay to me.. If I delete the file, it is regenerated by the mythmetadatalookup crontab process that seems to run okay.

However, the manual lookup via the MythVideo interface fails almost immediately.. too quickly for it to have executed the tmdb3.py script...

comment:6 by Matt R <acorttam@…>, 13 years ago

More testing... if I run mythfrontend as root, the lookup works.. Will have to troubleshoot further to figure out what's going on... certainly feels like permissions.

comment:7 by Matt R <acorttam@…>, 13 years ago

Okay.. got it. Thanks for the help.

FYI, it was permissions.. I assumed it was trying to use /home/mythtv/.mythtv/pytmdb3.cache but using 'strace' I found it was failing on its own $HOME/.mythtv/pytmdb3.cache .. The owner on its own .mythtv directory were root.root. It has probably been that way for a while, but didn't notice it until the switch to tmdb3.py and the required creation of the cache file.

Hope this helps someone else. Cheers!

comment:8 by Raymond Wagner, 13 years ago

Resolution: Invalid
Status: acceptedclosed

comment:9 by Argus <pthorn-mythd@…>, 12 years ago

I had the same thing happen to me, but different cause. It turned out that my startup script failed to set $HOME for mythfrontend due to the environment it operates in.

After I set $HOME to what it should have been: success.

One must ensure that something supports tilde expansion, as tmdb3.py tries to open ~/.mythtv/pytmdb3.cache and fails immediately if it can't. The generic error message doesn't really help when it fails this way, but I don't think anything really needs to be "fixed." In a properly configured environment everything seems fine.

comment:10 by Raymond Wagner <rwagner@…>, 12 years ago

In 2c50a824be1f3083ca966ff0309ea39854452b29/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available

comment:11 by Raymond Wagner <rwagner@…>, 12 years ago

In 65668cd6b98f36532fd478f4b6c491a8273c467e/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available

comment:12 by JYA, 12 years ago

Resolution: Invalid
Status: closednew

Seeing a similar issue on the mac.

running manually tmdb python after deleting /Users/jyavenard/.mythtv/cache/pytmdb3.cache fail.

$ PYTHONPATH=~/Work/mythtv/.osx-packager/build/lib/python2.6/site-packages ~/Work/mythtv/.osx-packager/build/share/mythtv/metadata/Movie/tmdb3.py  -l en -a GB -M "Toy Story"
/Users/jyavenard/Work/mythtv/.osx-packager/build/lib/python2.6/site-packages/MythTV/dataheap.py:63: DeprecationWarning: object.__new__() takes no parameters
  return super(Artwork, cls).__new__(cls, attr, parent, imagetype)
Unable to access cache file: /Users/jyavenard/.mythtv/cache/pytmdb3.cache

If I do: $ touch /Users/jyavenard/.mythtv/cache/pytmdb3.cache

and re-run the above command, it works

comment:13 by JYA, 12 years ago

looking at the code, it tests if the file exists, but if the file doesn't exists it simply exits with an error and do not attempt to create it.

comment:14 by JYA, 12 years ago

Priority: minorblocker

upgrading this priority to blocker.

As it is, metadata retrieval *will* fail on any new install and will only work on system where the ~/.mythtv/pytmdb3.cache already exists

comment:15 by Raymond Wagner, 12 years ago

Priority: blockerminor
Resolution: Fixed
Status: newclosed

tmdb3.py will create the file pytmdb3.cache if it does not exist. This issue is that it will not work backwards and create any higher level directories. The script will either be run on the frontend through the Video Library, or on the backend through mythmetadatalookup or the services API. In either scenario, mythfrontend or mythtv-setup will have been run, creating that directory in which to store the theme cache. The script should be creating the directory if it does not exist (or really the upstream library handling the cache file), but this is a situation that should never exist on an operation system. You're only experiencing it because you've created a completely fresh system, and are calling the script manually for testing purposes.

In any case, this issue is unrelated to the original ticket.

comment:16 by JYA, 12 years ago

Resolution: Fixed
Status: closednew

Your analysis is wrong.

Please take some time to look at it before closing it.

The scripts test if the tmdb3.cache file exists and is accessible for both read and write.

If not, the script will exit.

That new behavior was introduced in your February fix.

It has nothing to do with running the script on its own, or the directory not existing.

If the file doesn't exist, it will exit with an error, never giving the opportunity for the cache file to be created

THAT is the error

comment:17 by Raymond Wagner, 12 years ago

Milestone: unknown0.27.1
Status: newaccepted

comment:18 by slackerlinux85@…, 12 years ago

just a FYI this also happens with the thetvdb script in master(0.28). ran into both of these when i did a freshinstall last weekend

comment:19 by Raymond Wagner <rwagner@…>, 12 years ago

Resolution: fixed
Status: acceptedclosed

In ec084b39099d2ea43a736ac46caffad90272ef9d/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available

comment:20 by Raymond Wagner <rwagner@…>, 12 years ago

In b93fb14831a0ca8d59a7df5267c04cb6e52d9254/mythtv:

Error: Processor CommitTicketReference failed
GIT backend not available
Note: See TracTickets for help on using tickets.