Opened 10 years ago
Closed 10 years ago
Last modified 10 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)
Changed 10 years ago by
Attachment: | mythfrontend-version.txt added |
---|
comment:1 Changed 10 years ago by
Owner: | set to Raymond Wagner |
---|---|
Status: | new → accepted |
comment:2 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
Resolution: | → Invalid |
---|---|
Status: | accepted → closed |
comment:9 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
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 Changed 10 years ago by
Milestone: | unknown → 0.27.1 |
---|---|
Status: | new → accepted |
comment:18 Changed 10 years ago by
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 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Mythfrontend version