Re: Recursive download with episode name filter?
Have a look at https://www.bbc.co.uk/iplayer/episodes/b010nsbf/snooker-world-championship, and underneath that they have "Day 1 Round 1", "Day 2 Round 1" etc up to "Today". Under each of those there are videos of a particular match - eg under Day 1 there is https://www.bbc.co.uk/iplayer/episode/p0hq5cs9/snooker-world-championship-2024-live-tom-ford-v-ricky-walden-session-one. I can use the pid b010nsbf with --pid-recursive, but that gets everything, which involves considerable duplication of coverage, which is why I would like to filter what --pid-recursive downloads, rather than . Interestingly, if I run get_iplayer "Snooker* all that finds are the various Day 1, Day 2 etc videos. None of the A vs B match videos are found. On 24/04/2024 20:48, Chris Walker wrote: On Wed, 24 Apr 2024 19:33:40 +1000 Nick Payne wrote: For example, with the coverage of the current world snooker championships, I'm only after the videos of one specific player versus another, and they all have episode names of the format A_v_B, where A and B are the players. BBC have a pid that can be used to download all their coverage with --pid-recursive, but I'd like to filter it down to only episodes that contain "_v_" in their name. Is this possible? Nick Payne I've just done a search for snooker and that's just listed as this :- 4579: Snooker: World Championship: 2024 - Day 1: Afternoon Session, BBC One, m001ykb4 If I then do a --info against that there doesn't appear to be any information of the sort you're describing so where are you getting that information from? Can you give me an example PID? ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Recursive download with episode name filter?
For example, with the coverage of the current world snooker championships, I'm only after the videos of one specific player versus another, and they all have episode names of the format A_v_B, where A and B are the players. BBC have a pid that can be used to download all their coverage with --pid-recursive, but I'd like to filter it down to only episodes that contain "_v_" in their name. Is this possible? Nick Payne ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio portion of dash downloads slow
On 14/03/2022 09:30, VeniVidiVideo wrote: On Mar 13, 2022, at 5:45 PM, Nick Payne wrote: When I download a program with GiP using dash rather than hls, the initial separate download of the audio always comes down at only somewhere between 5% and 10% of the speed that I get when the video portion of the download is happening. Do other users see the same? This is with the latest v3.29 GiP. Did the audio actually download in much less time than the video, overall? So you're mainly concerned about the reported download speeds? If so, it's possible that the audio, being much smaller than the video, is having its download speed calculated from many fewer samples, so it is less accurate. Its measurement would also be drastically more affected by any startup and/or shutdown overhead that is included in the download time. No guarantees, but as long as the audio is actually downloading in substantially less time than the video the problem may simply be in how these speeds are being calculated. No, here's an example of the quite different speeds for the audio and video portions of a dash download - the 158Mb of audio took 31 minutes to download, and the 3536Mb of video took 1hr 2min, which means that the video portion downloaded at just over 14 times the speed of the audio download. If the audio had downloaded at the same speed as the video, the entire download would have completed in about 2/3 of the time it actually took. I see the same audio/video download speed difference for every dash download. A second, and quite unrelated problem is that the estimated file sizes for fhd 1080p downloads are always too high by a factor or three or four - unlike 720p downloads, where the estimate is usually accurate within 20% or so. Again, see the example below, where GiP's estimate for the video size was 10339Mb, but the actual size for the successfully completed download was 3536Mb. I think every fhd download I've done has had the same wildly inaccurate estimated size. = INFO: Downloading tv: 'Snooker: Welsh Open: 2022 - 14. The Final - Part 2 (m00158vr) [original]' INFO: Trying 'dashfhd1' mode: attempt 1 / 3 INFO: ffmpeg version string = 4.3.3-0+rpt2+deb11u1 INFO: ffmpeg version number = 4.3 INFO: File name prefix = Snooker_Welsh_Open-s15e14-The_Final_-_Part_2 INFO: Begin downloading at: 0.00 MB (00:00:00) [1] INFO: Downloaded: 158.00 MB (02:42:25) [2538] in 00:31:30 @ 0.67 Mb/s (dashfhd1/cf) [audio] INFO: Begin downloading at: 0.00 MB (00:00:00) [1] 3.3% 341.30 MB / ~10339.76 MB (00:09:01 / 02:42:25) [ 141 / 2538] @ 9.4 Mb/s ETA: 02:22:13 (dashfhd1/cf) [video] [...] INFO: Downloaded: 3536.83 MB (02:42:25) [2538] in 01:02:04 @ 7.60 Mb/s (dashfhd1/cf) [video] INFO: Converting to MPEG-TS [...] = Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Audio portion of dash downloads slow
When I download a program with GiP using dash rather than hls, the initial separate download of the audio always comes down at only somewhere between 5% and 10% of the speed that I get when the video portion of the download is happening. Do other users see the same? This is with the latest v3.29 GiP. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
GiP size estimates for 1080p downloads are several times too big
I've noticed, since downloading a few programs with GiP in 1080p, that that the estimated download size is usually too big by a factor of around three or four times. This for example, is typical - the estimate for the dash video size is 10339MB, but the actual download is 3536MB: INFO: Downloading tv: 'Snooker: Welsh Open: 2022 - 14. The Final - Part 2 (m00158vr) [original]' INFO: Trying 'dashfhd1' mode: attempt 1 / 3 INFO: ffmpeg version string = 4.3.3-0+rpt2+deb11u1 INFO: ffmpeg version number = 4.3 INFO: File name prefix = Snooker_Welsh_Open-s15e14-The_Final_-_Part_2 INFO: Begin downloading at: 0.00 MB (00:00:00) [1] INFO: Downloaded: 158.00 MB (02:42:25) [2538] in 00:31:30 @ 0.67 Mb/s (dashfhd1/cf) [audio] INFO: Begin downloading at: 0.00 MB (00:00:00) [1] 3.3% 341.30 MB / ~10339.76 MB (00:09:01 / 02:42:25) [ 141 / 2538] @ 9.4 Mb/s ETA: 02:22:13 (dashfhd1/cf) [video] [...] INFO: Downloaded: 3536.83 MB (02:42:25) [2538] in 01:02:04 @ 7.60 Mb/s (dashfhd1/cf) [video] INFO: Converting to MPEG-TS [...] By contrast, the estimated sizes for 720p downloads are usually accurate within 20% or so. This is GiP 3.29 running on Raspbian Linux. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Which Linux distro with get_iplayer support
The GUI in Linux Mint with Cinnamon will be fairly familiar to a Windows user, and it also has a PPA for get-iplayer that keeps it current: https://launchpad.net/~jon-hedgerows/+archive/ubuntu/get-iplayer. The next LTS version of Mint is due for release in about a month. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Slow speed
On 19/02/2020 11:21 am, Ralph Corderoy wrote: > RS wrote: >> Your only real remedy is to complain, complain and complain again to >> your ISP, or find a better ISP. > I'd have thought it's the CDN choice that's being made rather than ISP. > For example, having the line ‘exclude-supplier bidi’ in my > ~/.get_iplayer/options fixed a problem for me a few months back. > The OP needs to investigate what CDN/supplier is being used when he's > having problems. Ditto here. I used to have fairly frequent problems with the "Unexpected size for file segment" error, and downloads eventually failing, but since I added 'exclude-supplier bidi' to my options file, I have not had those errors, and the downloads are noticeably faster. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Slow speed
On 16/02/2020 10:57 pm, RS wrote: > I should have added that --audio-only, radio and the audio part of DVF > downloads are much slower, at a maximum of 7Mbit/s. I find the same with the audio part of DVF downloads - the speed of the audio download is always at less than 10% of the speed of the video download... ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: get_iplayer -g --force --pid-recursive http://www.bbc.co.uk/iplayer/group/p01277qd
On 30/12/2019 5:08 am, Sharon Kimble wrote: > get_iplayer -g --force --pid-recursive > http://www.bbc.co.uk/iplayer/group/p01277qd That pid doesn't seem to be classed as a series, so the recursive parameter doesn't work. You can download all the episodes of "The Train Now Departing" using the series pid get_iplayer --pid-recursive --pid=p011pddx Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: His Dark Materials m000csdk: only audiodescribed available?
I used: --tvmode=dvfhd --exclude-supplier=bidi on the command line, and the program downloaded as version 'technical': INFO: Mode list: dvfhd INFO: Searching for version: 'technical' INFO: Found version: 'technical' INFO: Modes to try for 'technical' version: dvfhd1 INFO: Downloading tv: 'His Dark Materials: Series 1 - 08. Betrayal (m000csdk) [technical]' INFO: Trying 'dvfhd1' mode: attempt 1 / 3 INFO: ffmpeg version string = 3.4.6-0ubuntu0.18.04.1 INFO: ffmpeg version number = 3.4 INFO: File name prefix = His_Dark_Materials-s01e08-Betrayal INFO: Begin downloading at: 0.00 MB (00:00:00) [1] running --info against the pid shows: longname: His Dark Materials: Series 1 modes: audiodescribed: dvfxsd1,dvflow1 modes: technical: dvfhd1,dvfsd1,dvfxsd1,dvfhigh1,dvfxhigh1,dvflow1,subtitles1,subtitles2 modesizes: audiodescribed: dvfxsd1=690MB,dvflow1=188MB [estimated sizes only] modesizes: technical: dvfhd1=2179MB,dvfsd1=1209MB,dvfxsd1=690MB,dvfhigh1=675MB,dvfxhigh1=356MB,dvflow1=188MB [estimated sizes only] name: His Dark Materials: Series 1 nameshort: His Dark Materials pid: m000csdk ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: odd problem with downloading
On 26/11/2019 8:59 am, MacFH - C E Macfarlane wrote: > On 25/11/2019 01:58, artisticforge Niemand wrote: >> Hello >> >> Downloading the current episode of Seven Worlds One Planet >> starts out okay, when if has to restart the download it fails. > > I'm not even getting that far, I get ... > > Seven Worlds One Planet - 01 05 Europe.audio.m4a (length 0) > Seven Worlds One Planet - 01 05 Europe.audio.txt (length 1KB) > > ... and that's all. Going to the programme page ... > > https://www.bbc.co.uk/iplayer/episode/m000bqjg/seven-worlds-one-planet-series-1-5-europe > > > ... that seems to begin alright, and there's no mention of problems > with it in the iPlayer help page, so I'm not sure what to try next. Ditto here. Other programs download without any problem, including other episodes of the same series, so it seems to be something awry with this one. The log shows: INFO: File name prefix = Seven_Worlds_One_Planet-s01e05-Europe INFO: Begin downloading at: 0.00 MB (00:00:00) [1] INFO: Downloaded: 0.00 MB (00:00:00) [0] in 00:00:01 @ 0.00 Mb/s (dvfhd1/bi) [audio] WARNING: Failed to download file segment [0] WARNING: Response: 400 Bad Request WARNING: File segment URL: https://mm.bidi.bbc.co.uk/vod-dash-uk/usp/auth/vod/piff_abr_full_hd/71da27-m000c5x9/vf_m000c5x9_2572b580-43d1-4adb-977a-af2c23928a8b.ism.hlsv2.ism/dash/vf_m000c5x9_2572b580-43d1-4adb-977a-af2c23928a8b.ism.hlsv2-audio_eng_1=128000.dash?at=4NFhVUwGd8b75c9fff30a80a11f90e7f98750cd9c669ed6d5983325e3e680 WARNING: Stopped downloading at: 0.00 MB (00:00:00) [0] and GiP then tries for the editorial version and finds no streams available. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT Video Conversion
I use MakeMKV (which isn't free) for ripping the DVDs or BluRays, followed by Handbrake to convert the resulting files to the H.265 video codec to reduce the file sizes (which is a pretty slow process). As I have an nVidia Quadro video card in the PC, I tried the NVENC version of H.265 in Handbrake, as the conversion runs many times faster than using the straight H.265, but the files produced were considerably larger and the video quality poorer, so I've stuck with the slow process. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: New distro.
On 20/06/2019 6:19 pm, Jim web wrote: > In article , Nick Payne > wrote: >> Using the PPA and apt will only install the needed dependencies. You're >> far more likely to be "spraying things you don't actually need into your >> install" by trying to do it manually. And apt will give you an exact >> list of the additional packages that need to be installed to satisfy >> dependencies. > As I think I've said, I tend to use synaptic. I've assumed this *does* > handle dependencies, etc. It certainly seems to from its interface reports. > > Is this wrong? If you install get-iplayer via Synaptic and the PPA, you'll get the current version and all the dependencies will be pulled in without you having to figure which are required. Add the PPA in Synaptic (Settings / Repositories / PPAs / Add / jon-hedgerows/get-iplayer), update, then search for and install get-iplayer. But I still think the command line is easier: sudo add-apt-repository ppa:jon-hedgerows/get-iplayer sudo apt-get update sudo apt-get install get-iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: New distro.
On 19/06/2019 10:38 pm, Jim web wrote: > In article , Alan C. > Foster wrote: >>> Install the PPA from here >>> >>> >>> https://launchpad.net/~jon-hedgerows/+archive/ubuntu/get-iplayer >>> >>> I've been doing that in Linux Mint for years. It gets updated >>> automatically by the Mint update manager when appropriate. > >> Jim, >> Why don't you follow this, it seems sensible? > Well, simply following the first advice and adding the libxml2-dev package > (the non -dev already being present) didn't work. So I'm trying to > establish which packages I *do* need (or not). Partly so I understand, > partly to avoid spraying things I don't actually need into my install in > the hope they'll work. Using the PPA and apt will only install the needed dependencies. You're far more likely to be "spraying things you don't actually need into your install" by trying to do it manually. And apt will give you an exact list of the additional packages that need to be installed to satisfy dependencies. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: BBC-wants-shows-available-iPlayer-12-months-bid-compete-rivals
Public broadcasters in other countries already have fairly extensive on-demand access to their back catalogue. The SBS in Australia, for example, has an on-demand website/app along the lines of iPlayer, and most programs seem to be available regardless of how long ago they were broadcast. Nor does this availability appear to affect the success of commercial streaming services such as Netflix or Amazon Prime. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Slightly OT Video conversion
Have you tried Handbrake. Free and open source and available for Windows, Mac, Linux. https://handbrake.fr/ ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: pid-recursive broken?
Same problem with 3.14. Here's the output from trying to retrieve
episodes of Hidden (using pid from
https://www.bbc.co.uk/iplayer/episodes/p066st1w, which shows four
episodes available):
D:\Users\Nick>get_iplayer --pid="p066st1w" --pid-recursive
get_iplayer 3.14.0, Copyright (C) 2008-2010 Phil Lewis
This program comes with ABSOLUTELY NO WARRANTY; for details use
--warranty.
This is free software, and you are welcome to redistribute it under
certain
conditions; use --conditions for details.
INFO: encodinglocale = cp1252
INFO: encodinglocalefs = cp1252
INFO: encodingconsoleout = cp850
INFO: encodingconsolein = cp850
INFO: ${^UNICODE} = 0
INFO: Profile dir: C:\Users\Nick\.get_iplayer
INFO: User options file: C:\Users\Nick\.get_iplayer\options
INFO: System options file: C:\ProgramData\get_iplayer\options
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
Current options:
encodingconsolein = cp850
encodingconsoleout = cp850
encodinglocale = cp1252
encodinglocalefs = cp1252
fileprefix = <-senum><-episodeshort>
nopurge = 1
output = D:\Users\Nick\videos
pid = p066st1w
pidrecursive = 1
radiomode = best
tvmode = hd
verbose = 1
INFO: Search args: ''
INFO: No file cache exists for tv
INFO: No file cache exists for radio
INFO: Cleaning PID - old: 'p066st1w' new: 'p066st1w'
INFO: Getting URL: https://www.bbc.co.uk/programmes/p066st1w.json
INFO: tv series or brand PID detected (p066st1w)
INFO: Getting URL:
https://www.bbc.co.uk/programmes/p066st1w/episodes/player?page=1
INFO: No episodes found, checking alternate location...
INFO: Getting URL: https://www.bbc.co.uk/iplayer/episodes/p066st1w?page=1
INFO: 0 total programmes
Nick
On 28/06/2018 7:57 AM, Jon Crookston wrote:
> Hi,
>
> I tried this this evening:
>
> $ gip --pid=p064g5r2 --pid-recursive --test
>
>
> (which should pick up a series of, I think, 21 episodes from CBeebies). The
> output was:
>
> get_iplayer v3.13, Copyright (C) 2008-2010 Phil Lewis
> This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty.
> This is free software, and you are welcome to redistribute it under certain
> conditions; use --conditions for details.
>
>
> INFO: 0 total programmes
>
>
>
>
> I can't offer any more info than that. Hope it's helpful.
>
> Thanks,
>
> Jon.
>
>
>
> From: Mark Carroll
> To: get_iplayer
> Sent: Wednesday, 27 June 2018, 17:40
> Subject: Re: pid-recursive broken?
>
>
>
> On 27 Jun 2018, Doug Faunt wrote:
>
>> Hi, it appears that pid-recursive has been broken.
>> Any idea if this is temporary or permanent as result of the new regime?
>> In get_iplayer 3.00-windows.0
> 3.13 has some -pid-recursive fixes that were needed for children's
> television and are maybe now needed more widely?
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: no more hslv format ?
On 3/05/2018 9:24 AM, RS wrote: > On 02/05/18 23:21, Owen Smith wrote: > >> >> I've been mystified for a while why people talked about "dropping >> every other frame" as if it were trivial to do, and an email earlier >> in this chain looked like someone was trying to do that again. I was >> explaining why that simply is not possible in the general case. >> > > If I have caused confusion by talking about dropping alternate frames > I apologise. I had come across some posts in another forum which > suggested it could be done, but I now recognise I was wrong. What > makes it worse is that I have since come across a thread in this > listserver from two years ago where I was asking exactly the same > questions, and Vangelis pointed out I was wrong and directed me to a > Wikipedia article on H.264. > > It is not possible to change the frame rate using -c:v=copy in ffmpeg; > it is necessary to re-encode which is why it takes so long. > Inevitably there will be losses, added to which the codecs available > to us may be inferior to those used by the BBC. > > I think it was Nick Payne who said he had experimented with > re-encoding in HEVC (H.265) and found that the file size was the same > for 25fps as it was for 50fps, which led him to conclude that frames > were being duplicated to achieve 50fps. Yes, I had some of the coverage of the UK snooker championships where they provided HLS downloads @ 1280x720 25fps and other coverage was only available as HVF downloads @ 1280x720 50fps. When I ran these both through Handbrake with identical settings to convert to HEVC, retaining the frame rate of the downloaded files, the size reduction for the 50fps downloads was about twice that for the 25fps downloads, and the size of the files output by Handbrake was proportional to the length of the program and not the frame rate. e.g. 4h58m match: D/L size 5.03Gb @ 25fps, output from Handbrake was 1.55Gb 4h44m match: D/L size 10.2Gb @ 50fps, output from Handbrake was 1.48Gb Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
GiP trying to download incorrect PID
I've noticed this now a couple of times on different downloads - I give
GiP a PID on the command line, and it errors out on a different PID
number. See console output below for an example - I've asked for PID
b0b1y57f, and that initially gets echoed back in the console output, but
further on it then tries to download b0b1y54f and fails.
GiP 3.13 on Win10 x64.
==
D:\Users\Nick\scripts>get_iplayer --pid="b0b1y57h"
get_iplayer 3.13.0, Copyright (C) 2008-2010 Phil Lewis
This program comes with ABSOLUTELY NO WARRANTY; for details use
--warranty.
This is free software, and you are welcome to redistribute it under
certain
conditions; use --conditions for details.
INFO: encodinglocale = cp1252
INFO: encodinglocalefs = cp1252
INFO: encodingconsoleout = cp850
INFO: encodingconsolein = cp850
INFO: ${^UNICODE} = 0
INFO: Profile dir: C:\Users\Nick\.get_iplayer
INFO: User options file: C:\Users\Nick\.get_iplayer\options
INFO: System options file: C:\ProgramData\get_iplayer\options
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
Current options:
encodingconsolein = cp850
encodingconsoleout = cp850
encodinglocale = cp1252
encodinglocalefs = cp1252
fileprefix = <-senum><-episodeshort>
nopurge = 1
output = D:\Users\Nick\Videos
pid = b0b1y57h
radiomode = best
tvmode = hlshd,hvfhd
verbose = 1
INFO: Search args: ''
INFO: No file cache exists for tv
INFO: No file cache exists for radio
INFO: Cleaning PID - old: 'b0b1y57h' new: 'b0b1y57h'
INFO: Getting URL: http://www.bbc.co.uk/programmes/b0b1y57h.json
INFO: tv episode PID detected (b0b1y57h)
Episodes:
World Championship Snooker Extra - 2018, Day 8, BBC Two, b0b1y57h
INFO: 1 total programmes
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
INFO: Loaded history for first check.
INFO: Loading recordings history
INFO: Programme not in history
INFO: Getting URL: http://www.bbc.co.uk/programmes/b0b1y57h.json
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/iptv-all/vpid/b0b1y54f?cb=41342
INFO: Getting URL:
http://vod-hls-uk-live.akamaized.net/usp/auth/vod/piff_abr_l2v_hd/e7e021-b0b1y54f/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.ism/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.m3u8?__gda__=1524997552_dd0950aced4ceec24ac416d4fd4494aa
INFO: Getting URL:
http://vod-hls-uk-live.bbcfmt.hs.llnwd.net/usp/auth/vod/piff_abr_l2v_hd/e7e021-b0b1y54f/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.ism/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.m3u8?s=1524954352=1524997552=ac1a2d135efb4afaf5337b1fabd4f1ad
INFO: Getting URL:
http://mm.bidi.bbc.co.uk/vod-hls-uk-live/usp/auth/vod/piff_abr_l2v_hd/e7e021-b0b1y54f/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.ism/vf_b0b1y54f_45d28a3d-89d2-4683-9c55-be006339d9fe.ism.hlsv2.m3u8?at=SKe0kPiW9aa5fd138b29232affe562a3eda9a2ceffdd8b3956af521e8f400
INFO: Found mode hvfhd1: gip_hvf_iplayer_5510 hls h264 1280x720
50fps 5510kbps mf_bidi_uk_hls/3
INFO: Found mode hvfhd2: gip_hvf_iplayer_5510 hls h264 1280x720
50fps 5510kbps mf_limelight_uk_hls/2
INFO: Found mode hvfhd3: gip_hvf_iplayer_5510 hls h264 1280x720
50fps 5510kbps mf_akamai_uk_hls/1
INFO: Found mode hvfsd1: gip_hvf_iplayer_3117 hls h264 960x540
50fps 3117kbps mf_bidi_uk_hls/3
INFO: Found mode hvfsd2: gip_hvf_iplayer_3117 hls h264 960x540
50fps 3117kbps mf_limelight_uk_hls/2
INFO: Found mode hvfsd3: gip_hvf_iplayer_3117 hls h264 960x540
50fps 3117kbps mf_akamai_uk_hls/1
INFO: Found mode hvfxsd1: gip_hvf_iplayer_1836 hls h264 960x540
25fps 1836kbps mf_bidi_uk_hls/3
INFO: Found mode hvfxsd2: gip_hvf_iplayer_1836 hls h264 960x540
25fps 1836kbps mf_limelight_uk_hls/2
INFO: Found mode hvfxsd3: gip_hvf_iplayer_1836 hls h264 960x540
25fps 1836kbps mf_akamai_uk_hls/1
INFO: Found mode hvfxhigh1: gip_hvf_iplayer_1013 hls h264 704x396
25fps 1013kbps mf_bidi_uk_hls/3
INFO: Found mode hvfxhigh2: gip_hvf_iplayer_1013 hls h264 704x396
25fps 1013kbps mf_limelight_uk_hls/2
INFO: Found mode hvfxhigh3: gip_hvf_iplayer_1013 hls h264 704x396
25fps 1013kbps mf_akamai_uk_hls/1
INFO: Found mode hvfstd1: gip_hvf_iplayer_865 hls h264 640x360
25fps 865kbps mf_bidi_uk_hls/3
INFO: Found mode hvfstd2: gip_hvf_iplayer_865 hls h264 640x360
25fps 865kbps mf_limelight_uk_hls/2
INFO: Found mode hvfstd3: gip_hvf_iplayer_865 hls h264 640x360
25fps 865kbps mf_akamai_uk_hls/1
INFO: Found mode hvflow1: gip_hvf_iplayer_599 hls h264 512x288
25fps 599kbps mf_bidi_uk_hls/3
INFO: Found mode hvflow2: gip_hvf_iplayer_599 hls h264 512x288
25fps 599kbps mf_limelight_uk_hls/2
INFO: Found mode hvflow3: gip_hvf_iplayer_599 hls h264 512x288
25fps 599kbps mf_akamai_uk_hls/1
INFO: Found mode
Re: Cannot play downloads from get_iplayer!
On 18/04/2018 8:05 PM, Paul Thornett wrote: > As a matter of interest, how do I check if hls is available for a > particular file? I thought --info would show this, but using this > option on "Ordeal by Innocence Episode 1" does not reveal the > availability of the hlshd stream, even though it is there. I have tvmode=hlshd in my options file. If hlshd is available, it gets used, otherwise the download fails, and I then look at the GiP console output to see what modes are available, choose one, and use --tvmode=... on the command line to override the options file. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Using ffmpeg to halve frame rate
On 16/04/2018 6:59 AM, Nick Payne wrote: > On 16/04/2018 2:18 AM, RS wrote: >> A couple of years ago there were problems with HLS and there was >> speculation that we might have 50 fps HVFhd and DVFhd as the only HD >> modes. At that time I wondered if it would be feasible to drop every >> other frame to reduce the frame rte to 25 fps. I thought because of >> the H.264 delta encoding it would probably mean transcoding and that >> it would be too slow. >> >> On a 42" screen for the programmes that I usually watch I cannot see >> any difference between a HD picture at 50 fps and one at 25 fps, so 50 >> fps for me is just a waste of bandwidth and storage space, so I have >> been looking at it again. > I experimented a while ago with running some GiP downloads through > Handbrake to convert the video to the x265 codec. That reduced the file > size to about 1/3 of the original download, with no subjective > difference in video quality that I could see when viewing on our TV. A > one hour 1280x720 25fps program that downloads as a 1Gb file was reduced > in size to ~350Mb. On my PC, the re-encode runs at about 50fps for > 1280x720, so ~2x real time for 25fps and ~real time for 50fps. For > smaller video dimension such as 960x540, the re-encode speed was around > 85-90FPS. I just ran another test on some 1280x720 50fps and 1280x720 25fps downloads from the last UK snooker championship. As before, the 25fps downloads were reduced to about 1/3 previous size by Handbrake (eg a 4h58m match that was 5.03Gb came down to 1.55Gb). However, the 50fps downloads were reduced by far more with exactly the same settings in Handbrake - for example, a 4h44m match that was a 10.2Gb download from GiP came down to 1.48Gb, and a 4h14m 8.93Gb file came down to 1.30Gb. This leads me to wonder if the 50fps downloads are from a 25fps original and just have each frame duplicated, as after running through Handbrake, the file sizes just seem proportional to the length of the program, and whether 50fps or 25fps has no effect on the file size. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Using ffmpeg to halve frame rate
On 16/04/2018 5:21 PM, Steve Dodd wrote: > On Sun, Apr 15, 2018 at 9:59 PM, Nick Payne <njh...@gmail.com> wrote: > >> I experimented a while ago with running some GiP downloads through >> Handbrake to convert the video to the x265 codec. That reduced the file >> size to about 1/3 of the original download, with no subjective >> difference in video quality that I could see when viewing on our TV. > Figures - most of the comparison work done on H.265 v. H.264 says you > should get same subjective quality for half the bitrate. > >> A one hour 1280x720 25fps program that downloads as a 1Gb file was reduced >> in size to ~350Mb. On my PC, the re-encode runs at about 50fps for >> 1280x720, so ~2x real time for 25fps and ~real time for 50fps. For >> smaller video dimension such as 960x540, the re-encode speed was around >> 85-90FPS. > Do you know what x265 quality setting you used? I'm also experimenting > now it seems HLSHD is being turned off (series 2 of Salamander has HVF > only so far).. RF17 seems to be spitting about half the bitrate of the > BBC h.264 output, and running at ~40fps which I can live with (Core > i5-6500). Noticeable quality difference still when looking at stills, > but have tried watching it moving yet.. For re-encoding 1280x720 downloads to x265, on the Video tab in Handbrake I have the encoder preset at "Faster" and the RF quality at 23. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Using ffmpeg to halve frame rate
On 16/04/2018 2:18 AM, RS wrote: > A couple of years ago there were problems with HLS and there was > speculation that we might have 50 fps HVFhd and DVFhd as the only HD > modes. At that time I wondered if it would be feasible to drop every > other frame to reduce the frame rte to 25 fps. I thought because of > the H.264 delta encoding it would probably mean transcoding and that > it would be too slow. > > On a 42" screen for the programmes that I usually watch I cannot see > any difference between a HD picture at 50 fps and one at 25 fps, so 50 > fps for me is just a waste of bandwidth and storage space, so I have > been looking at it again. I experimented a while ago with running some GiP downloads through Handbrake to convert the video to the x265 codec. That reduced the file size to about 1/3 of the original download, with no subjective difference in video quality that I could see when viewing on our TV. A one hour 1280x720 25fps program that downloads as a 1Gb file was reduced in size to ~350Mb. On my PC, the re-encode runs at about 50fps for 1280x720, so ~2x real time for 25fps and ~real time for 50fps. For smaller video dimension such as 960x540, the re-encode speed was around 85-90FPS. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Format of options file
On 4/03/2018 9:54 AM, Bernard Peek wrote: > > On 03/03/18 17:33, James Scholes wrote: >> RS wrote: >>> The Windows download_history file seems to work correctly. I hope I >>> don't need to edit it. >> >> You've probably edited your options file by hand in the past, >> resulting in a mixture of weird line endings from a Windows editor, >> and appropriate ones when get_iplayer itself has updated it. That's >> just my guess after going through exactly the same thing recently. >> I'd bet you probably don't go editing your download_history file by >> hand very often so it's most likely fine. > > For what it's worth I noticed that under Windows the Wordpad program > seems to understand UNIX style terminations and retains them. The free Notepad++ editor does also. In fact, you can set in the program preferences whether you want line endings to be formatted as the Windows CRLF, Unix LF, or Mac CR. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Modes and best quality
On 13/12/2017 10:19 PM, Ralph Corderoy wrote: > Hi Nick, > >> I have noticed, on numerous pids, that if I download them using >> --tvmode=best then the highest quality 25fps stream that is found is >> dvfxhigh (704x396 25fps). >> >> However, if I explicitly use --tvmode=hlshd, then I get the 1280x720 >> 25fps stream. > I too am unclear on how the `better', `best', etc., map to modes. You > might want to experiment with the --fps50 option as that seems to > influence the definition of `best' and friends. Yes, if I use --fps50 with --tvmode=best then I get the 1280x720 50fps stream. However, I have yet to view a program where I thought that 50fps gave an advantage over 25fps, so from my point of view using it means having to download files of twice the size for no visible advantage. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Modes and best quality
I have noticed, on numerous pids, that if I download them using
--tvmode=best
then the highest quality 25fps stream that is found is dvfxhigh (704x396
25fps).
However, if I explicitly use --tvmode=hlshd, then I get the 1280x720
25fps stream.
As an example, here's the console output from downloads of pid b09hlzbb
(Expedition Volcano episode 1), first using --tvmode=best and then using
--tvmode-hlshd.
This behaviour does not accord with the documentation at
https://github.com/get-iplayer/get_iplayer/wiki/modes, which gives as an
explicit example using --tvmode=best to get 1280x720 @25fps:
===
D:\Users\Nick>get_iplayer --pid=b09hlzbb --verbose --tvmode=best
get_iplayer 3.07.0, Copyright (C) 2008-2010 Phil Lewis
This program comes with ABSOLUTELY NO WARRANTY; for details use
--warranty.
This is free software, and you are welcome to redistribute it under
certain
conditions; use --conditions for details.
INFO: encodinglocale = cp1252
INFO: encodinglocalefs = cp1252
INFO: encodingconsoleout = cp850
INFO: encodingconsolein = cp850
INFO: ${^UNICODE} = 0
INFO: Profile dir: C:\Users\Nick\.get_iplayer
INFO: User options file: C:\Users\Nick\.get_iplayer\options
INFO: System options file: C:\ProgramData\get_iplayer\options
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
Current options:
encodingconsolein = cp850
encodingconsoleout = cp850
encodinglocale = cp1252
encodinglocalefs = cp1252
fileprefix = <-senum><-episodeshort>
output = D:\Users\Nick\Videos
pid = b09hlzbb
tvmode = best
verbose = 1
INFO: Search args: ''
INFO: Loaded history for first check.
INFO: Loading recordings history
INFO: Programme not in history
INFO: No file cache exists for tv
INFO: No file cache exists for radio
INFO: Cleaning PID - old: 'b09hlzbb' new: 'b09hlzbb'
INFO: Getting URL: http://www.bbc.co.uk/programmes/b09hlzbb.json
INFO: tv episode PID detected (b09hlzbb)
Matches:
INFO: 0 matching programmes
INFO: Programme not in history
INFO: Getting URL: http://www.bbc.co.uk/programmes/b09hlzbb.json
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/iptv-all/vpid/p05p91x1/transferformat/dash?cb=29003
INFO: Getting URL:
http://vod-dash-uk-live.akamaized.net/usp/auth/vod/piff_abr_full_sd_ad/3172c5-b09hlz8g/vf_b09hlz8g_ab4e84c6-23f5-46a9-aea4-c3478add3d01.ism.hlsv2.ism/iptv_hd_abr_v1_dash_master.mpd?__gda__=1513182214_cbbc75654e7f5b43589a44ecde2df3bd
INFO: Getting URL:
http://vod-dash-uk-live.bbcfmt.hs.llnwd.net/usp/auth/vod/piff_abr_full_sd_ad/3172c5-b09hlz8g/vf_b09hlz8g_ab4e84c6-23f5-46a9-aea4-c3478add3d01.ism.hlsv2.ism/iptv_hd_abr_v1_dash_master.mpd?s=1513139014=1513182214=9eccf2f6b09c53eca6ad67496675c5ba
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/pc/vpid/p05p91x1/transferformat/dash?cb=88101
ERROR: Response: 403 No Protocol
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/iptv-all/vpid/p05p91x1/transferformat/hls?cb=65088
ERROR: Response: 403 No Protocol
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/apple-ipad-hls/vpid/p05p91x1/transferformat/hls?cb=34729
ERROR: Response: 403 No Protocol
INFO: No streams available for 'audiodescribed' version (p05p91x1) -
skipping
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/iptv-all/vpid/b09hlz8g/transferformat/dash?cb=82852
INFO: Getting URL:
http://vod-dash-uk-live.akamaized.net/usp/auth/vod/piff_abr_full_hd/3172c5-b09hlz8g/vf_b09hlz8g_c6f5a28e-45a1-4db2-ae5a-490bffd8dc84.ism.hlsv2.ism/iptv_hd_abr_v1_dash_master.mpd?__gda__=1513182229_9e5f766da2f24338e5de21cf8527aa48
INFO: Getting URL:
http://vod-dash-uk-live.bbcfmt.hs.llnwd.net/usp/auth/vod/piff_abr_full_hd/3172c5-b09hlz8g/vf_b09hlz8g_c6f5a28e-45a1-4db2-ae5a-490bffd8dc84.ism.hlsv2.ism/iptv_hd_abr_v1_dash_master.mpd?s=1513139029=1513182229=52587baf738286ac7d4e00eba2989aed
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/pc/vpid/b09hlz8g/transferformat/dash?cb=55978
ERROR: Response: 403 No Protocol
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/iptv-all/vpid/b09hlz8g/transferformat/hls?cb=38674
ERROR: Response: 403 No Protocol
INFO: Getting URL:
http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/apple-ipad-hls/vpid/b09hlz8g/transferformat/hls?cb=24356
ERROR: Response: 403 No Protocol
INFO: Found mode 'dvfhd1': (gip_dvf_iplayer_5070) dash h264 1280x720
50fps 5070kbps stream (CDN: mf_limelight_uk_dash/2)
INFO: Found mode 'dvfhd2': (gip_dvf_iplayer_5070) dash h264 1280x720
50fps 5070kbps stream (CDN: mf_akamai_uk_dash/1)
INFO: Found mode 'dvfsd1': (gip_dvf_iplayer_2812) dash h264 960x540
50fps 2812kbps stream (CDN: mf_limelight_uk_dash/2)
INFO: Found mode 'dvfsd2':
Re: With 3.07 .dash.m4v left behind
On 7/12/2017 3:00 AM, RS wrote: > From: Ralph Corderoy > Sent: Wednesday, December 6, 2017 2:08 PM > >> That just means get_iplayer is ignoring the failure to remove the file >> rather that report it to you. A quick skim of all the `unlink' function >> calls show none have their return value checked. > > Hi Ralph and Nick > > What level of error reporting is being used? The default (since v3.06) > > --ffmpeg-loglevel=fatal > > does not even report running out of disk space for the output file. > If you use > > --ffmpeg-loglevel=info or --ffmpeg-loglevel=verbose > > it may tell you what the error is. > > Running get_iplayer with --verbose may also help to narrow down where > the failure is occurring. Doesn't look as though using --verbose gives any information to help with the problem. Here's the last part of the console output from downloading the latest Peaky Blinders episode with --verbose. The output folder at the end of the download still contains the .dash.m4v and -temp-32694.mp4 files as well as the expected .mp4 file. === INFO: Converting to MP4 INFO: Command: "ffmpeg" "-loglevel" "fatal" "-stats" "-y" "-i" "D:\Users\Nick\Videos\Peaky_Blinders-s04e04-Dangerous.dash.m4a" "-i" "D:\Users\Nick\Videos\Peaky_Blinders-s04e04-Dangerous.dash.m4v" "-c:v" "copy" "-c:a" "copy" "-map" "0:a:0" "-map" "1:v:0" "D:\Users\Nick\Videos\Peaky_Blinders-s04e04-Dangerous.partial.mp4" frame=172416 fps=34275 q=-1.0 Lsize= 1741151kB time=00:57:28.29 bitrate=4136.4kbits/s speed= 685x INFO: Command exit code 0 (raw code = 0) INFO: Loading recordings history INFO: Downloading thumbnail INFO: Getting URL: http://ichef.bbci.co.uk/images/ic/192x108/p05nrw04.jpg INFO: Tagging MP4 INFO: Command: "AtomicParsley" "D:\Users\Nick\Videos\Peaky_Blinders-s04e04-Dangerous.mp4" "--freefree" "--overWrite" "--stik" "TV Show" "--advisory" "remove" "--copyright" "2017 British Broadcasting Corporation, all rights reserved" "--title" "Dangerous" "--artist" "BBC Two" "--albumArtist" "BBC TV" "--album" "Peaky Blinders: Series 4" "--grouping" "Drama,Crime,Classic & Period" "--composer" "BBC iPlayer" "--genre" "Drama" "--comment" "Tommy's enemies edge nearer as an old friend makes a welcomed return." "--year" "2017-12-06T21:00:00Z" "--tracknum" "4" "--disk" "4" "--lyrics" "The Peaky Blinders are lured by the Italians into a cat-and-mouse chase on the streets of Birmingham, where it becomes clear that Tommy has met his match. Trapped in Small Heath, Tommy tries to console himself with a visit from an old flame but it soon becomes clear that he can't always get what he wants. As his factory lies idle, Tommy confronts the possibility that the Communists might win and he will be deemed a traitor to his class. Meanwhile, Changretta prepares to spring another trap. EPISODE http://www.bbc.co.uk/iplayer/episode/b09j0hxs SERIES http://www.bbc.co.uk/programmes/p05hgs13; "--description" "Tommy's enemies edge nearer as an old friend makes a welcomed return." "--longdesc" "The Peaky Blinders are lured by the Italians into a cat-and-mouse chase on the streets of Birmingham, where it becomes clear that Tommy has met his match. Trapped in Small Heath, Tommy tries to console himself with a visit from an old flame but it soon becomes clear that he can't always get what he wants. As his factory lies idle, Tommy confronts the possibility that the Communists might win and he will be deemed a traitor to his class. Meanwhile, Changretta prepares to spring another trap." "--hdvideo" "true" "--TVShowName" "Peaky Blinders: Series 4" "--TVEpisode" "s04e04" "--TVSeasonNum" "4" "--TVEpisodeNum" "4" "--TVNetwork" "BBC Two" "--artwork" "D:\Users\Nick\Videos\Peaky_Blinders-s04e04-Dangerous.jpg" Started writing to temp file. Progress: ==> 98% -| Finished writing to temp file. INFO: Command exit code 0 (raw code = 0) D:\Users\Nick> === ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: With 3.07 .dash.m4v left behind
On 5/12/2017 9:44 PM, Ralph Corderoy wrote: > Hi Nick, > >> I assume this is meant to be deleted once the conversion to mp4 has >> been completed, but this isn't happening consistently. >> >> OS is Windows 10 x64. > Does Windows allow a file to be deleted if a process still has it open? > Unix does. Perhaps this is another manifestation of my guess in > http://lists.infradead.org/pipermail/get_iplayer/2017-November/011371.html > that got no replies, e.g. by people that know Windows and can track what > files are open when. In that previous case (temp file not able to be renamed) a permissions error appears on the console. In this case no problem is indicated at all. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
With 3.07 .dash.m4v left behind
I've had three instances since installing 3.07 where the download of a programme finishes without any problems or errors indicated in the console output, but as well as the mp4 file there is also a .dash.m4v file of slightly smaller size. I assume this is meant to be deleted once the conversion to mp4 has been completed, but this isn't happening consistently. OS is Windows 10 x64. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Cannot download b09hzwsn
GiP 3.07 on Windows 10 x64. When I try to download this pid (UK Snooker championship round 2 highlights part 2), it comes back with "no streams found". If I use --info on this pid, I can see that GiP doesn't find any available modes: == D:\Users\Nick>get_iplayer --pid="b09hzwsn" --info get_iplayer 3.07.0, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. Matches: WARNING: No media streams found for requested programme versions and recording modes. INFO: No versions of this programme were selected (available versions: none) brand: UK Snooker Championship categories: Sport,Snooker category: Sport channel: BBC Two desc: Hazel Irvine introduces continued live coverage from round two of the UK Championship. desclong: Hazel Irvine introduces continued live coverage from the second round of the UK Championship. descmedium: Hazel Irvine introduces continued live coverage from the second round of the UK Championship. descshort: Hazel Irvine introduces continued live coverage from round two of the UK Championship. dir: D:\Users\Nick\Videos\iplayer dldate: 2017-12-03 dltime: 12:26:56 episode: Second Round - Part 2 episodeshort: Second Round - Part 2 expires: in 29 days 16 hours (2018-01-01T18:00:00+00:00) ext: EXT filename: D:\Users\Nick\Videos\iplayer\UK_Snooker_Championship-s2017e00-Second_Round_-_Part_2.EXT filepart: D:\Users\Nick\Videos\iplayer\UK_Snooker_Championship-s2017e00-Second_Round_-_Part_2.partial.EXT fileprefix: UK_Snooker_Championship-s2017e00-Second_Round_-_Part_2 firstbcast: 2017-12-02T14:00:00Z firstbcastdate: 2017-12-02 firstbcastrel: 0 days 11 hours ago longname: UK Snooker Championship: 2017 name: UK Snooker Championship: 2017 nameshort: UK Snooker Championship pid: b09hzwsn player: http://www.bbc.co.uk/iplayer/episode/b09hzwsn senum: s2017e00 series: 2017 seriesnum: 2017 thumbfile: D:\Users\Nick\Videos\iplayer\UK_Snooker_Championship-s2017e00-Second_Round_-_Part_2.jpg thumbnail: http://ichef.bbci.co.uk/images/ic/192x108/p039pqhm.jpg title: UK Snooker Championship: 2017: Second Round - Part 2 type: tv version: default web: http://www.bbc.co.uk/programmes/b09hzw7s INFO: 0 matching programmes == If I run --info on part 1 of the second round highlights, the various modes show up for that one: == D:\Users\Nick\scripts>get_iplayer --pid="b09j3bhq" --info get_iplayer 3.07.0, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. Matches: brand: UK Snooker Championship categories: Sport,Snooker category: Sport channel: BBC One desc: Hazel Irvine introduces live coverage as the second round gets under way. desclong: Hazel Irvine introduces live coverage of the UK Championship second round, alongside former champions Steve Davis and John Parrott. The championship, which is the second most prestigious ranking tournament on the calendar, saw 128 players starting out on Tuesday, with up-and-coming rookies having a chance to take on established stars in front of the York Barbican Centre crowd. descmedium: Hazel Irvine introduces live coverage of the UK Championship second round, alongside former champions Steve Davis and John Parrott. descshort: Hazel Irvine introduces live coverage as the second round gets under way. dir: D:\Users\Nick\Videos\iplayer dldate: 2017-12-03 dltime: 12:27:51 duration: 2700 durations: original: 2700 episode: Second Round - Part 1 episodeshort: Second Round - Part 1 expires: in 29 days 12 hours (2018-01-01T14:00:00+00:00) ext: EXT filename: D:\Users\Nick\Videos\iplayer\UK_Snooker_Championship-s2017e00-Second_Round_-_Part_1.EXT filepart: D:\Users\Nick\Videos\iplayer\UK_Snooker_Championship-s2017e00-Second_Round_-_Part_1.partial.EXT fileprefix: UK_Snooker_Championship-s2017e00-Second_Round_-_Part_1 firstbcast: 2017-12-02T13:15:00Z firstbcastdate: 2017-12-02 firstbcastrel: 0 days 12 hours ago longname: UK Snooker Championship: 2017 modes: original: dvfhd1,dvfhd2,dvfsd1,dvfsd2,dvfhigh1,dvfhigh2,dvfxhigh1,dvfxhigh2,subtitles1 modesizes: original:
Re: Sometimes get file rename error at end of download
Yes, I've seen that other problem too. But in this case I don't see that it can be a connection issue - at the point where the error happens the download has completed and all the actions taking place are operations on local files. And I don't think in either case is it necessary to force another download. I just manually rename the files to remove the ".partial" or the "temp-xxx..." and they play to completion without problem. On 25/11/2017 10:07 PM, Alan Milewczyk wrote: > I get this from time to time, alternatively I get a file with a > -temp- suffix where x is a random series of numbers. IIRC it's > been put down to connnection issues. I've read that repeating the > download instruction is supposed to force the correct actions but > that's not worked for me. Forcing a download usually does the job though. > > A > > On 25/11/2017 18:57, Nick Payne wrote: >> Running get_iplayer 3.06 on Win10 x64. Sometimes the rename of the mp4 >> file at the end of a download fails. ffmpeg creates the partial.mp4 file >> without any problem, but get_iplayer.pl then fails to rename >> .partial.mp4 to mp4. It's not a permissions problem, else ffmpeg would >> not be able to create the partial.mp4 file. >> >> The problem doesn't happen on every download, maybe one in three. All >> downloads go into the same folder, in which I have full permissions. >> Relevant part of the console output from running with --verbose. >> >> INFO: Converting to MP4 >> INFO: Command: "ffmpeg" "-loglevel" "fatal" "-stats" "-y" "-i" >> "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.dash.m4a" >> "-i" >> "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.dash.m4v" >> "-c:v" "copy" "-c:a" "copy" "-map" "0:a:0" "-map" "1:v:0" >> "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.partial.mp4" >> >> frame=173860 fps=20666 q=-1.0 Lsize= 1853690kB time=00:57:57.16 >> bitrate=4367.2kbits/s speed= 413x >> INFO: Command exit code 0 (raw code = 0) >> ERROR: Could not rename file: >> D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.partial.mp4 >> ERROR: Destination file name: >> D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.mp4 >> INFO: Skipping all versions of this programme >> ERROR: Failed tv: 'Peaky Blinders: Series 4 - 2. Heathens (b09gvn5j)' >> >> >> >> >> ___ >> get_iplayer mailing list >> get_iplayer@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/get_iplayer >> > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > ___ > get_iplayer mailing list > get_iplayer@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/get_iplayer > ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Sometimes get file rename error at end of download
Running get_iplayer 3.06 on Win10 x64. Sometimes the rename of the mp4 file at the end of a download fails. ffmpeg creates the partial.mp4 file without any problem, but get_iplayer.pl then fails to rename .partial.mp4 to mp4. It's not a permissions problem, else ffmpeg would not be able to create the partial.mp4 file. The problem doesn't happen on every download, maybe one in three. All downloads go into the same folder, in which I have full permissions. Relevant part of the console output from running with --verbose. INFO: Converting to MP4 INFO: Command: "ffmpeg" "-loglevel" "fatal" "-stats" "-y" "-i" "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.dash.m4a" "-i" "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.dash.m4v" "-c:v" "copy" "-c:a" "copy" "-map" "0:a:0" "-map" "1:v:0" "D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.partial.mp4" frame=173860 fps=20666 q=-1.0 Lsize= 1853690kB time=00:57:57.16 bitrate=4367.2kbits/s speed= 413x INFO: Command exit code 0 (raw code = 0) ERROR: Could not rename file: D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.partial.mp4 ERROR: Destination file name: D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s04e02-Heathens.mp4 INFO: Skipping all versions of this programme ERROR: Failed tv: 'Peaky Blinders: Series 4 - 2. Heathens (b09gvn5j)' ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: 3.06 and 25fps/50fps modes
On 6/11/2017 7:43 PM, Alan Milewczyk wrote: > On 06/11/2017 08:03, Nick Payne wrote: >> I'm trying to download episodes 9 and 10 of Ken Burns' Vietnam War >> series via the command line. The previous eight episodes (downloaded >> with older versions of GiP) all downloaded as hlshd by specifying >> --tvmode=best, but when I use --tvmode=best for episodes 9 and 10, they >> are both downloading as dvfxhigh: > > Hi Nick > > I downloaded episodes 9 and 10 on Oct 24th around 04:00 using a timed > batch file and both programmes are 1280x720 and comparable size to > others in the series. I've just done an --info and hlshd is present. > > > Regards > > Alan Alan Thanks, but I'm not seeing any hls modes. Here is the output from GiP from --info for episode 9, no hls modes are listed under modes, and I have to use --fps50 to get the 1280x720 50fps version, which is about 75% larger than the previous 1280x720 25fps episodes I downloaded: D:\Users\Nick>get_iplayer --pid=b09bdyrl --info get_iplayer 3.06.0, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. Matches: brand: The Vietnam War categories: Factual,History,Documentaries category: Factual channel: BBC Four desc: South Vietnamese forces fighting on their own in Laos suffer a terrible defeat. desclong: South Vietnamese forces fighting on their own in Laos suffer a terrible defeat. Massive US airpower makes the difference in halting an unprecedented North Vietnamese offensive. After being re-elected in a landslide, Nixon announces that Hanoi has agreed to a peace deal. American prisoners of war will finally come home - to a bitterly divided country. descmedium: Series telling the story of the Vietnam War. Massive US airpower makes the difference in halting an unprecedented North Vietnamese offensive. descshort: South Vietnamese forces fighting on their own in Laos suffer a terrible defeat. dir: D:\Users\Nick\Videos\iplayer dldate: 2017-11-05 dltime: 18:28:00 duration: 3300 durations: original: 3300 episode: 9. Fratricide (May 1970-March 1973) episodenum: 9 episodeshort: Fratricide (May 1970-March 1973) expires: in 16 days 14 hours (2017-11-22T21:55:00+00:00) ext: EXT filename: D:\Users\Nick\Videos\iplayer\The_Vietnam_War-s01e09-Fratricide_May_1970-March_1973.EXT filepart: D:\Users\Nick\Videos\iplayer\The_Vietnam_War-s01e09-Fratricide_May_1970-March_1973.partial.EXT fileprefix: The_Vietnam_War-s01e09-Fratricide_May_1970-March_1973 firstbcast: 2017-10-23T22:00:00+01:00 firstbcastdate: 2017-10-23 firstbcastrel: 13 days 10 hours ago longname: The Vietnam War: Series 1 modes: original: dvfhd1,dvfhd2,dvfsd1,dvfsd2,dvfhigh1,dvfhigh2,dvfxhigh1,dvfxhigh2,subtitles1 modesizes: original: dvfhd1=1981MiB,dvfhd2=1981MiB,dvfsd1=1099MiB,dvfsd2=1099MiB,dvfhigh1=613MiB,dvfhigh2=613MiB,dvfxhigh1=323MiB,dvfxhigh2=323MiB,subtitles1=82KiB [estimated sizes only] name: The Vietnam War: Series 1 nameshort: The Vietnam War pid: b09bdyrl player: http://www.bbc.co.uk/iplayer/episode/b09bdyrl runtime: 55 senum: s01e09 series: Series 1 seriesnum: 1 thumbfile: D:\Users\Nick\Videos\iplayer\The_Vietnam_War-s01e09-Fratricide_May_1970-March_1973.jpg thumbnail: http://ichef.bbci.co.uk/images/ic/192x108/p05k8yvq.jpg title: The Vietnam War: Series 1: Fratricide (May 1970-March 1973) type: tv verpids: original: b0999sll version: original versions: original web: http://www.bbc.co.uk/programmes/b096k8kx ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
3.06 and 25fps/50fps modes
I'm trying to download episodes 9 and 10 of Ken Burns' Vietnam War series via the command line. The previous eight episodes (downloaded with older versions of GiP) all downloaded as hlshd by specifying --tvmode=best, but when I use --tvmode=best for episodes 9 and 10, they are both downloading as dvfxhigh: == D:\Users\Nick>get_iplayer --pid=b09bdyrl --tvmode=best []... INFO: Downloading tv: 'The Vietnam War: Series 1 - 9. Fratricide (May 1970-March 1973) (b09bdyrl) [original]' INFO: Downloaded: 49.65 MiB (00:54:39) @ 5.70 Mibit/s (dvfxhigh1) [audio] INFO: Downloaded: 306.02 MiB (00:54:39) @ 9.83 Mibit/s (dvfxhigh1) [video] == When I run get_iplayer --pid=b09bdyrl --info, it shows me that the modes available are modes: original: dvfhd1,dvfhd2,dvfsd1,dvfsd2,dvfhigh1,dvfhigh2,dvfxhigh1,dvfxhigh2,subtitles1 so no hls modes are available - it looks as though if I don't have --fps50 specified, and no hls modes are available, then the recording defaults to the *lowest* available quality. Is there a combination of options I can specify to have highest available quality at 25fps as the default and fall back to the highest available quality at 50fps if 25fps is not available? According to the documentation, I can do it the other way around if I specify --fps50 on the command line, as it will then fall back to 25fps if no 50fps streams are available, but I find that 25fps is more than adequate for most content, and it downloads in half the time. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Recordings folder changed
Out of curiosity I changed the drive letter for my external backup drive to U: and then ran the get_iplayer command to change the output folder in the options file (GiP 3.06 on Windows 10) D:\Users\Nick>get_iplayer --prefs-add --output="C:\Users\graham.temple\Desktop\New folder" INFO: Changed option 'output' from 'D:\Users\Nick\Videos\iplayer' to 'C:\Users\graham.temple\Desktop\New folder' INFO: Options file C:\Users\Nick\.get_iplayer\options updated and when I checked the options file the output line had been changed correctly output C:\Users\graham.temple\Desktop\New folder and I was able to also change it back to my normal default without problem. Windows uses backslashes rather than forward slashes for delineating paths. What happens if you issue the command using backslashes? Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
3.05 separate downloads for video+audio and audio
I recently upgraded from 3.02 to 3.05. I notice that with the new version, when I download a TV programme GiP performs two separate downloads. The first is shown in the terminal output as being [audio+video], the second much smaller download as just being [audio]. Why the two separate downloads? If I play the first [audio+video] download (this file has an hls.ts extension) while the separate [audio] download has not yet completed, the audio is already there in the file, so why the second download? This is what I see on the console: INFO: Downloading tv: 'Kaufmann's Otello at the Royal Opera House - - (b099tpcb) [original]' INFO: Downloaded: 2685.38 MiB (02:30:10) @ 7.92 Mibit/s (hlshd1) [audio+video] INFO: Downloaded: 363.78 MiB (02:30:10) @ 7.35 Mibit/s (hvfhd1) [audio] INFO: Converting to MP4 INFO: Tagging MP4 Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
ffmpeg conversion
What is the ffmpeg command that GiP uses to convert the ts downloads to mp4? I occasionally find after downloading a program that for some reason the conversion to mp4 has not happened and I only have the ts file. I can convert this to mp4 with ffmpeg using the following command, but that takes about 20 minutes to convert a one hour program downloaded using hlshd, and so is obviously not the way the GiP does it. ffmpeg -i input.ts -c:v libx264 -c:a copy -bsf:a aac_adtstoasc output.mp4 ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: TV Audio Bitrates
On 24/08/2017 8:49 AM, tellyaddict wrote: Hi All, With 3.02 of GiP, all HVF modes now use 320 kbps audio. Not so. I just downloaded the BBC Proms recording of Ravi Shankar & Philip Glass using 3.02 and hvfsd, and MediaInfo reports the video as 960*540 @50fps and the audio as 48kHz 2 channel AAC. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Red Button now on iPlayer
On 15/05/2017 8:50 PM, RS wrote: > [snip]... > > There are no HLShd modes, but this appears to be normal for Red Button > coverage. What I noticed with the red button coverage for the recently finished World Snooker Championships was that if I downloaded the coverage as soon as it became available, then no HD downloads were available, but if I waited a few hours, then HD downloads *were* available. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
GiP 2.30 - unexpected size for segment
Was simultaneously downloading the afternoon and evening sessions of the final day of the World Snooker Championships. The afternoon session downloaded without any hiccups at all, but the download of the evening session had several instances of reporting "Unexpected size for segment". The download did complete successfully after resizing and resuming at each error point: [...] WARNING: Unexpected size for segment [272] WARNING: Expected: 2054840 Downloaded: 769070 WARNING: Retrying download WARNING: Stopped recording file: D:\Users\Nick\Videos\Snooker_World_Championship-s01e01-Monday_Final_Evening.video.ts WARNING: Stopped recording at: 417.77 MiB (00:34:41) [271] WARNING: Retry recording for 'Snooker: World Championship: 2017 - Monday, Final, Evening (b08pmslj)' INFO: File name prefix = Snooker_World_Championship-s01e01-Monday_Final_Evening INFO: Resizing file: D:\Users\Nick\Videos\Snooker_World_Championship-s01e01-Monday_Final_Evening.video.ts INFO: Resizing from 438832758 to 438063688 for resume INFO: Resume recording file: D:\Users\Nick\Videos\Snooker_World_Championship-s01e01-Monday_Final_Evening.video.ts INFO: Resume recording at: 417.77 MiB (00:34:41) [272] ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No .xml - what is work-around?
On 28/04/2017 11:21 PM, artisticforge . wrote: > get_iplayer-2.99 > > completely and utterly broken. Nonsense. I started this D/L five minutes ago. I get no meaningful filename or embedded program information, but the program downloads ok: D:\Users\Nick\scripts>get_iplayer --pid="b08nz0j0" --output=D:\Users\Nick\Videos get_iplayer 2.99-windows.0, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. NOTE: A UK TV licence is required to legally access BBC iPlayer TV content WARNING: rdf URL contained no data WARNING: PID URL contained no RDF data. Trying to record PID directly. INFO: Trying pid: b08nz0j0 using type: tv INFO: Trying to download PID using type tv INFO: pid not found in tv cache Matches: INFO: 1 Matching Programmes WARNING: Could not download programme metadata from http://www.bbc.co.uk/programmes/b08nz0j0.xml INFO: Checking existence of original version INFO: hlshd1,hlshd2,hvfxsd1,hvfxsd2,dvfxsd1,dvfxsd2,dvfxsd3,hlsvhigh1,hvfxhigh1,hvfxhigh2,dvfxhigh1,dvfxhigh2,dvfxhigh3,hvflow1,hvflow2,dvflow1,dvflow2,dvflow3 modes will be tried for version original INFO: Trying hlshd1 mode to record tv: get_iplayer - b08nz0j0 INFO: File name prefix = get_iplayer-b08nz0j0 INFO: Begin recording file: D:\Users\Nick\Videos\get_iplayer-b08nz0j0.video.ts INFO: Begin recording at: 0.00 MiB (00:00:00) [1] ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No programme schedules?
On 14/03/2017 11:53 AM, tellyaddict wrote: > Downloading is impossible by any method at the moment due to the missing xml > feeds. Not so. I started a D/L using --pid= a few minutes ago, and it's running as I type... ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Why mp4 or mp4.ts from identical installation?
Well both downloads I've done since installing 2.98 yesterday (on Windows 10) have resulted in three output files in the download directory after the download completed, all three files being approximately the same size: the expected download with mp4 file extension, a temp-n.mp4 file (n being a five digit number), and a file with the hls.ts extension. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Recover file from "failed to download segment"
On 4/12/2016 10:25 AM, Vangelis forthnet wrote: > On Sat Dec 3 21:32:54 GMT 2016, Nick Payne wrote: > >> what do I need to run to convert the partial.mp4.ts file to an mp4? > > In all probability, you should still be able to play > a partial MPEG-TS file (.ts extension, inside the > MPEG-TS container) with most of the known > software players (e.g MPC-HC & its fork MPC-BE > - on Windows - are both known to work), > especially since the missing segment occurs > at the end of the partial file (so timestamps > should be OK by that point). > Even hardware players with AVC/AAC support > should also be able to cope with... > > If you MUST have the MP4 media container, use ffmpeg: > > ffmpeg -v 8 -stats -i ".partial.mp4.ts" -c copy -bsf:a > aac_adtstoasc ".partial.mp4" > > where "" is the name/title of your download. Thanks. I found that my LG TV set, which can function as a DLNA renderer, will play the partial.mp4.ts file without any problem via DLNA. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Recover file from "failed to download segment"
I had one of the "Failed to download segment" errors right near the end of downloading coverage of the UK snooker championship, and I'm left with a partial.mp4.ts file. The file is 5Gb in size - GiP expected a file size of 5066Mb and had downloaded 5067Mb at the point where the error occurred. As I don't want to download 5Gb again, and don't care if a bit of the coverage is missing, what do I need to run to convert the partial.mp4.ts file to an mp4? Running GiP 2.97 on Windows 10. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Beeb encoding different programs at quite different framerates
On 28/10/2016 9:04 PM, RS wrote: > >> Well, the size keeps shrinking. The very latest episode of The Fall >> (just downloaded using hvfhd1 but not yet watched) is down to 647Mb for >> 59 minutes of 1280x720@50fps, video bit rate 1403kbps. This is about 2/3 >> the size of the old flashhd GiP 1280x720@25fps downloads, which used to >> always run around the 1Gb mark for an hour long program. > > Is this episode 5, b080y01r? It may be an idea to skip through the > download with VLC to check it is complete. --info shows the size for > HVFHD1 as 2325MB. The HVF downloader shows the size as 2320.91MB. Yes, that's what I downloaded. On a quick flip through in VLC it all seems to be there. However, the HVF downloader also shows the HVFHD download size for episode 4 as being 2325Mb, whereas the downloaded file that I have is only 898Mb, is certainly complete as I've watched the entire episode, and is, according to both VLC and Mediainfo, 1280x720@50fps using the H.264 codec. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Beeb encoding different programs at quite different framerates
Well, the size keeps shrinking. The very latest episode of The Fall (just downloaded using hvfhd1 but not yet watched) is down to 647Mb for 59 minutes of 1280x720@50fps, video bit rate 1403kbps. This is about 2/3 the size of the old flashhd GiP 1280x720@25fps downloads, which used to always run around the 1Gb mark for an hour long program. On 28/10/2016 6:43 AM, CJB wrote: > I too have noticed strange differences when replaying video files > which should have had almost identical metadata. BTW I use the default > settings on the Windows PVR all of the time. I always use VLC to > playback downloads. Recently I have downloaded two programmes - one > payed smoothly with well sync'd audio - the other was 'jerky' with > well out of sync'd audio. I shall have to look at the properties. CJB > > On 27/10/2016, Nick Payne <njh...@gmail.com> wrote: >> The video quality seems perfectly fine in both cases, but I was >> surprised to see that one download was more than twice the size of the >> other, both being virtually the same duration and at the same resolution >> and frame rate. I just compared recently downloaded episodes of The Fall >> and The Missing. The audio in both files is 125kbps AAC, the difference >> is all in the video. Both downloaded using --modes=hlsbest. >> >> The Fall: 59m 30s, 1280x720, 50fps, video bit rate 1976 kbps, file size >> 898Mb >> >> The Missing: 58m 54s, 1280x720, 50fps, video bit rate 4549 kbps, file >> size 1.93Gb >> >> >> Nick >> >> >> ___ >> get_iplayer mailing list >> get_iplayer@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/get_iplayer >> > ___ > get_iplayer mailing list > get_iplayer@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/get_iplayer > ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Beeb encoding different programs at quite different framerates
The video quality seems perfectly fine in both cases, but I was surprised to see that one download was more than twice the size of the other, both being virtually the same duration and at the same resolution and frame rate. I just compared recently downloaded episodes of The Fall and The Missing. The audio in both files is 125kbps AAC, the difference is all in the video. Both downloaded using --modes=hlsbest. The Fall: 59m 30s, 1280x720, 50fps, video bit rate 1976 kbps, file size 898Mb The Missing: 58m 54s, 1280x720, 50fps, video bit rate 4549 kbps, file size 1.93Gb Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Error in TV modes table
In the table of TV modes at https://github.com/get-iplayer/get_iplayer/wiki/modes#tv-modes, the recording mode hlshigh appears in the table twice (the 3rd and 9th rows). I think the mode for second occurrence should be hvfhigh, which is missing from the table. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Simultaneous D/L warnings in 2.95.1
Well it seems the problem isn't due to simultaneous downloads, as it happened again today with only a single download running. But this time it was only a single warning message, the rest of the program downloaded without any more warnings: INFO: Episode-only pid detected INFO: Trying pid: b07l1zvw using type: tv INFO: Trying to stream pid using type tv INFO: pid not found in tv cache Matches: INFO: 1 Matching Programmes INFO: Checking existence of original version INFO: hlshd1,hlsvhigh1,hlshigh1,hlsstd1,hlslow1 modes will be tried for version original INFO: Trying hlshd1 mode to record tv: Forces of Nature with Brian Cox - 3. The Moth and the Flame INFO: File name prefix = Forces_of_Nature_with_Brian_Cox.s01e03.The_Moth_and_the_Flame INFO: Begin recording file: D:\Users\Nick\Videos\iplayer\Forces_of_Nature_with_Brian_Cox.s01e03.The_Moth_and_the_Flame.partial.mp4.ts WARNING: Segment not found (13) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-337a7a28-ae94-4436-9815-5024e6c5dc75_b07l1wv4_1468052918769,1500kbps/modav/bUnknown-337a7a28-ae94-4436-9815-5024e6c5dc75_b07l1wv4_1468052919396,3200kbps/modav/bUnknown-337a7a28-ae94-4436-9815-5024e6c5dc75_b07l1wv4_1468058730774,.mp4.csmil/segment13_2_av.ts WARNING: There may be a gap near 120 secs in programme On 14/07/2016 3:03 PM, Nick Payne wrote: I installed GiP 2.95.1 Windows version a couple of days ago (previously using 2.94). While downloading two programs simultaneously this morning in two terminal windows (King Lear parts 1 & 2), both downloads were periodically spitting warnings like the below, and when the downloads completed, although they went all the way through to the credits, they were both only about half the length indicated for the programs (~45mins each as opposed to the 90 mins per program shown on the iPlayer web site). When I ran the downloads sequentially rather than simultaneously, both programs downloaded without any warnings and at the full length. I frequently ran simultaneous downloads with 2.94 and never saw this problem. WARNING: Segment not found (484) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment484_2_av.ts WARNING: There may be a gap near 4830 secs in programme WARNING: Segment not found (485) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment485_2_av.ts WARNING: There may be a gap near 4840 secs in programme WARNING: Segment not found (486) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment486_2_av.ts WARNING: There may be a gap near 4850 secs in programme WARNING: Segment not found (487) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment487_2_av.ts WARNING: There may be a gap near 4860 secs in programme ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: hlshd download speeds
On 15/07/2016 8:24 AM, RS wrote: From what I have been reading it seems that Windows 10 and Windows 8.1 have problems with USB 3 drives. In some cases they stop being recognised after a period of idle time. I have not had that, but there is a really dramatic slowing down. I've never seen a USB3 slowdown on either operating system on any of our PCs or laptops, nor had any USB3 connected devices suddenly drop from view. I run my backups to external USB3 drives, and the Robocopy log from the latest backup of my PC reports average throughput to the USB3 drive as being 120Mb/sec: TotalCopied Skipped MismatchFAILEDExtras Dirs : 32064 2 32062 0 0 0 Files :13488653134833 0 016 Bytes : 1.362 t 73.940 g 1.290 t 0 0 309.96 m Times : 0:13:47 0:10:29 0:00:00 0:03:17 Speed : 126073800 Bytes/sec. Speed :7214.000 MegaBytes/min. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Simultaneous D/L warnings in 2.95.1
I installed GiP 2.95.1 Windows version a couple of days ago (previously using 2.94). While downloading two programs simultaneously this morning in two terminal windows (King Lear parts 1 & 2), both downloads were periodically spitting warnings like the below, and when the downloads completed, although they went all the way through to the credits, they were both only about half the length indicated for the programs (~45mins each as opposed to the 90 mins per program shown on the iPlayer web site). When I ran the downloads sequentially rather than simultaneously, both programs downloaded without any warnings and at the full length. I frequently ran simultaneous downloads with 2.94 and never saw this problem. WARNING: Segment not found (484) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment484_2_av.ts WARNING: There may be a gap near 4830 secs in programme WARNING: Segment not found (485) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment485_2_av.ts WARNING: There may be a gap near 4840 secs in programme WARNING: Segment not found (486) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment486_2_av.ts WARNING: There may be a gap near 4850 secs in programme WARNING: Segment not found (487) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793857609,1500kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466793854241,3200kbps/modav/bUnknown-3c717156-f406-46f4-a0fe-e475e8952dbd_p03zc3n5_1466798710273,.mp4.csmil/segment487_2_av.ts WARNING: There may be a gap near 4860 secs in programme ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Where should problems with dev version be reported?
I was using the 2.95 dev version of get_iplayer, downloaded from git a couple of days ago. First couple of downloads completed without any problem, the third failed - looks from the messages as though there might have been an interruption to my Internet connection, but the last line seems to indicate an internal problem caused by the interruption: INFO: Begin recording file: D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s03e02-Episode_2-b07bksbb.partial.mp4.ts Recording: 420.42MB / 992.83MB 985kbps 42.3% 01:19:22 remaining ERROR: Failed to download segment (144) http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-aaf2dff4-3fd9-4fd2-b477-dcbfcbb575e8_b07bks81_1462207270382,1500kbps/modav/bUnknown-aaf2dff4-3fd9-4fd2-b477-dcbfcbb575e8_b07bks81_1462207270231,3200kbps/modav/bUnknown-aaf2dff4-3fd9-4fd2-b477-dcbfcbb575e8_b07bks81_1462213589919,.mp4.csmil/segment144_2_av.ts INFO: Recorded: 421.27MB in 00:59:21 at 969kbps to D:\Users\Nick\Videos\iplayer\Peaky_Blinders-s03e02-Episode_2-b07bksbb.partial.mp4.ts WARNING: Retry recording for 'Peaky Blinders: Series 3 - 2. Episode 2 (b07bksbb)' INFO: File name prefix = Peaky_Blinders-s03e02-Episode_2-b07bksbb Can't locate object method "new" via package "Streamer::" (perhaps you forgot to load "Streamer::"?) at get_iplayer.pl line 8982. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Spurious write permission error
Running GiP 2.94 on Windows. I had two downloads running simultaneously, both writing to the same directory. One download completed without any problem indicated, the other put out the following on the console at the end of the download: INFO: MP4 tagging MP4 file Started writing to temp file. Progress: ===> 99% | Finished writing to temp file. Unable to write to a directory lacking write permission.INFO: Command exit code 255 (raw code = 65280) WARNING: Failed to tag MP4 file When I have a look in the output directory, there is an output MP4 file for the download that gave the error with "-temp-22448" appended to the end of the filename. I can play the MP4 in VLC without any error. I've also noticed on some occasions that after the download has finished, both the permanent download file and the file with "-temp-x" appended are present in the output directory. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
What determines the resolution GiP selects for download?
I've been downloading some of the coverage of the world snooker championships. All the downloads use the command line get_iplayer --pid="%1" --modes=hlsbest but I find that the resolution of the downloaded mp4 files varies quite a lot. Most are 1280x720, but some are 960x540, some are 832x468, and a couple are only 704x396. I retried one of the downloads that was only 704x396, using the same command line with the addition of --force, and the second time it downloaded at 832x468, so I'm wondering how GiP determines what resolution to download? I'm running GiP v2.94 on Windows. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audio and video gradually go out of sync
On 20/04/2016 9:50 AM, Vangelis forthnet wrote: On Tue Apr 19 23:00:46 BST 2016, Nick Payne wrote: but the audio and video on the Day 3 program gradually get out of sync as the program progresses - they're in sync at the start, but by the end of the 50 minutes of the program, the audio is about half a dozen seconds in advance of the video. (snip) At the moment, I don't know whether this is a problem with the GiP processing at my end or with the download from the BBC. Using GiP 2.94 on Windows. Hi Nick, am afraid more info is needed... On what tvmode downloaded have you experienced the gradual loss of AV sync? Was it a flash mode (flashhd, flashvhigh etc.) or a hls one (hlshd, hlsvhigh etc.)? Vangelis Thanks. I used --modes=hlsbest for the download. This is the same option as for the other downloads which didn't suffer this loss of sync. I didn't notice any errors indicated in the console window. Does GiP create a log file? I couldn't find one. Regards Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: BBC Breakfast News - 3 Feb 2016
If you have the program downloaded, Avidemux can extract a segment from it. On 3/02/2016 8:12 PM, CJB wrote: Does anyone know how to extract a clip of today's News at about 8.50 am to 9.10? http://www.bbc.co.uk/programmes/b06z4pnd ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Msg: non-existing SPS 0 referenced in buffering period
I'm using GiP 2.94 on Windows 10 x64. The command line I use for download is: get_iplayer --pid= --modes=hlsbest Every single program I download shows the error msg I've given in the title in the terminal window. The downloads all complete successfully and the files play without any problem. Here's the part of the terminal output surrounding the msg (it always appears twice): ffmpeg version 2.2.3 Copyright (c) 2000-2014 the FFmpeg developers built on Jun 19 2014 20:24:25 with gcc 4.8.3 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat55. 33.100 / 55. 33.100 libavdevice55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libswscale 2. 5.102 / 2. 5.102 libswresample 0. 18.100 / 0. 18.100 libpostproc52. 3.100 / 52. 3.100 [h264 @ 02a3a520] non-existing SPS 0 referenced in buffering period Last message repeated 1 times [h264 @ 05704040] non-existing SPS 0 referenced in buffering period Input #0, hls,applehttp, from 'http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,400kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181900755,480kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181892745,800kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181899250,1500kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181897590,.mp4.csmil/index_3_av.m3u8?hdnea=st=1450297038~exp=1450318638~acl=/*400kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181900755,480kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181892745,800kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181899250,1500kbps/modav/bUnknown-94269304-a1c6-4bc4-9fd8-6715141d7a1b_p03c3yq9_1450181897590*~hmac=d2dd821878b39b57c676325550a0c01daeaa8092db826ceba95657afbc620338': ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GiP mp4s and Panasonic PVR
On 23/11/2015 6:28 AM, Peter S Kirk wrote: On 22 Nov 2015 at 22:42, Nick Payne Nick Payne <nick.pa...@internode.on.net> wrote: I recently purchased a Panasonic DMR-HWT250 PVR, which can also function as a DLNA client - I run Serviio on my PC as the server. I can use the DLNA client on the PVR to play MP4s I create myself, but if I try to play any of the MP4s downloaded by GiP, I just get a "Please wait" message on the TV screen and the file never starts playing. I re-encoded a couple of the GiP MP4s using VidCoder (which uses HandBrake as its encoding engine), and then copied the re-encoded MP4s over the ones downloaded by GiP, and those re-encoded MP4s play through the DLNA client without any problem... I'm running GiP 2.94 on Windows, and the command I use is just get_iplayer --pid= --modes=hlsbest Any suggestions on any command line options I can try to get around this problem? Try running the mp4 through mkvtoolnix, the conversion to mkv seems to strip out a lot of the container info that iPlayer and GiP add. Thanks for the suggestion. I found that adding the --mkv command line option to GiP created an mkv output file directly that the DLNA client in the PVR played without any problem. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audacity, get_iplayer & Windows 10
On 18/11/2015 9:48 PM, CJB wrote: OK - that's all good to know. But ... do I really need to upgrade to Win 10 anyway? Its the aggressive forcing of the issue that riles me. My little Acer notebook hasn't the capacity for a full blown Windows. I only have Win 7 Starter anyway. And my 250GB hard drive is full of video and audio files. There's no room for more bloat from MS. But the killer is the enforced updates. How dare MS dictate my lifestyle. Life is too short. I only have a Three mobile dongle with a contract for 5GB a month. So updates I do at MacD's on free wifi and in my own time. I don't need MS stealing my small allowance. You just define the connection as metered and updates won't automatically download when you're using it: http://lifehacker.com/enable-metered-connection-to-delay-windows-10-updates-1723316525. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Audacity, get_iplayer & Windows 10
On 18/11/2015 05:21, CJB wrote: Audacity is the music editing app. that I am most familiar with. I like it. It works. I also use it to process downloads from get_iplayer. However with Microsoft's increasingly aggressive stance in forcing upgrades to Windows 10 I am concerned. I have heard that Audacity does not work with Win 10. Is this correct? What are possible work-arounds? Is there an alternative Audacity-like app.? And does get_iplayer work with Win 10? Both Audacity and get_iplayer work ok for me on Windows 10 x64... ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Problems with --exclude-supplier=akamai and HD downloads
For many months I have used --exclude-supplier=akamai on my GiP command line as it results in a 10- or 12-fold increase in download speed compared to the throughput I get without that option - with the option, an hour long problem @1280x720 will download in around 5-6 minutes, without it the download takes about an hour. The command line I have been using is get_iplayer --pid= --exclude-supplier=akamai I returned from a weeks holiday yesterday and attempted to download a couple of BBC Proms programs using my normal command line, but found that 1280x720 resolution was not found and the download started at 832x468 resolution. Killed the download, removed the --exclude-supplier=akamai option, and the download started at 1280x720, but I was back to the much slower download speed. Any suggestions on how I can still get HD downloads at the faster rate? Running GiP 2.94 on Windows 8.1. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Problems with --exclude-supplier=akamai and HD downloads
On 15/09/2015 09:12, tellyaddict wrote: For many months I have used --exclude-supplier=akamai on my GiP command line as it results in a 10- or 12-fold increase in download speed compared to the throughput I get without that option - with the option, an hour long problem @1280x720 will download in around 5-6 minutes, without it the download takes about an hour. The command line I have been using is get_iplayer --pid= --exclude-supplier=akamai I returned from a weeks holiday yesterday and attempted to download a couple of BBC Proms programs using my normal command line, but found that 1280x720 resolution was not found and the download started at 832x468 resolution. Killed the download, removed the --exclude-supplier=akamai option, and the download started at 1280x720, but I was back to the much slower download speed. Any suggestions on how I can still get HD downloads at the faster rate? Running GiP 2.94 on Windows 8.1. Have a read of https://squarepenguin.co.uk/forums/thread-520.html. This is a known issue as something has changed at the BBC. I agree that Akamai is slower than Level3, but it is not that slow. From the akamai server an hour long programme takes about 10 minutes. Ok, thanks. Looks like there's no remedy at the moment until Level3 fix whatever their problem is. And for me, Akamai is dead slow and always has been. I just downloaded Beck, and it took ~3-1/2 hours for the 1.42Gb 1280x720 HD file to complete downloading. Normally, downloads off Level3 run at my full connection speed of around ~15Mbit, and a download of that size would take 12-15 minutes. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [Maybe OT]British Library National Audit of Sound Collections
On 19/05/2015 21:09, David Cantrell wrote: In this case the tapes are whatever unsigned bands consisting of impoverished students could buy in bulk. So cheap crap made out of swarf and brown paint probably. A friend of mine who spent a couple of decades repairing VCRs once said to me: Using cheap tapes in your machine is like running a mixture of sandpaper and chewing gum past the heads... ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Temp file remaining at end of download
Using GiP 2.92 on Windows. Every so often, when a download completes, and seems to complete successfully, I find that as well as the expected downloaded file, there is also what appears to be a temporary file of almost exactly the same size in the same output folder. For instance, I just downloaded episode 3 of The Game, and the output folder contains the files: The_Game_Episode_3_b05vnkjw.mp4 - size 1,062,517,931 bytes and The_Game_Episode_3_b05vnkjw-temp-22211.mp4 - size 1,062,523,965 bytes Both files have the same timestamp, and both play right through to the end without any problem. I just delete the version with temp in the filename, but any ideas on why this happens? Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Downloads hanging
On 13/05/2015 21:17, Alan Milewczyk wrote: On 13/05/2015 09:27, Jed Robbins wrote: In the last few weeks my downloads have stopped working. Get_iplayer seems to connect but then nothing happens i.e. get_iplayer --get --type=radio --pid b05tl3jk get_iplayer 2.92-ppa22, Copyright (C) 2008-2010 Phil Lewis =snip== This happens for tv and radio and on both linux and windows. Has anyone else experienced the same issue? Is there a solution? I don't know what get_iplayer 2.92-ppa22 is, but I'm using gip v2.92 Win7x64. I've not had any problems whatsoever and I downloaded the above programme yesterday evening without difficulties. ppa22 is from the PPA for Ubuntu Linux and derivatives: https://launchpad.net/~jon-hedgerows/+archive/ubuntu/get-iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Downloads hanging
On 14/05/2015 01:06, Vangelis forthnet wrote: On Wed May 13 09:27:37 BST 2015, Jed Robbins wrote: In the last few weeks my downloads have stopped working. Get_iplayer seems to connect but then nothing happens i.e. ... get_iplayer 2.92-ppa22, ... RTMPDump v2.4-n87-gita9f353c-ppa8~saucy (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL Connecting ... This happens for tv and radio and on both linux and windows. Hello Jed :-) Win32 user here, so can't offer much help with regards to your Linux(-ish) installation, but since your issue is not OS specific, I would hazard a guess that something's gone awry recently in your network settings... Have you changed anything in your modem/router? Are you behind a hardware/software firewall? Maybe using a VPN? Internet Security software mis-configured? Is your Windows GiP also the latest, i.e. 2.92? If yes, please try a download (e.g. radio) command asking for a flashmode and add the --verbose (or even debug) switch; then focus (and maybe post) on that part of the log where rtmpdump attempts to connect... Default rtmpport is 1935, so it must be open in your network. Open in a browser this URL: http://www.therealtimeweb.com/index.cfm/2004/10/2/fms-port-tester If port 1935 does not pass the test, and 443/80 do, then repeat the GiP command by adding --rtmpport 443 (or 80). As far as Jon Davies' suggestion goes, in 2.92 there's a new option that allows for a more precise way of connecting to a particular CDN: --exclude-supplier In the UK, the default CDN is usually Akamai; If your issue is, as suggested, caused by the inability of rtmpdump to connect to a specific CDN (you first have to explore the rtmpports matter, then use your verbose log to identify the problematic CDN), you can add --exclude-supplier akamai and let GiP try an alternate CDN, like Limelight. I've found when downloading TV programs - don't know why it happens - that if I use --tvmode=best, which virtually always defaults to flashhd1, that my downloads will chug along at about 1.5Mbit/sec. If instead I use --tvmode=flashhd2, the downloads will run at pretty much my full connection speed of just under 15Mbit/sec. This happens on both Linux and Windows with GiP 2.92. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Large downloads slowing/stopping as they progress
I've been downloading parts of the World Snooker Championship coverage. Some of the files are quite large - four hours long and over 4Gb if downloaded as HD. I've noticed (this happens with 2.92 on both Linux and Windows) that as the downloads progress they get slower and slower, and quite a number of the downloads of 120 minutes or more eventually come to a complete halt, without any error message being displayed. If I stop the download at that point and start it again it won't resume successfully (loops continually with the message Command exit code 1 (raw code = 256) and I have to start it again from the beginning. I've found the best way to download these large files is to run the downloads in a Linux VM and periodically reboot the VM when the download slows but while it is still progressing. When the VM has finished rebooting I restart the download and it successfully resumes at normal speed from the point at which it was when the VM was rebooted. I don't experience these problems with the usual 30min / 1hr programs that I download. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Betjeman - Won't download, can anyone explain?
Worked fine for me using: get_iplayer --pid=b03495yn --tvmode=best --versions default,audiodescribed,signed On 24/04/2015 15:48, C E Macfarlane wrote: ~ # gip --type tv --pid b03495yn -g get_iplayer v2.91, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. INFO Trying to stream pid using type tv INFO: pid found in cache Matches: 648:Let's Imagine - A Branch Line Railway with John Betjeman, BBC, Factual,Lifestyle Leisure,Travel, default INFO: 1 Matching Programmes WARNING: No programme versions found www.macfh.co.uk/CEMH.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [ANN] get_iplayer 2.92 released
On 14/03/2015 09:14, dinkypumpkin wrote: Release notes here: https://github.com/get-iplayer/get_iplayer/wiki/release292 Since the upgrade (Windows 81. x64, downloaded and ran the Windows installer for the upgrade), I'm getting two copies of each file downloaded, both the filename I would expect and one that looks like it is a temporary file that should be deleted. e.g. I just downloaded Poldark episode 2, and when the download completed I have two mp4 files in the same folder, named: Poldark_Episode_2_b05n8kfz.mp4 Poldark_Episode_2_b05n8kfz-temp-8277.mp4 The files are not quite the same size (1,052,333,131 bytes vs 1,052,339,293 bytes), but they both play fine and are both indicated as being exactly the same duration (58:23). There are no errors indicated in the cmd window where I ran get_iplayer. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Help needed with BBC Collections Archive programmes
On 06/02/2015 10:22, Vangelis forthnet wrote: On Thu Feb 5 17:29:53 GMT 2015, M Clark wrote: Whilst pid=b048s4tn doesn't need this switch, using it gives a file Plants_-__b048s4tn_default.m4a whilst not using it returns Plants_From_Roots_to_Riches_-_1._A_Rose_by_Any_Other_Name_b048s4tn_default.m4a. The version of get_iplayer used is the commit of 3rd Jan. Hello again! As I keep some older versions of the main script in my installation folder (for experimentation debugging purposes), I conducted some further experiments with your sample pid=b048s4tn. With my oldest version get_iplayer v2.90-45-g16b0c40 of 2014-12-06 (http://git.infradead.org/get_iplayer.git/blob_plain/16b0c40f1ca65c0ccfec23e72928d17f8b5ec862:/get_iplayer), I get: A. NO --playlist-metadata Plants_From_Roots_to_Riches_-_1._A_Rose_by_Any_Other_Name_b048s4tn_default B. --playlist-metadata Plants_-_From_Roots_to_Riches_A_Rose_by_Any_Other_Name_b048s4tn_default So, already a small difference between the auto-generated file names, but no info missing. With my slightly newer copy get_iplayer v2.90-58-gd1caff0 of 2014-12-12 (http://git.infradead.org/get_iplayer.git/blob_plain/d1caff0e19139eba4f4e6cac826a6ebf7061e295:/get_iplayer), I get: A. NO --playlist-metadata Plants_From_Roots_to_Riches_-_1._A_Rose_by_Any_Other_Name_b048s4tn_default B. --playlist-metadata Plants_-__b048s4tn_default Tag v2.91 exhibits the same behaviour and this, as you state, is matched by the Jan 3rd dev version of the script. I would look in the commits between 16b0c40 d1caff0 to find the change of code that introduced this bug... I see something similar when downloading via PID with v2.91. I downloaded several episodes of Smiley's People via PID, and the downloaded files were all named Smileys_People_Smileys_People_pid. I had to go back and look at the PIDs on the iPlayer web site to get the Episodes sorted in order. The only command line parameters used were --pid and --output to specify the download folder. Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Multiple pids - another way, in some cases
That method doesn't seem to work for me - for TV, anyway. For example, BBC4 have a number of blues programs available in their archive (see http://www.bbc.co.uk/iplayer/group/p01m79bn). If I try to use the p01m79bn pid, I get the following: get_iplayer --pid=p01m79bn --pid-recursive --output D:\Users\Nick\Videos --tvmode=best get_iplayer v2.87, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. WARNING: rdf URL contained no data WARNING: PID URL contained no RDF data. Trying to record PID directly. INFO: Trying pid: p01m79bn using type: tv INFO: Trying to stream pid using type tv INFO: pid not found in tv cache Matches: INFO: 1 Matching Programmes ERROR: Failed to get version pid metadata from iplayer site Nick On 02/11/2014 02:09, roadcone wrote: For those new to using the command line or terminal and wanting to secure all programs from a series, there may be an alternative to harvesting and entering multiple pids. In some cases the program series may have a series web page. For example, Germany: Memories of a Nation has this one: http://www.bbc.co.uk/programmes/b04dwbwz/broadcasts/2014/11 The pid from that url is b04dwbwz but that will not --get you anything apart from a list of pids for the individual programs. Add: --pid-recursive to your command and get_iplayer will try to get each individual program. It will fail where the program is too old, not yet broadcast, already in your download history or some other BBC problem and as a consequence, you will get loads of error messages but it will get what is available that you do not already have. This is not a panacea but may help in some cases though do check the downloads are what you expect as you may need to go hunt the errant episode manually. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: More (or less) Tommies
Go to the page on the iPlayer web site for the episode. In the address bar of the web browser you will see the URL - eg for the 14th October episode, the URL is http://www.bbc.co.uk/programmes/b03thc2q. The string of eight characters at the end is what you need to download via pid. To get this program, use: get_iplayer.cmd --pid=b03thc2q --type=radio On 25/10/2014 10:25, Doug Faunt N6TQS +1-510-717-1197 wrote: Err, I don't understand this- tiny brain, using Windows 8 Please lead me by the hand. thanks, doug On 15-Oct-14 14:53, dinkypumpkin wrote: Both episodes of Tommies are available vir --pid. It took a couple of days for last week's episode to appear in the cache, so I guess the same will apply to yesterday's. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Download showing negative cts, previous timestamps might be wrong
I just downloaded the most recent episode of New Tricks in HD (series 11 episode 8), and when I had a look at the cmd window after the download finished, it was full of the three messages like those copied below, repeated over and over with a different frame number for each set of three messages, though the download eventually seemed to complete successfully. Although the episode is the same time length as previous episodes, the downloaded file is about 50% larger (about 1.5Gb vs 1Gb for older episodes). I opened the downloaded MP4 into WMP and checked that it was playable at several random points, including the titles at the end, and the download seems to play ok. I'm running the most recent version of get_iplayer on Windows. Any suggestions on what has happened here? [flv @ 02602c60] negative cts, previous timestamps might be wrong Last message repeated 612 times frame=12336 fps=1644 q=-1.0 size= 214945kB time=00:08:13.44 bitrate=3568.5kbits Nick Payne ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Is this still a BBC problem I'm seeing?
Just tried to download episode 4 of The Honourable Woman after performing a refresh, and I get the following error: nick@nick-lm17 ~ $ get_iplayer --get 1056 --output ~/Videos/iplayer/ --tvmode=best get_iplayer 2.86-2-g969bd34-ppa17, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. Matches: 1056:The Honourable Woman - 4. The Ribbon Cutter, BBC Two, Audio Described,Drama,Guidance,Highlights,Popular,TV,Thriller, default,audiodescribed, INFO: 1 Matching Programmes WARNING: No programmes are available for this pid with version(s): default (available versions: default,audiodescribed,) ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: HandleInvoke, Sanity failed. no string method in invoke packet
On 11/07/14 19:13, SquarePenguin wrote: Nick Payne wrote: but if I run iotop in another terminal, I can see that rtmpdump is running and is still downloading something...but not to the specified output folder. Are you certain it's actually downloading and not just simply still running? I don't have a linux install so see exactly how this works but are you certain that it's not only 'active' but also actively downloading content? Yes, it's still downloading content. If I run system monitor and look at resource use, it shows the network card receiving a fairly constant ~200Kb/s, and as soon as I Ctrl+C the process in terminal this network activity stops, as does the rtmpdump process in iotop. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
HandleInvoke, Sanity failed. no string method in invoke packet
This error seems to be happening when I use --tvmode=best and get_iplayer tries to download the program using flashhd1 - see terminal output below. I tried the download several times and this error happened each time, but at a different point in the file each time. When the error comes up, I can leave the terminal running for many minutes, but no further terminal output appears, and the bytes and percentage downloaded doesn't change. If I look at the folder ~/Videos/iplayer/ while this is happening, I can see that the size of the downloaded file is not incrementing at all, but if I run iotop in another terminal, I can see that rtmpdump is running and is still downloading something...but not to the specified output folder. If I press Ctrl+C to terminate the download and force flashhd2 download by changing --tvmode=best to --tvmode=flashhd2, then the download proceeds normally and completes successfully without any errors indicated. Running on Linux Mint 17 amd64. nick@nick-lm17 ~ $ get_iplayer --get 1051 --output ~/Videos/iplayer/ --tvmode=best get_iplayer 2.86-2-g969bd34-ppa17, Copyright (C) 2008-2010 Phil Lewis This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty. This is free software, and you are welcome to redistribute it under certain conditions; use --conditions for details. Matches: 1051:Storyville - 2013-2014: 30. Velorama, BBC Four, Cycling,Sport,TV, default, INFO: 1 Matching Programmes INFO: Checking existence of default version INFO: flashhd1,flashhd2,flashvhigh1,flashvhigh2,flashhigh1,flashhigh2,flashstd1,flashstd2,flashlow1,flashlow2 modes will be tried for version default INFO: Trying flashhd1 mode to record tv: Storyville - 2013-2014: 30. Velorama INFO: File name prefix = Storyville_-_2013-2014_30._Velorama_b048wqcc_default RTMPDump v2.4-n87-gita9f353c-ppa8~saucy (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL Connecting ... INFO: Connected... Starting download at: 0.000 kB INFO: Metadata: INFO: duration 3518.24 INFO: moovPosition 36.00 INFO: width 1280.00 INFO: height720.00 INFO: videocodecid avc1 INFO: audiocodecid mp4a INFO: avcprofile100.00 INFO: avclevel 41.00 INFO: aacaot2.00 INFO: videoframerate25.00 INFO: audiosamplerate 48000.00 INFO: audiochannels 2.00 INFO: trackinfo: INFO: length87956000.00 INFO: timescale 25000.00 INFO: language und INFO: sampledescription: INFO: sampletypeavc1 INFO: length168875008.00 INFO: timescale 48000.00 INFO: language und INFO: sampledescription: INFO: sampletypemp4a 460.312 kB / 5.44 sec (0.1%) WARNING: HandleInvoke, Sanity failed. no string method in invoke packet ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Large filesizes (re-formatted)
I have no problem on Linux with get_iplayer downloading files over 4Gb. One of the Wimbledon tennis matches I downloaded a couple of nights ago in HD is a 5.1Gb file. The version of rtmpdump is whatever is in the ppa I installed from: running rtmpdump -version shows: RTMPDump v2.4-n87-gita9f353c-ppa8~saucy Nick On 04/07/14 09:11, Vangelis forthnet wrote: Apologies, my mail client is acting weird :-( On Thu Jul 3 19:43:25 BST 2014, TQ wrote: I seem to recall a thread a while ago regarding large files ( 4GB or so) which truncate at the fat32 limit due to, ISTR, rtmpdump. I've trawled back through my archives and can't find any reference. Does anybody remember it, You can find this thread in the Feb 2014 list archives: http://lists.infradead.org/pipermail/get_iplayer/2014-February/thread.html#start OP was Sam P: http://lists.infradead.org/pipermail/get_iplayer/2014-February/005425.html and the issue was observed on the flashhd quality variant of the Winter Olympics 2014 Opening Ceremony... what was the solution Many thanks to dinkypumpkin, who provided a special mod of rtmpdump to bypass the RTMP 4GB limit (which has nothing to do with the file system of your hard disk): https://bitbucket.org/dinkypumpkin/rtmpdump/branch/4GB If you are on Windows, you can grab the x86 binary here (again,c/o dinkypumpkin): https://bitbucket.org/dinkypumpkin/rtmpdump/downloads You can safely replace your current copy of rtmpdump.exe (or choose to back it up first) with this moded one - just rename it from rtmpdump-4GB.exe to simply rtmpdump.exe. Or you can point get_iplayer to this new binary by editing your system options file or via the --rtmpdump path option... If not on Windows, I'm sure others can step in... Regards, Vangelis. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Download speed difference between flashhd1 and flashhd2
I notice a really marked difference in download speed between these two modes. I'm running get_iplayer 2.86 from the ppa jon-hedgerows/get-iplayer on Linux Mint 17, and I've noticed that if I specify --tvmode=best, then the download always first tries flashhd1 mode, and that chugs along at a few hundred kilobit/sec. However, if I force flashhd2 mode with --tvmode=flashhd2, the download runs many times faster - up to 12-14 megabit/sec (the max line speed I get on a test to my ISP is around 16 megabit). Why this vast difference in the download speed of the two modes? Nick ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
