metadata lookup failing with exit code 128

[jfabernathy]

In an attempt to test the RPi4 commercial flagging on V31 on a RPi4, I recorded some programs with post-processing options lookup metadata and commercial flagging.
Commerical flagging worked, but Metadata lookup fail with exit code 128.

From an old post I found that if I run:

Code: Select all

/usr/share/mythtv/metadata/Television/ttvdb.py -t
The modules tvdb_api.py (v2.0 or greater).
They should have been installed along with the MythTV python bindings.
Error:(No module named 'requests_cache')

However requests_cache is installed

Code: Select all

pi@raspberrypi:/var/log/mythtv $ sudo apt install python-requests-cache
Reading package lists... Done
Building dependency tree       
Reading state information... Done
python-requests-cache is already the newest version (0.4.13-2).
python-requests-cache set to manually installed.

Portion of log:

Code: Select all

Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext mythpower.cpp:131 (Init) Power: Supported actions: None
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext mythtranslation.cpp:64 (load) Loading en_us translation for module mythfrontend
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext main.cpp:112 (main) Testing grabbers and metadata sites for functionality...
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I SystemManager mythsystemunix.cpp:262 (run) Starting process manager
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I SystemIOHandlerR mythsystemunix.cpp:83 (run) Starting IO manager (read)
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I SystemIOHandlerW mythsystemunix.cpp:83 (run) Starting IO manager (write)
Apr  3 06:01:31 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I SystemSignalManager mythsystemunix.cpp:488 (run) Starting process signal handler
Apr  3 06:01:32 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext metadatadownload.cpp:423 (TelevisionGrabberWorks) Television grabber not functional.  Aborting this run.
Apr  3 06:01:32 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext platforms/mythpowerdbus.cpp:72 (~MythPowerDBus) PowerDBus: Closing interfaces
Apr  3 06:01:32 raspberrypi mythmetadatalookup: mythmetadatalookup[5540]: I CoreContext mythcontext.cpp:1665 (~MythContext) Exiting

[bill6502]

The default Python version for v31 is 3, maybe you want python3-requests-cache.

[jfabernathy]

The default Python version for v31 is 3, maybe you want python3-requests-cache.

Interesting. I built this test system using the Mythtv light wiki instructions except changing from myth30 to myth31.
After that install, I used the latest pi-mythtv-helper script from this forum category.

I didn't request any additional packages to be installed. So maybe on V31 the dependence for requests-cache needs to be changes??
Jim A

[MikeB2013]

Did you (re)run ansible to setup build depends, there were some changes around 10 days ago in this area ?

You will also need to set StorageGroups (if not already done) in mythtv-setup for coverart,fanart and banners (I always thought that if not setup it would default to recordings storagegroup but apparently not).
For Pi they are in /srv/mythtv/

Mike

[jfabernathy]

I did the install via adding this line to /etc/apt/sources.list.:
deb http://dl.bintray.com/bennettpeter/deb/ buster myth31

So maybe that source is a little out of date.

However, I created a new system and built from source using fixes/31 with the latest dependencies from ansible and that worked without any changes.
Both commercial flagging and metadata lookup worked.

However, while using the frontend on the RPi4 I went into edit mode and used 'm' to load the cut list and tried to check out how real the cuts were from the commercial flagging and the frontend blew away back to the console. I didn't have a log running so, I'll redo with a log and see if I can duplicate.

Jim A

[jfabernathy]

However, while using the frontend on the RPi4 I went into edit mode and used 'm' to load the cut list and tried to check out how real the cuts were from the commercial flagging and the frontend blew away back to the console. I didn't have a log running so, I'll redo with a log and see if I can duplicate.

Jim A

I'm not sure if Themes can make a difference, but the original failure was using Theme mythcenter-wide 1.7. I don't like that one for editing a recording. So I switched to Mythbuntu 30.1 and I haven't crash it yet. I'll keep a log open for now on with debug level.

Jim A

[MikeB2013]

That buster build is old 13 Feb 2020 commit a51f21a

As far as I know Peter has not yet released mythtv-light 31, the mythtv-light wiki does not show it as being available.

Unfortunately certain problems only appear when the official builds are available. Building from source is not quite the same as installing from a deb package. When building from source both the build and run-time depends get installed by running ansible, installing from deb only installs run-time depends which are defined in the deb file (it is so easy to miss one or more of these and the only way to be sure is to create the deb files and install on a clean version of the operating system and then run a whole load of tests to make sure it all works).

Mike

[jfabernathy]

Mike thanks for the explanation. I'll stick with the source of mythtv-light for now. Working fine for commercial flagging.
The real test will be what can you do while commercial flagging is running in background. I'm afraid that some of my breakups in recordings last night were due to that.

More testing.

Jim A