Log message:
get_iplayer: update to 3.29
get_iplayer 3.29 Release Notes
Changes in 3.29
There is a breaking change in this release
* Fixed bug that caused searches to fail when target episode title in
cache contained vertical bar (|) characters. Vertical bars now
converted to hyphens.
* Adjusted stream classification to accommodate BBC changes
* 960x540@25 streams are apparently no longer provided for
programmes first broadcast after approximately 2021-12-05. The
are still available for older programmes, including recent
repeats.
* 960x540@25 streams for new programmes have been replaced by
960x540@50 streams with the same bit rate. get_iplayer now
detects these lower-bitrate 50fps streams and classifies them
appropriately. Use --tv-lower-bitrate to prefer those streams if
they are available. The file sizes should be roughly the same as
the previous 25fps streams. You do not need to change your
preferences.
* Restored BBC Three schedules to the programme indexing to accomodate
its return as a broadcast channel. Perform a full rebuild of the TV
programme index cache if you want to ensure it includes all supported
BBC Three programmes:
get_iplayer --rebuild-cache
Ignore these warnings, as there were no BBC Three schedule listings
for that week:
WARNING: Got 0 programmes for BBC Three schedule page (HTML): \
https://www.bbc.co.uk/schedules/p00fzl95/2022/w01
WARNING: Failed to parse BBC Three schedule page: \
https://www.bbc.co.uk/schedules/p00fzl95/2022/w01
* Options related to recording quality have been changed
* Some command iine parameters have been renamed:
Old New Option Key
--modes --quality modes
--tv-mode --tv-quality tvmode
--radio-mode --radio-quality radiomode
--fps25 --tv-lower-bitrate fps25
The old command-line option names are scheduled for removal in
the next release. The option keys (used in preferences, presets,
and PVR searches) remain the same, so recording quality settings
in existing preferences, presets, and PVR searches will continue
to work.
* The possible recording quality settings have been reduced to:
Type Quality Settings Aliases Default
TV fhd,hd,sd,web,mobile 1080p,720p,540p,396p,288p hd,sd,web,mobile
Radio high,std,med,low 320k,128k,96k,48k high,std,med,low
In the next release, it will be a fatal error to enter an invalid
quality setting on the command line. Aliases can be used
interchangeably with their corresponding alphabetic codes. The
two substantive changes are that TV "high" quality is now \
"web",
and TV "low" quality is now "mobile". This makes \
TV and radio
quality settings distinct sets that can be mixed unambiguously
for --quality and the Web PVR Manager. All recording quality
settings that cannot be translated into values from the lists
above are discarded. See Recording Quality for further
information. See below for more information about the "fhd"
quality setting.
* BREAKING CHANGE: Existing quality settings (or recording modes)
saved in preferences, presets, and PVR searches will be
translated into new quality settings in a backwards-compatible
manner, with one exception. If your saved values have prefixes
denoting stream format (hls,hvf,had,dash,dvf,daf), or numeric
suffixes for specific streams, those prefixes and suffixes are
now stripped and ignored. You should never use numeric suffixes
since they are non-deterministic. In the unlikely event you need
to restrict the stream formats to record, use the new
--exclude-format option. --exclude-format=dash will exclude
MPEG-DASH streams, and --exclude-format=hls will exclude HLS
streams.
* If you have not specifed at least one of sd,web,high with
--tv-quality when downloading an audiodescribed programme,
get_iplayer will now insert those quality settings to ensure a
stream is available. HD is not available for audiodescribed
programmes.
* Changes to programme metadata fields
* No longer included in XML/JSON metadata files: durations,
geoblocked, modes, modesizes, unavailable, verpids, versions. Use
--info to see available version-dependent metadata values.
* Now included in XML/JSON metadata files: quality, verpid
* No longer displayed with --info unless --verbose is also
specified: modes, modesizes
* Now displayed with --info: qualities, qualitysizes
* Changes to application options
* --purge-files has been removed.
* --trim-history and --no-purge are now ignored and will be removed
in the next release. You can remove them from your preferences
with:
get_iplayer --prefs-del --trim-history=0 --no-purge
get_iplayer will no longer issue a warning to remove downloaded
programmes more than 30 days old.
* EXPERIMENTAL: Full HD streams (1080p)
* Before anyone asks: UHD 4k streams are still not available to
get_iplayer.
* get_iplayer now attempts to generate 1920x1080@50 ("fhd") \
stream
URLs for every programme that has 1280x720@50 ("hd") \
streams (so
no audiodescribed programmes). The purpose of these 1080p streams
is not known. They may be used for some smart TVs or set-top
boxes, or they may be a BBC experiment.
* It is not a bug if "fhd" streams are not available for a
programme. Do not depend on the presence of these streams. They
may disappear at any time. They are provided solely for you to
experiment with if you find them useful. You may decide that the
video quality of "fhd" streams does not justify their extra
download and storage requirements.
* The "fhd" streams are not included by default, nor are they
included when expanding the obsolete "best" shortcut if it is
saved in your preferences, presets, or PVR searches. You must
request "fhd" downloads specifically with --tv-quality=fhd or
--tv-quality=1080p. This is done in part to avoid resource shock
for the presumed majority of users who don't read release notes
and documentation, but also because the quality of "fhd" \
streams
varies greatly. If you wish to include "fhd" in your default
settings, save it in your preferences:
get_iplayer --prefs-add --tv-quality=fhd,hd,sd,web,mobile
* The bit rates for the "fhd" streams can vary quite a bit \
between
programmes. The maximum appears to be around 10 Mb/s (though most
are far lower), so output files could be up to ~90% larger than
their "hd" equivalents, in the region of 3.8 GB/hr for video.
Most will have far lower bit rates, sometimes lower than their
"hd" equivalents, likely due to more sophisticated compression
techniques being employed.
* Because of the method used to access the "fhd" streams,
get_iplayer can't estimate their actual bit rates, so it assumes
8 Mb/s, the value advertised in iPlayer metadata. Consequently,
file size estimates and download progress reports may be quite
far off.
* It has been observed in initial testing that MPEG-DASH "fhd"
downloads are much faster than HLS equivalents, so MPEG-DASH
streams are tried first, while the opposite is true for \
non-"fhd"
streams. This makes no difference to the output. The extra
post-processing time required for MPEG-DASH is more than offset
by the faster download. You can test the difference with
--tv-quality=fhd --exclude-format=hls and --tv-quality=fhd
--exclude-format=dash.
|
Log message:
get_iplayer: Update to 3.26
get_iplayer 3.26 Release Notes
Changes in 3.26
* Restored download of programme credits - broken by BBC changes.
* Restored channel names to --pid-recursive-list output - broken by BBC
changes.
* Restored subtitle colours - broken by BBC changes.
* Media streams mislabelled as belonging to the defunct BBC Store are no
longer ignored - a few may contain valid content.
* Fixed hash initialisation in Pvr class (@praxilian)
* Added new --cuesheet-offset option (synonym: --tracklist-offset) that
can be used to apply a positive or negative offset to track times in
cue sheet or track list. If you find track times off by a consistent
amount after download, use --cuesheet-only with --cuesheet-offset=<n>
or --tracklist-only with --tracklist-offset=<n> (where n = offset in
seconds) to generate a new cue sheet or track list with adjusted track
times.
* The default value of the --thumbnail-size option is now 1920, which
downloads a 1920x1080 image. The previous default was 192, which
downloaded a 192x108 image. This larger default size should work
better on TVs and larger devices, but it will still scale down for
smaller devices and media manager software.
* If you have added --thumbnail-size to your preferences, it will
continue to be used.
* This change will add ~200KB to the size of tagged output files,
compared to the previous default.
* If you wish to restore the previous default thumbnail size:
get_iplayer --prefs-add --thumbnail-size=192
* Thumbnail size is now automatically limited to 1280 when
--thumbnail-square is used, in order to avoid distorted images.
* The @wrt atom in metadata tags (iTunes: Composer field) is now set to
"BBC Sounds" for radio programmes. The value is still set to \
"BBC
iPlayer" for TV programmes.
* The --tag-utf8 option is now ignored and will be removed in the next
release. It hasn't served any useful purpose for some time. To remove
it from your preferences if necessary:
get_iplayer --prefs-del --tag-utf8
* The minimum version of Perl nominally required for get_iplayer is now
5.16, in line with recent changes in requirements for the Mojolicious
module. This requirement is not yet enforced in get_iplayer code since
some combinations of older Perl and Mojolicious versions will still
work. This only concerns Linux users doing manual installations, and
who for some reason attempt to install new versions of Mojolicious
with obsolete versions of Perl, so it is unlikely to apply to you.
* get_iplayer previously allowed a PVR run to continue even if the
previous run might still be active, as long as 12 hours had elapsed
since the previous run was launched, on the presumption that after 12
hours the previous run must be hung. That is no longer the case.
* If an invalid (e.g., due to disk write error) PVR lockfile is
found, get_iplayer deletes the lockfile and exits with an error
and an instruction for you to check if get_iplayer PVR is already
running before restarting.
* If a valid PVR lockfile is found and the previous run is still
active, get_iplayer will now always exit with an error regardless
of whether or not 12 hours has elapsed. It now prints the process
ID associated with the running PVR so that you can check the
process status if necessary.
* get_iplayer is not prone to hanging as it sometimes was when it
relied on rtmpdump and ffmpeg for downloading, so this change
should have little effect on you. One possible exception is if
you try to use get_iplayer in Windows Subsystem for Linux v1 (WSL
1), where AtomicParsley always hangs and thus hangs every PVR
run. Don't use get_iplayer on WSL 1. AtomicParsley does work with
WSL 2.
|