TV metadata lookup: prefer season/episode on search
over subtitle search if inetref is provided.
The search for TV shows with 'inetref' & 'subtitle' is ambiguous if the
same subtitle exists multiple times, like "Episode 1" available for
multiple seasons.
If data for 'season' and 'episode' numbers are available, use it at
first instance, because these data are unique.
Refs #473
(cherry picked from commit 2311368b60b4df26fe8d1db701ecea64f1bfd517)
Python Bindings: Fix uncaught exception in 'deadlinesocket'
Python Bindings throws an error if the socket does not provide data:
Traceback (most recent call last):
....
File "/usr/lib/python3/dist-packages/MythTV/utility/other.py", line 374, in dlexpect
raise MythError(MythError.CLOSEDSOCKET)
AttributeError: type object 'MythError' has no attribute 'CLOSEDSOCKET'
Solution:
Align the error code to the methods provided by MythError.SOCKET.
Fixes #423
(cherry picked from commit 1e6246da6845370938eee6f75ecbf915559f7448)
Traceback (most recent call last):
File "/.../MythTV/msearch.py", line 35, in __init__
self.sock.setblocking(0.1)
TypeError: 'float' object cannot be interpreted as an integer
Python's socket implementation allows to set the blocking mode with
- setblocking([0/1] or
- settimeout(float) # i.e '0.0'
Prior to python3.10, 'setblocking' evaluated the float value to an integer,
which results in this case to zero (tested with 'socket.gettimeout'()).
Make it clear, that we want the non-blocking mode.
Tested with python3.6 and 3.10.
(cherry picked from commit e57584bab7d25dc3438b7661c3cc33f5d92b4a13)
This was reported on the forum, it throws this
Error: (module 'requests_cache' has no attribute 'core')
It turned out, that the monkey patch provided by
`mythtv/bindings/python/MythTV/ttvdb/requests_cache_compatability.py`
is only valid for versions of request-cache < '0.5.0'. Newer versions
do not need this patch and versions beyond '0.8.0' crashes with above
error message.
Note: The module requests_cache.core was removed in version '0.8.0'
on Sept. 2021 and deprecated in version '0.6.0' in April, 2021.
Refs #408
(cherry picked from commit da3f00653588813fc225eafa146d975b26986819)
In MariaDB 10.1.2 a new temporal format was introduced from
MySQL 5.6 that alters how the `TIME`, `DATETIME` and `TIMESTAMP`
columns operate at lower levels. These changes allow these temporal
data types to have fractional parts and negative values.
You can disable this feature using the `mysql56_temporal_format`
system variable.
Starting from MariaDB 10.5.1 columns with old temporal formats are
marked with a `/* mariadb-5.3 */` comment in the output of
`SHOW CREATE TABLE`, `SHOW COLUMNS`, `DESCRIBE` statements, as well
as in the `COLUMN_TYPE` column of the `INFORMATION_SCHEMA.COLUMNS`
Table.
Since the python bindings use the `DESCRIBE` statement to identify
the type of an MySQL entry, the comment must be stripped off.
This happens on old MariaDB databases upgraded automatically
during system upgrade, e.g.: Debian 10 -> 11.
This is a backport of the 'ttvdb4.py' television grabber from
MythTV/master to fixes/31.
The current API from thetvdb.com (v3) is marked as deprecated
and will be removed soon.
In order to enable this grabber, run in mythtv frontend
"Setup" -> "Artwork and Data Sources"
and select 'TheTVDatabaseV4' for the default TelevisionGrabber.
Upon first start, a file named 'ttvdb4.ini' is created under
the '$HOME/.mythtv' folder, which lets you add some options, like
additional languages to seach. Edit this file according your needs.
Refs #463
25f1bb1...
by
Klaas de Waal <email address hidden>
Restarting playback with VDPAU after PMT change
Playback of some recordings of the Finnish broadcaster YLE fails
when the VDPAU hardware accelerator is selected in the playback profile.
This is caused by a restart of the video decoding after a PMT change.
This problem only occurs with the MythTV-specific demuxer (mpegts-mythtv.c)
and not with the original FFmpeg demuxer (mpegts.c) because the FFmpeg
demuxer largely ignores PMT changes once playback has started.
The first time the VDPAU codec support is checked, the pixel format is
given as AV_PIX_FMT_YUV420P. This pixel format translates to video frame type FMT_YV12.
There is a check if the video frame type is FMT_YV12 and this check succeeds.
At the end, when it is decided that VDPAU can be used, the pixel format is set to AV_PIX_FMT_VDPAU.
After a playback restart following a PMT change the VDPAU codec support is checked again.
The AVCodecContext is re-used and the pixel format is still set to AV_PIX_FMT_VDPAU.
This pixel format translate to video frame type FMT_VDPAU.
The check if the frame type is FMT_YV12 now fails and there is an attempt to continue
with FFMPEG decoding. This also fails, then resulting in a black screen while waiting forever.
The fix is to accept also video frame type FMT_VDPAU for use with VDPAU decoding.
This does solve the playback problems of all available YLE test clips.
It can possibly also solve playback problems in other cases where the PMT changes such
as when a channel that is broadcasting only part of the day does start broadcasting.
Note that in the beginning of MythVDPAUContext::GetSupportedCodec there is a check
if frame type FMT_VDPAU is supported and VDPAU can only be used if this is the case.
It therefore makes sense to accept FMT_VDPAU as a valid video frame type and
it was probably an omission in the original code that this frame type was not accepted.
