RE: 2.95 & --refresh-future
> -Original Message- > From: get_iplayer [mailto:get_iplayer-boun...@lists.infradead.org] On > Behalf Of Vangelis forthnet > Sent: 19 July 2016 03:39 > To: get_iplayer@lists.infradead.org > Subject: Re: 2.95 & --refresh-future > > On Sun Jul 17 07:59:35 BST 2016, Simon Morgan wrote: > > > That's right; the 2.95 release notes informs us that this option is > > ignored and no longer works. > > ...Not quite! If you are referring to line: > > > The --refresh-future option is ignored, so searching of future > > schedules will not work. > > present in the 2.95 Release Notes, then a more careful reading will > reveal that this sentence is under "chapter" 6 of the Notes: > > > 6. Fallback indexing: For when the BBC plays with matches > > so it is only true when the --ybbcy switch has been added to options (I > hope we never have to resort to that!). ... > Cheers, > Vangelis. > Thanks for putting me straight on this one. I confess that I only ready the release notes not the full manual. Must try harder! Simon Morgan ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: get_iplayer-2.95 & windows 10
On Mon Jul 18 15:19:13 BST 2016, Simon Morgan wrote: I also get this error msg (...cannot fork at line 331...) using the web PVR. However GetiPlayer usually runs for 2 or 3 days before this occurs. In v2.94the msg referenced line 281. It would be nice if this error could be solved as it means I cannot leave GiP running unattended for too long. ... Unfortunately, this is a known limitation on Windows OSes not likely to be fixed : -( For reference, here are links to previous Support Forum threads: (from 2013) https://squarepenguin.co.uk/forums/thread-20-post-20.html (from 2015) https://squarepenguin.co.uk/forums/thread-429-post-429.html https://squarepenguin.co.uk/forums/thread-438.html https://squarepenguin.co.uk/forums/thread-576-post-3142.html Regards ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: 2.95 & --refresh-future
On Sun Jul 17 07:59:35 BST 2016, Simon Morgan wrote: That's right; the 2.95 release notes informs us that this option is ignored and no longer works. ...Not quite! If you are referring to line: The --refresh-future option is ignored, so searching of future schedules will not work. present in the 2.95 Release Notes, then a more careful reading will reveal that this sentence is under "chapter" 6 of the Notes: 6. Fallback indexing: For when the BBC plays with matches so it is only true when the --ybbcy switch has been added to options (I hope we never have to resort to that!). In fact, the issue first reported by James Daley and then confirmed by terry is due to a bug; the code maintainer has become aware since and has created issue #267 in the GitHub tracker, later closed by commit git-992d670 in the develop branch: https://github.com/get-iplayer/get_iplayer/commit/992d670 I am not a user of the "--refresh-future" feature, but interested parties are welcome to check the fix in the latest 2.96-dev edition of the main script: https://raw.github.com/get-iplayer/get_iplayer/develop/get_iplayer Cheers, Vangelis. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: get_iplayer downloads .ts files
On Mon Jul 18 17:00:43 BST 2016, Jon Davies wrote: By default, get-iplayer has produced .mp4 files for a long time, and it still does. So there's something in the way you've configured it that's producing .ts files. most likely you've asked it to produce raw files. Hi, Jon I do not want to step in your shoes in the slightest, you are doing an absolutely sterling job with GiP with your PPA (BTW thanks for hosting win32 AP binaries!), but may I also suggest that the OP produces a verbose log of a video download which should help significantly in troubleshooting, e.g. get_iplayer --pid=p041c2rv -v > verbose_log.txt 2>&1 (test video of only 5min in duration) GiP 2.95 now by default records in hlshd tvmode, video file is indeed recorded first as .ts (MPEG-TS container, as being the result of HLS dump), but is subsequently remuxed to the MP4 container (.mp4 file) via FFmpeg/avconv so it can be tagged by AP. Maybe the OP has something gone awry with his FFmeg/avconv (depending on OS/distro) configuration that is hindering the final remux to MP4, thus leaving him with un-remuxed .ts files. As I am clueless in non-Windows, you should be able to assist him further in possibly fixing it... Best regards, Vangelis. ___ 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
> Sent: Tuesday, July 19, 2016 at 12:31 AM > From: "Nick Payne" > > WARNING: Segment not found (13) That is due to a server error. It means that piece of the programme is missing or unavailable on the server. It isn't related to your network connectivity or anything in GiP. The fact that you see that message means the server has delivered a complete response, albeit a 404 "not found" response. I've seen these problems fixed after a while, but not always. ___ 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
On Tue Jul 19 00:31:07 BST 2016, Nick Payne wrote: Well it seems the problem isn't due to simultaneous downloads, as it happened again today with only a single download running. it was only a single warning message, the rest of the program downloaded without any more warnings: Good evening (/morning?), Nick As you are very well aware, GiP 2.95 (there does not exist a GiP 2.95.1 as per your mail title, 2.95.1 is used solely for the latest version of the Windows installer) has changed the default tv mode from flash (RTMP stream) to hlshd (AppleHLS); additionally, in GiP 2.95 hlshd is fetched by default via a native Perl downloader rather than FFmpeg (which was the case in GiP 2.94). Due to the very nature of AppleHLS delivery method, the recording is realised by downloading individual file segments over HTTP which are then concatenated back to end file. This downloading scheme demands an absolutely robust internet connection - if the connection is fickle and latency is introduced, then one or more individual segments are missed (possibly because the CDN server has progressed to serving the next segment in the playlist; but don't take my word for granted, I'm not an expert in file delivery :-). Another person has also reported failures on parrallel GiP recordings with v2.95: https://squarepenguin.co.uk/forums/thread-956-post-4293.html As I've told you already, it boils down to a robust connection; the coder stated in his reply there: All I can tell you is that I have no problem running simultaneous downloads and utilising all my available bandwidth, but YMMV. So if your connection is iffy, please refrain from parallel downloads or revert to flash tvmodes by asking specifically for --tvmode=flashhd in your commands (flash modes and support for the RTMP streams have been deprecated in 2.95; this means THEY DO STILL WORK, BUT ARE SCHEDULED FOR REMOVAL, probably in the next release... == IMPORTANT EDIT == Having visited the Support Forums, it dawned on me that you are the same person who made the following post there: https://squarepenguin.co.uk/forums/thread-836.html That post describes a similar failure: looks from the messages as though there might have been an interruption to my Internet connection (snip) ERROR: Failed to download segment (144) I am not without sin, so unable to cast the first stone, but the mods at the forum checked your IP address and found it to be non-UK; so your thread was hastily locked, as per forum guidelines. Indeed, by searching your e-mail address used on this list, it leads to a South Australian ISP (internode). You are physically located half a globe away from the CDNs serving the content you are after, which is meant for consumption within the UK only (not the Commonwealth!) anyway, plus whatever method you are employing to evade geo-blocking adds to the flakiness of your connection. So, please STOP MAKING SIMILAR POSTS to this list, the answer is HLS tvmodes will be unreliable for you due to your location; not a fault of GiP's. As said, I won't pass any judgement, but the owner of this list has expressly stated in the past his view that people asking to circumvent the beeb's geo-filter should not be helped! While I technically did not do that - you seem to have found the way on your own - my hands are sort of tied, so out of fairness to legitimate GiP users I won't be offering any more support in future to your queries if they are BBC TV related ;-( Greetings Down-Under, Vangelis. ___ 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
From: Nick Payne Sent: Tuesday, July 19, 2016 00:31 WARNING: Segment not found (13) WARNING: There may be a gap near 120 secs in programme I have the same error. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: hlshd download speeds
On Mon Jul 18 16:02:27 BST 2016, RS wrote: Both drives are formatted as FAT32. This is necessary for compatibility with my satellite receiver, but it is also necessary for safe hot removal. Hello, Richard :-) How are you managing > 4GB video files with the above file system on those drives? In hlshd tvmode, file size of video files are ca. 1GB/h, so you're not very likely to hit that limit with ordinary programmes, but the likelihood exists for extended broadcasts of some events, e,g, sports (the Olympics come into mind...). And if you want to check the hvf modes implemented in GiP 2.95, do note that hvfhd (720p/50FPS/5Mbits) tvmode comes in at ~ 2.1 GB/h... Kind regards, Vangelis. ___ 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: get_iplayer downloads .ts files
> On 18 July 2016 at 12:26, John Rose wrote: > I've just installed get_iplayer v2.95-ppa25~trusty emanating from your ppa. > It downloads TV programmes as .ts files (e.g. dad's Army and the Proms. > On 18/07/16 17:00, Jon Davies wrote: > By default, get-iplayer has produced .mp4 files for a long time, and > it still does. So there's something in the way you've configured it > that's producing .ts files. most likely you've asked it to produce > raw files. > > what's the result of this command in your configuration? > $ get_iplayer --prefs-show On 18 July 2016 at 17:10, John Rose wrote: > get_iplayer --prefs-show > > shows nothing (i.e. just returns the command prompt). ok, next question: what command are you using to download programmes? Jon ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: get_iplayer downloads .ts files
On 18 July 2016 at 12:26, John Rose wrote: in general, please either post to the get-iplayer mailing list (in cc) or post a question on the forums at www.squarepenguin.com. ... but having said that... > I've just installed get_iplayer v2.95-ppa25~trusty emanating from your ppa. > It downloads TV programmes as .ts files (e.g. dad's Army and the Proms. > These files play OK, but cannot be edited or converted to .flv or .mpg > formats either using ProjectX or using Avidemux. Please tell me what's > happening with the BBC Player and how I may edit these .ts files. By default, get-iplayer has produced .mp4 files for a long time, and it still does. So there's something in the way you've configured it that's producing .ts files. most likely you've asked it to produce raw files. what's the result of this command in your configuration? $ get_iplayer --prefs-show Jon ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: hlshd download speeds
From: RS Sent: Monday, July 18, 2016 16:02 The performance of the two drives was much more similar. The Samsung drive started at 79GByte/s. It then fell to 30GByte/s after about 500MByte and remained at that level. The Maxtor drive started at 77GByte/s and also fell to 30GByte/s after about 500MByte. Sorry that should read The performance of the two drives was much more similar. The Samsung drive started at 79MByte/s. It then fell to 30MByte/s after about 500MByte and remained at that level. The Maxtor drive started at 77MByte/s and also fell to 30MByte/s after about 500MByte. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: hlshd download speeds
From: Nick Sent: Sunday, July 17, 2016 14:19 There was a thing at some point with Windows where external drives would not have write caching enabled. Perhaps the different OS versions and/or different drives have ended up with different settings? Drive caching being off means that external drives can be unplugged with minimal chance of file corruption, but it gives a performance penalty. Thanks for the suggestion. Both devices are using the Quick removal policy, so that is not a reason for the difference in performance. The 29MByte/s and 10MByte/s write speeds were with Quick removal. Write caching is really only appropriate for devices which are only going to be unplugged when the machine is powered down. I know Microsoft says you can rely on the safely remove tool, but I don't trust it. Both drives are formatted as FAT32. This is necessary for compatibility with my satellite receiver, but it is also necessary for safe hot removal. I don't know about Windows 7 and 10, but in XP and Vista Microsoft assumed that all NTFS devices were permanently installed, so that data could be temporarily shared between drives. The only safe way to remove a NTFS drive is to shut down. I once lost 5GByte of data from a flash drive I had formatted as NTFS. A new bug seems to have been introduced in Windows 10. The first time a removable drive is use the safe removal tool keeps insisting that it is still in use. There is no problem on subsequent uses. It may be that the driver installer does not release it. After writing the above I thought I ought at least to try write caching to see what effect it had. The performance of the two drives was much more similar. The Samsung drive started at 79GByte/s. It then fell to 30GByte/s after about 500MByte and remained at that level. The Maxtor drive started at 77GByte/s and also fell to 30GByte/s after about 500MByte. In other words drive caching is only of benefit for transfers up to 500MByte, and for a sound drive the performance for larger transfers is similar to that without drive caching. In both cases there were no dips in speed between files as there had been without drive caching. With drive caching the Maxtor drive was able to download HLSHD at full speed. I remain of the view that the Maxtor drive is faulty. There should not be such a large deterioration in performance without drive caching. The drive did not work at all with the supplied cable when it arrived. It did work with a cable from another drive. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: get_iplayer-2.95 & windows 10
> -Original Message- > From: get_iplayer [mailto:get_iplayer-boun...@lists.infradead.org] On > Behalf Of artisticforge . > Sent: 18 July 2016 13:10 > To: RS > Cc: get_iplayer > Subject: Re: get_iplayer-2.95 & windows 10 > > hello > > I found one problem with it. get_iplayer.cgi is dying at line 331. > "Cannot fork" is the error message. > > Run PVR completes then dies with that error. > I will have to look at it more later. > Dealing with life at the moment. > I also get this error msg (...cannot fork at line 331...) using the web PVR. However GetiPlayer usually runs for 2 or 3 days before this occurs. In v2.94 the msg referenced line 281. It would be nice if this error could be solved as it means I cannot leave GiP running unattended for too long. Other than this, GiP is pretty damn good and very useful in my opinion. I am using Windows Home Server 2011 and GiP v2.95 Rgds Simon Morgan ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: get_iplayer-2.95 & windows 10
hello I found one problem with it. get_iplayer.cgi is dying at line 331. "Cannot fork" is the error message. Run PVR completes then dies with that error. I will have to look at it more later. Dealing with life at the moment. On Sun, Jul 17, 2016 at 5:17 PM, RS wrote: > From: artisticforge . > Sent: Sunday, July 17, 2016 15:15 > >> My gut feeling is that Windows 10 is going to sleep/suspend mode and >> that is why get_iplayer-2.95 via the Web Manager is not running. > > > It is several years since I used the PVR and I have never used the web PVR, > so I can't help with that. By default Windows 7 and Windows 10 do sleep > after quite a short period of keyboard inactivity. I was going to say it > should be obvious if the machine is in sleep mode, but if the fan is quiet > the only indication will be that the light on the power switch or another > light is flashing. > > Go to Start Settings System Power & sleep > Under Sleep select Never from the drop down list. There are separate > settings for battery and plugged in. > > > ___ > get_iplayer mailing list > get_iplayer@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/get_iplayer -- terry l. ridder ><> ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
