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: | 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)
Change History (21)
by , 13 years ago
| Attachment: | mythfrontend-version.txt added |
|---|
comment:1 by , 13 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:2 by , 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 , 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 , 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 , 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 , 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 , 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 , 13 years ago
| Resolution: | → Invalid |
|---|---|
| Status: | accepted → closed |
comment:9 by , 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:12 by , 12 years ago
| Resolution: | Invalid |
|---|---|
| Status: | closed → new |
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 , 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 , 12 years ago
| Priority: | minor → blocker |
|---|
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 , 12 years ago
| Priority: | blocker → minor |
|---|---|
| Resolution: | → Fixed |
| Status: | new → closed |
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 , 12 years ago
| Resolution: | Fixed |
|---|---|
| Status: | closed → new |
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 , 12 years ago
| Milestone: | unknown → 0.27.1 |
|---|---|
| Status: | new → accepted |
comment:18 by , 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 , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |

Mythfrontend version