Re: Syntax for grabbing all episodes of the new season of Celebrity Master Chef
On Mon, 6 Jul 2020 11:14:48 +0100, CJB wrote: > Then there are VPN services - free v.v. paid for. If the Beeb offered > such then folks would surely pay to watch or listen from overseas. Trouble is the BBC does not hold hold the rights to world wide distribution on all of their content. > Anther revenue stream it does not been to want to exploit. It has potential to be a good litte earner but managing what content was available to which parts of the world and that the consumer was really where they claimed to be would be horrendous. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT Help Please with Clicks and Volume Levels
On Tue, 31 Mar 2020 09:53:16 +0100, Jim web wrote: > But with digital LPCM transfers they should just 'pass the parcel' and > deliver at the end of the chain what got put in at the start. Assuming the clocks at each end are locked. If they aren't clicks are a common side effect as the reciever has to drop or invent a frame of data once they get too far apart. These can come in groups spaced away from each depending on how the clocks drift relative to each other and how stable (jitter) one or the other are. Don't know anything about the kit involved here either. I get the impression no interkit connections are digital so the above is a red herring. And "domestic" digital interconnects can recover the clock from the data stream. The fact the setup has recently moved and the problem started with that move would have me moving it back to where it was and seeing if the problem disappears. It could be interferrence pick up in the connection to the Bluetooth Tx, unlikely if that is at line (high, headphone) level. In the move did any parts get changed? Wall wart PSU's in particular, they are not all created equal, some maybe more prone to letting mains disturbances through than others. Does the kit move now mean the Bluetooth headphones are being used closer to any other 2.4 GHz than they were before? Turn that bit of kit off. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No Prime Minister?
On Wed, 5 Feb 2020 23:17:46 +, MacFH - C E Macfarlane wrote: >> Older stuff can, possibly a little counter-intuitively, be more >> problematic than recent material, as, at the time it was made, there >> was no expectation that the BBC would ever want repeat transmission >> rights for anything other than broadcast TV. The only other >> distribution method, at the time, would have been home video, and the >> rights to that were often negotiated separately so that those involved >> in the production could get their cut there, too. Since iPlayer is >> neither home video nor broadcast, there's nothing to cover it in the >> original contracts. > > I see, bit of a bummer, but thanks for the explanation. Certainly, it > does seem counter-intuitive and somewhat ridiculous that we can't > download such an old but popular series. I loved both Yes Minister and > Yes Prime Minister, but have none of them recorded. Both available as boxed sets on DVD... aka "home video". B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No Prime Minister?
On Wed, 5 Feb 2020 09:57:16 +, MacFH - C E Macfarlane wrote: > Thanks, but I knew that, and it seems to me rather strange that an own > BBC 30 years' old series should be subject to such a constraint, and > wondered if anyone happened to know anything more specific. Depends on the rights the BBC obtained, or could obtain or can obtain, for anything included in that episode. Incidental music, "guest" actor/actress, etc... -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Mojo error
Just had this error reported after a pvr run: (in cleanup) Can't call method "remove" on an undefined value at /usr/share/perl5/Mojo/UserAgent.pm line 82 during global destruction. No programme matches found. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [ANN] get_iplayer v3.00 released
Just want to say thank you. Downloaded the zip arcive, unpacked the script, copied to the right place on my media server Raspberry Pi and fired off my PVR script. It "just worked" and collected a couple of programmes. The only fuss was a request to remove redundant rtmdump references in my options file. Thanks again. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: BBC Licensing Expose
On Mon, 27 Feb 2017 10:43:20 +0100, Peter Corlett wrote: > Apart from those who don't have a TV Licence because they don't require > one, Haven't the rules recently changed from only needing a licence to watch "as broadcast", ie a live stream, to requiring a licence to watch "on demand" content as well. You certainly get asked if you have a licence if you try and watch anything on demand via the web. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: cute error message
On Sun, 1 Jan 2017 08:46:36 -0600, artisticforge . wrote: >> Whether it was 50fps is irrelevant, one day we'll be downloading >> 1920x1080 or hopefully 4K and then 6GB will be an average file size. > > I will be long dead before that happens. Unless you intend to pop off very shortly and "long" is > 5 years I wouldn't like to be on it. TV Production is moving to UHD, a facilities company building someting now will be UHD if they have any sense. 4k services are available online from the likes of Netflix, Amazon, BT (in the UK). > I personally think downloading 4k media files the height of stupidity. Over a V42bis connection would be a bit silly and take a while but it's not that long ago that I'd start a download at bedtime and it might have completed by the next evening over such a connection. And *that* is the problem. To shift gigabytes of data in a sensible amount of time you need a fast connection, that is a few 10's of Mbps. That sort of speed just isn't available in many places, this place included with < 5 MBps ADSL+. The new 50fps iPlayer downloads at not much quicker than realtime... > It was the humour in the error message that is refreshing. Agreed and it also gave pertinent and useful information about the error. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: So what does this really mean
On Fri, 16 Sep 2016 09:51:00 +0200, Dave Widgery wrote: > Whatever blocks the bbc and other broadcasters put there will always be a > way past the system, so why not accept this and look at ways to increase > revenue from the millions of British people who would quite happily > contribute but forced to find ways around the system if they want quality > tv. One word "rights". I wonder how much the BBC would have to spend to get worldwide rights on all their content? Assuming the worldwide rights are available in the first place. I wonder how much the BBC would have to pay in rights violations if they didn't get worldwide rights? -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [ANN] get_iplayer 2.95 released
On Sun, 3 Jul 2016 18:18:21 +0100, dinkypumpkin wrote: > Release notes: > > https://github.com/get-iplayer/get_iplayer/wiki/release295 Some ones been a buzy bee. Will have to try the 5 Mbps feeds to see if the improvement over 2.5 Mbps is worth (and if a RPi can keep up...). Many thanks, your work is much appreciated. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bl**dy Beeb Truncations on iPlayer
On Thu, 30 Jun 2016 20:30:51 +0100, Chris Woods wrote: > As I understand it, programmes are recorded with buffer time then may be > manually reviewed and trimmed if there's too much cruft. Several ways to interperet that. It's a good few years since I was engineering BBC radio programmes but generally speaking shows with "people gathered around a microphone" were made to time. If there is fluff in a read a stopwatch comes in handy, stopped and started as appropiate. There was little to no "buffer time". Shows with prerecorded sections would have the links written so the total duration was within ten of seconds or so of the required duration. The editing of the prerecorded sections would of course be done taking into account the required overall duration. And considerable amounts of material could be "out takes" or not... I doubt that the BBC has substanially changed it's operating procedures. The programmes producer would listen to the finished programme and sign it off as "ready for transmission". A programme tape not signed off would not be transmitted. Network would request a duration at the commissioning stage and generally speaking that duration was stuck to +/- a loose 10 seconds. If a programme ran 28'45" that is the time it would occupy, if it *had* to be adjusted it *had* to go back to the producer, the changes made and signed off again. The producer is where the buck stops, only they can make decisions about what can or can't be cut. No one in continuity has the authority to make changes. IIRC 28'30" was (is..) the requested duration of a 1/2 hour radio a show. The durations quoted are 28'30" +/- "a loose ten seconds" -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Is this necessary, and how can I get rid of it?
On Sun, 22 May 2016 08:16:28 +0100, Mark Carroll wrote: >> "Getting radio Index Feeds (this may take a few minutes)" > > get_iplayer is a Perl script. In this case you can just look for that > text within get_iplayer itself then put a # at the beginning of that > line to comment it out. This true but it'll still be downloading the radio index feeds, it just won't tell you it is. B-) get_iplayer only downloads the index feeds if it needs to, so the OP has at least one radio download requested somewhere. Find and remove them and it'll stop pulling the radio index. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: How good is HD supposed to be?
On Sat, 30 Apr 2016 22:49:01 +0100, Christopher Woods wrote: > The deinterlacing algorithm is doing no resizing - it's interpolating > between the frames and then 'printing' that to 50 progressive frames. The > resulting image will have slightly lower definition due to the bob > artifacts as it's reconstructing the frame from two sequentially > interlaced fields, but it hasn't changed resolution. Sorry, I'm still missing what is actually going on but I think I'm getting there. Is the first reference to "frames" refering to a frame constructed from the two fields designed to be shown at 25 fps? Lets call this F1. At 50 fps we need twice as many frames so an F1 and an F2. F2 doesn't exist and is created by interpolation between the current F1 and the next F1. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: What determines the resolution GiP selects for download?
On Sun, 1 May 2016 09:32:49 +1000, Nick Payne wrote: > 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? Live stuff takes time to appear in all resolutions, the lower ones tending to appear first. Waiting 24 hours and trying a --force might get you a higher resolution version. If it doesn't after 48 hours it proably never will. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: How good is HD supposed to be?
On Fri, 29 Apr 2016 20:42:06 +0100, Christopher Woods wrote: > "Upscaling" is a misnomer in this context. That implies a change of > picture resolution, ... Agreed. > ... when there's no resizing going on. Not convinced. > 25 interlaced frames per second yields 50 interlaced fields per second > (due to odd and even line scanning), But does a frame have the same number of lines as a field? It doesn't in the analog world. 625 line frame, comprising two 312.5 line fields. Frame rate 25 per second, field rate 50 per second but half the vertical resolution. If a digital field only has half the vertical resolution, which I think it must have or you can't interlace them, then to create true 50 *frames* per second each field needs to be upscaled and the missing lines interpolated from the existing ones. If you just construct a frame from the two fields you have to repeat that frame or playback at double speed... I missing something but don't know what. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: How good is HD supposed to be?
On Thu, 28 Apr 2016 07:07:33 -0500, artisticforge . wrote: >>> NB hvfhd DOES NOT OFFER HIGHER RESOLUTION (CLARITY), only doubled >>> framerate (25FPS x2), which results in smoother scenes where motion is >>> involved! >> >> How does repeating frames improve smoothness of movement? Or does this >> encode upscale each field(*) and encode that to increase the temporal >> resolution? > > It is the frames per second that provide the human eye with the > persistence of vision, the illusion of motion. I could show you 100 fps but if there where only 4 different images displayed the illusion of motion would be no smoother than 25 fps. You only get smoother movement by increasing the number of different images displayed. So if this hvfhd only repeats each frame to get a higher frame there is no increase in smoothness. How ever if they take each field, upscale it and encode as a frame that would inrease the smoothness. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: How good is HD supposed to be?
On Thu, 28 Apr 2016 03:08:38 +0300, Vangelis forthnet wrote: >> In addition a high bit-rate (8000kbps) 1920x1080, interlaced at 25fps, >> full HD encode is generated, but has not yet been made available. > > but it has not yet been released publicly... > At ca. 8Mps, those will be really huge files! 3.2 GB/hour roughly. The current 2.5 Mbps (ish) uses about 1 GB/hr. > NB hvfhd DOES NOT OFFER HIGHER RESOLUTION (CLARITY), only doubled > framerate (25FPS x2), which results in smoother scenes where motion is > involved! How does repeating frames improve smoothness of movement? Or does this encode upscale each field(*) and encode that to increase the temporal resolution? (*) If good ole 25 frames/50 fields per second has any relevance in the digital world. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GiP-2.95-develop & list archives
On Thu, 7 Apr 2016 12:26:32 +0100, Paul Phillips wrote: >> Nearly all downloads are hls with two to four times the bit rate. >> Part of that slowness is from perl doing a main part of the work. Having started on the 'net with dialup @ 2400 baud setting something going and letting it get on with it overnight or longer isn't a problem... > Is the picture quality better then and would you recommend it? That went through my mind as well. "HD" at around 2.5 Mbps isn't very good, if these HLS downloads are HD @ 5 to 10 Mbps the double realtime they'll take to download over our 4 Mbps connection will be worth it. Think about getting a bigger HD for the media player. B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: BBC Breakfast News - 3 Feb 2016
On Wed, 3 Feb 2016 15:34:47 -, Simon Morgan wrote: > Try Audacity (http://www.audacityteam.org/). I don't think it does pictures though does it? Windows has Windows Movie Maker, a basic but functional video editing tool. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: now for something completely different
On Fri, 8 Jan 2016 17:06:55 +, Colin Law wrote: > Why would the files have to be on a USB drive? Why not the SD card? Reliabilty? I've "killed" an 8 GB microSD card and an 8 GB USB stick with a Pi being used as a webcam and producing a time laspe movie. OK one full HD frame every 30 seconds and rendering those into a roughly 2 min timelapse every 6 hours is rather high use of "disc" storeage but bothe the card and stick only lasted a few months before going into "safe" mode. ie you can still read the contents but not write anything. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GIP on Western Digital MyCloud
On Sun, 15 Nov 2015 11:46:30 +, Roger Bell_West wrote: >> So more digging required! Seems like the 64k page memory build is a >> bit of a hurdle for anyone trying to do things on the MyCloud over and >> above what comes pre-installed. > > I have to admit that at this point I'd be thinking that a Raspberry Pi > or similar low-power machine would be less trouble. +1 Raspberry Pi with OSMC installed so it'll act as a pretty good media player connected to your telly. Install GiP for what GiP does, configure OSMC and GiP to use space on the My Cloud device for storage/playback. That's what I have except the storage is a USB HD connected to the Pi, also USB powered. I have used NAS space in the past, if you can mount it you can use it. B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: How do I select an episode please?
On Wed, 11 Nov 2015 23:14:08 +, Budge wrote: > I find my old pvr entry Afternoon_on_3_-_Thursday_Opera_Matinee no > longer works. > > The programme is still there and now shows in the cache as :- > > 10139: Afternoon on 3: Thursday Opera Matinee - Massenet - Werther, BBC > Radio 3. The cache entry doesn't have a hypen. That may or may not be relevant as I know some punctuation is ignored by GiP. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GiP is ignoring lots of radio progs
On Sat, 7 Nov 2015 20:14:06 +, CJB wrote: > To download Hancock's Half Hour I have the search term Name = > 'hancock' in my Windows PVM list including Type=Radio > > Yet for weeks GiP has not been downloading anything. > > I have now checked at the iPlayer site and there are lots of Hancock > episodes to download. Don't often download radio but had fun a few days ago for a programme I wanted. It was listed in the radio cache and the (command line) PVR would find it but the fail to download as there was no match for "default". GiP suggested trying "modes flashaaclow,flashaacstd,hlsaacstd" and that cured it. my ~/.get_iplayer/options file: fileprefix .. modes best subdirformat versionlist default,signed output /media/seagate/TV_Progs outputradio /media/seagate/Radio subdir 1 metadata xbmc -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Format of BBC Radio 4 .m4a files
On Wed, 09 Sep 2015 11:42:19 +0100, David Cantrell wrote: >> get_iplayer could do with a FLAC/"Apple Lossless" output for maximum >> quality. > > There's not much point, because only lossy recordings are available on > iPlayer. As that stands correct but chaining lossy codecs is not a Good Idea. Each one will throw away different bits... more of problem at lower bit rates as more has to be thrown away to get the bit rate down. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: iplayer change or...
On Wed, 09 Sep 2015 10:03:14 +0100, Jim Lesurf wrote: > My impression is that the apparent error reports are so random that they > are just surface signs of a more basic problem. My ignorant guess is that > packets are arriving too fast in too irregular an order, and something > somewhere is being confused because it can't keep up with sorting out the > flow into proper order. > FWIW I have a nominally 70meg connection and when all is well, at about > 7-8 am I have no trouble fetching HDTV items at about x10 'real time' - at > least using the 'x' option. I'm also using a fairly fast machine with a > wired network. Normally I can easily do things like fetch one program > whilst watching another and the CPU use still seems low. If daytime downloading works but wee small hours doesn't, in a reasonably consistent manner, it does tend to point at something not keeping up with the flatout rate the BBC can throw stuff at you in the wee small hours. GiP is the only thing that any of this household uses that can fill the pipe and hold it full for how ever long a download takes. We only have a tiny pipe though, < 5 Mbps. I don't think the streams use a link layer error correcting transport protocol, so if a packet gets broken/dropped in transit it's gone forever. "Transit" includes any (hardware) buffers in the NIC... Makes sure you have the latest drivers for your NIC, see if there are any tweaks regarding buffers in the driver. Is it an "on board" NIC or a seperate card, on board stuff is normally "what they can get away with" but all the same 70 Mbps sustained shouldn't be a problem. One assumes you are saving the stream to the machines HD not a NAS over the same ethernet connection? -- Cheers Dave. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Clangers missing
On Tue, 11 Aug 2015 09:31:18 +0100, Colin Law wrote:
>>> http://www.bbc.co.uk/cbeebies/shows/clangers there are 26 available
>>> for download.
>>
>> Are those 26 episodes the 26 of Series 1 and 2 ('69/70 & '72/72) or the
>> first 26 of Series 3 (2015)?
>
> We will have to ask Ivor Williams that.
Eh? Oliver Postgate was the creator/writer/voice. My google foo is failing
to turn up anything for Ivor Williams but I'm pretty damn sure he had
something to do with childrens telly back in the 60/70's ish.
The 2015 series is new and voiced by Michael Palin.
> By the way everyone please reply to the list, people have a habit of
> sending mail to me directly rather than the list. Thanks.
Apologies, it is the way the list is configured. Don't go there...
--
Cheers
Dave.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: hlsvhigh4 error
On Mon, 13 Jul 2015 14:38:55 +0100, Jon Davies wrote: > Personally I stick with --mode=best all the time, which means I can > forget about which mode is used for download - I just end up with the > best available copy of each programme. Best avaliable at the time of download. Occasionaly the best available at time of download will have a better version appear a while later. Which of course is ignored as the programme is in the download history. I don't think there is a setting to automatically "upgrade" already downloaded content if a better version appears. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Paywall for iPlayer?
On Tue, 7 Jul 2015 15:52:02 +0100, Graham Temple \(gmail\) wrote: > TV should not be funded by a licence fee, but by direct grant from the > government, funded by general taxation. Good grief we then effectively have a state controlled broadcaster. Is that what you really want? The licence may be flawed but it keeps the government at arms length from the BBC. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Paywall for iPlayer?
On Tue, 07 Jul 2015 13:06:38 +0100, michael norman wrote: >> Yes but what about people who never ever watch TV at all. There are >> some, believe it or not - my parents for instance. They have computers >> and internet, but why should they pay a charge for something they will >> never use, That is a problem but sort of worked around if you call it a "Media Licence" that is it gives the household the ability to legally view any media from any source. Be that Netflix, 4OD, YouTube or, at the extreme, the graphics/still images that make up a web page. >> just because they have some equipment (whose primary purpose is not for >> accessing TV!) which theoretically could access on demand content. It's not that long ago that the possession of "receiving apparatus" was enough to trigger the requirement to hold a TV Licence. >> How will you differentiate between those who don't and those who say they >> don't? Just get the ISPs to report those customers that access "media" sites? Or just extend the current regulations relating to copyright infringement. > There are many people mostly I guess a bit younger than your parents who > don't watch live tv or even want to do so. What do they watch ? Netflix > Amazon tv (to give two examples amongst many) both of which they have to > pay for But at least that is their choice. I don't watch commercial TV stations but I still pay for them and the shareholder dividends etc, even those that don't have any ability to watch any TV still pay. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Re: Paywall for iPlayer?
On Mon, 06 Jul 2015 20:29:44 +, batguano999 wrote: >> "You have broadband and a computer / 'smart' TV. Egro, you are >> equipped to access iplayer, thus require a license." > > Hmmm > That's a computer license then. > :-) Too restrictive a description, unless you want to keep the lawyers fat arguing about the semantics of the word "computer". The Dutch have a "Media Licence". TBH I very happy that the licence will now apply to "on demand" content. Without that the BBC's income was set on a, possibly quite rapid, down ward direction as more and more people either cotton on or genuinely, never, ever, watch TV as it is being broadcast. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No categories in tv.cache file
On Sun, 28 Jun 2015 14:17:45 +0100, SquarePenguin wrote: > I keep meaning to sort that out, but the spec says "self-signed > certificate that specifies the root certificate authority MAY be omitted > from the chain", so it's been a low priority :-) > > SNI is essential for my setup as more than one SSL site is served from > the same IP. > > Sorry for the trouble! No worries. Running such an ancient setup I'm used to such niggles, which considering the OS is 15 years old and the browser 10 are surprisingly few. The advent HTML5 has improved things as javascript gets dropped. OK the rendering is generally a single column of *all* the content but at least you can see it and links work! As far as I'm concerned this certificate niggle can stay on a back burner. I just have to be less lazy and wander across to a window box. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No categories in tv.cache file
On Sun, 28 Jun 2015 03:25:04 +0300, Vangelis forthnet wrote: > tellyaddict has posted the right answer; to quote from the 2.93-2.94 > Release Notes > (https://github.com/get-iplayer/get_iplayer/wiki/release293) Thank you for the github link. My browser doesn't like the certificate that https://squarepenguin.co.uk presents it thinks it is "invalid or corrupted error code -8182", squarepenguin is not unique in this but it's not very common. My browser, Mozilla 1.7.12 running under OS/2 Warp 3 with Warp 4's TCP/IP stack, so not exactly "modern" but it works for the vast majority of sites I visit, it's only horrible javascript ridden ones that it has serious trouble rendering. I simply hadn't received the tuit to get the URL across to a window box and read it, my bad. > But it is only after you've pointed GiP to a specific pid that this > category metadata can be retrieved, since - as already stated - it is not > present in the schedule feeds. If GiP was to populate the "category" > column in the tv.cache file, it would have to load and parse 3330+ URLs... Ouch, possible but not practical. How ever my script only looking at a limited range of categories and able to cache any category information previously grabbed it maybe practical. Thinks a bit longer probably not, the first run would have to process every programme, once tolerable, just. But subsequent runs would have to process every new programme, that's still going to be well over a hundred per day since the script was last run. (wild guesstimate - 6 channels, 24 new programmes/day/channel average). Lets hope that the BBC open up Nitro is some way, even if it means that each GiP user has to get their own key. I can see the rights holders bring a lot of pressure on the BBC to NOT open it up. But if each user has to have their own key it means that individual use of GiP can be tracked which may keep the rights holders off the BBCs back. Weatherunderground revoked the key used by OSMC/Kodi to access their API but that can be worked around by getting your own key direct from Weatherunderground and tweaking OSMC's configuration. Thanks for the pointer and your patience. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No categories in tv.cache file
On Fri, 12 Jun 2015 00:21:53 +0200, tellyaddict wrote: >> Just noticed that the categories field in the tv.cache file is empty for >> all entries. Is this intentional, a by product of the BBC's changes or >> just accidentaly dropped on the floor? > > Unfortunately category's are now gone. This is due to the loss of the ION > feeds we were using. The schedule feeds that GiP now uses doesn't include > this information. Stolen from the "Art of Germany" first posting: > andrew@andrewhome:~$ get_iplayer --PID b00wlrzx --tvmode=best --force > --info > get_iplayer 2.94-ppa23, Copyright (C) 2008-2010 Phil Lewis > INFO: Episode-only pid detected > INFO: Trying pid: b00wlrzx using type: tv > INFO: Trying to stream pid using type tv > INFO: pid not found in tv cache > Matches: > WARNING: The 'default' programme version could not be determined > WARNING: No programme versions found > WARNING: You may receive this message if you are using get_iplayer > outside the UK > INFO: No versions of this programme were selected (available versions: ) > INFO: File name prefix = > Art_of_Germany_-_3._In_the_Shadow_of_Hitler_b00wlrzx_default > > > brand: Art of Germany > categories: Factual,Otto Dix,Joseph Beuys,Hilla > Becher,Germany,George Grosz,Georg Baselitz,Arts, Culture & the > Media,Documentaries,Bauhaus,Andrew Graham-Dixon,Adolf Hitler > category: Factual > channel:BBC Four Where has that category information come from? It's not a "one off" or an old prog with legacy information, heres a new listing of a new programme: > osmc@osmc:~/.get_iplayer$ get_iplayer --PID p02n9vgl --force --info > > get_iplayer 2.94-ppa23, Copyright (C) 2008-2010 Phil Lewis > INFO: pid found in cache > Matches: > 702:Japan: Earth's Enchanted Islands - Hokkaido, BBC Two England, , > default > ^MINFO: File name prefix = s01e03.Hokkaido.p02n9vgl > > available: 2015-06-22T22:00:00+01:00 > brand: Japan: Earth's Enchanted Islands > categories: Factual,Documentaries > category: Factual > firstbcast: default: 2015-06-22T21:00:00+01:00 > firstbcast: original: 2015-06-22T21:00:00+01:00 > lastbcast: default: 2015-06-22T21:00:00+01:00 > lastbcast: original: 2015-06-22T21:00:00+01:00 The category field in the cache entry for p02n9vgl is still empty... -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: No categories in tv.cache file
On Fri, 12 Jun 2015 00:21:53 +0200, tellyaddict wrote: >> Just noticed that the categories field in the tv.cache file is empty for >> all entries. Is this intentional, a by product of the BBC's changes or >> just accidentaly dropped on the floor? > > Unfortunately category's are now gone. This is due to the loss of the ION > feeds we were using. The schedule feeds that GiP now uses doesn't include > this information. Gone due to the feeds going, OK I understand that but the BBC is still using them, at least as a form of index: http://www.bbc.co.uk/programmes/genres So the data is there, somewhere... B-) > You might want to have a read of the release notes for details of what's > now changed https://squarepenguin.co.uk/wiki/releasenotes/release293/ Ta, I'll have a read. I run GIP on a Pi and as it hadn't had a update/upgrade cycle for a while I thought I'd do that before upgrading GIP. But the update/upgrade did it for me so I had no need to wander off looking for things. B-) I also add my thanks to those already expressed by others for the rapid response to the changes and getting a new version out so quickly. Excellent work, thank you. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
No categories in tv.cache file
Hi, Just noticed that the categories field in the tv.cache file is empty for all entries. Is this intentional, a by product of the BBC's changes or just accidentaly dropped on the floor? get_iplayer 2.94-ppa23, Copyright (C) 2008-2010 Phil Lewis Bit of a pain if they have really gone. I had a useful perl script that would run through the cache looking for categories that I found interesting comapring against the download history and its own list of previously saved "seen" programmes. Gave me a nice list of programmes new to the cache that I might be interested in and that I'd not already downloaded or seen via the script. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Problems downloading Springwatch
On Sat, 04 Apr 2015 18:56:20 +0100, Alan Milewczyk wrote: > Just to comment on a point made earlier in this thread, I have contacted > the BBC on maybe a dozen occasions using the online form, possibly a > half of them relating to iPlayer issues - each contact has been > acknowledged within an hour or two with an iPlayer Support reference > number and subsequently an e-mail in reply. Where is this form? I wanted to report that the first three parts of Rise of the Continents were missing but after following three of four links to pages and another half dozen drop down options I still hadn't got to anything where I could simply say "Rise of the Continents series is missing parts 1, 2, 3." -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Problems downloading Caribbean with Simon Reeve
On Mon, 23 Mar 2015 23:19:13 -0700, Anthony Kehoe wrote: > [iTunes@Frontier get_iplayer]$ ./get_iplayer caribbean -g > [iTunes@Frontier get_iplayer]$ ./get_iplayer -v --pvr-single > Caribbean_with_Simon_Reeve Different search terms? Does the PVR one work if you use just "caribbean" or enclose the PVR search term in quotes and remove the underscores and/or use only lowercase? -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On Tue, 17 Mar 2015 09:27:25 + (GMT), Jim web wrote: >>> Maybe when you see black rectangles you should 'view source' (or >>> whatever NS calls it). Or use Firefox (on linux). >> >> Far easier to highlight the text in theblock with right click drag >> surely? > > All that does with NetSurf here is drag the entire page. Doesn't reveal > the text that is hidden by black rectangles. OK but how do you highlight something (anything) to copy it to the "clipboard". -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On Mon, 16 Mar 2015 19:56:47 +, Jeremy Nicoll - ml get_iplayer wrote: > Also, eyeballing the contents of the cache files will show that the values > there are not always consistent in format (I mean I think the BBC do not > always describe successive episodes of the same show in the same way). Agreed there doesn't seem to be a fixed format for anything. Genre can be fun, I'd have expected the data entry for that to be a froma drop down list but it appears to be free form. >> But I did find reading awkward using NetSurf because the definition of >> seems on those pages to cause it to render as black text in a back >> rectangle! So I may have missed it. I assume this is a NetSurf problem. >> (This is using the RO NetSurf.) > > Maybe when you see black rectangles you should 'view source' (or whatever > NS calls it). Or use Firefox (on linux). Far easier to highlight the text in theblock with right click drag surely? -- Cheers Dave. ___ 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 Mon, 16 Mar 2015 18:03:43 +, Jon Davies wrote: > On 14 March 2015 at 22:20, Dave Liquorice wrote: > > > Now if 2.92 could make it across to the Raspberry repository I'd be even > > happier. B-) > > > > â Unfortunately my pi is dead. Again. :-( :-( indeed, I like my Pi's. > I've got another one somewhere so will try and get something built in the > next couple of days. Don't panic about it, how much has changed? I only use the GiP command line via SSH, not the web PVR etc. I get the impression that all I need to update is the get_iplayer perl script rather than any of the supporting programs/scripts. AFAIK the perl is portable, I might wander off and grab the perl from github and manually put it in the right place. Using apt-get etc is just lazy really. B-) -- Cheers Dave. ___ 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 Sat, 14 Mar 2015 15:05:32 -, Don Grunbaum wrote: > As always, Grateful thanks for your continued support for GiP. Hear hear, reading through the Release Notes some one has been a very busy bee. Thank you. Now if 2.92 could make it across to the Raspberry repository I'd be even happier. B-) "sudo apt-get update" shows: > Ign http://packages.hedgerows.org.uk wheezy/ InRelease > Hit http://packages.hedgerows.org.uk wheezy/ Release.gpg > Hit http://packages.hedgerows.org.uk wheezy/ Release > Hit http://packages.hedgerows.org.uk wheezy/ Sources > Hit http://packages.hedgerows.org.uk wheezy/ Packages > Ign http://packages.hedgerows.org.uk wheezy/ Translation-en "sudo apt-get upgrade get-iplayer" says: > Calculating upgrade... get-iplayer is already the newest version. "sudo apt-get install get-iplayer" says: > get-iplayer is already the newest version. My get_iplayer is: "get_iplayer 2.91-ppa21, Copyright (C) 2008-2010 Phil Lewis" -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Episode numbers missing
On Sun, 08 Mar 2015 16:13:20 +0800, Alan Milewczyk wrote: > Running v2.91 on Win 7 x64. Not sure if it's something I've done but > I've noticed that in the last few weeks where a TV episode used to have > an episode number and name in the title field, now just the name > appears. All TV series or just some? Filename on disc or that presented by a front end? I use "fileprefix .." in my options file and most of the time it works but the BBC is inconsistent in where it places series/episode numbers. Of the series I routinely collect Horizon is the worst. What series/season info there is is in GIP's name field, episode info might be totally abscent. And what info is provided doesn't match that used by thetvdb.com, the latter is fairly consistent in it's specials/series/episode numbering. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: unable to get specific pid
On Wed, 25 Feb 2015 15:52:37 +, John Adams wrote: > INFO: 1 Matching Programmes > WARNING: No programme versions found Ditto with get_iplayer 2.91-ppa21, on a OSMC/Kodi Pi. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Post-processing
On Thu, 8 Jan 2015 16:55:49 +, Jon Davies wrote: > On 8 January 2015 at 15:29, Al Feersum wrote: >> The generic XML metadata contains a lot more information than the xbmc >> .nfo files generated with GiP > > I've never investigated increasing the amount of data in the nfo files > that xbmc generates, but that could probably be done fairly > straightforwardly if the data exists in get-iplayer anyway. The > question is what would be useful? and how should it appear in the .nfo > file? Just got around to looking at what is in the GiP generated .nfo and what XBMC/Kodi can handle. Lots of things... sorry. No initial "" header line, not that I've noticed Kodi complaining. For "Episodes" ie those programmes that are part of a series and use the block. Currently has both Series and Episode names. eg: Map Man: Series 2 - 7. Mrs P's A-Z This is rather long for display in most places in Kodi, just the episode name is required: Mrs P's A-Z. Best not to set at all rather than to "10.00", IMHO. and I think can be set the same and to the channel the programme was broadcast on ie "BBC Four". Set to most recent broadcast date. Set to first broadcast date. Set to the year of first broadcast. If those dates are available ... B-) http://kodi.wiki/view/NFO_files is a reasonable place to start looking, I'll admit to struggling the Kodi's insistance of "classifying" everything, very limiting IMHO. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Upgrading to 2.91 breaks windows installation
On Mon, 16 Feb 2015 08:54:09 -, Charlie Heard wrote: > Just bumping this, as it's still broken. How can I force get_iplayer or > the PVR to download to the correct directory automatically without having > to manually use the --output option? Have you tried putting the relevant line(s) in the "options" file? output outputradio I don't use windows so donno if that will help at all with the permissions problem or where that file is stored on a windows system... There is away to set options from the get_iplayer command line, have a dig through the docs. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Pick up from Download Completed?
On Fri, 6 Feb 2015 02:04:28 +, Jeremy Nicoll - ml get_iplayer wrote: >> I run get_iplayer on a Raspberry Pi using a NAS as the download location >> and also processing the files there via SMB. > > Could you download to a disk attached directly to the RPi and then move > complete downloaded/converted files to the NAS afterwards? That's and idea, use a USB stick, be quicker that's for sure. Well that's wasted a day... But I know a lot more about how get_iplayer works. B-) Worked out how to turn off "file exists" detection, found the turned off the call to rtmpdump, commented that out and set the return code, avconv ran but produced garbage. 1 hour prog starting at >1GB in a few tens of MB, I think not... NAS must have not saved that file properly, downloaded same prog to NAS again, avconv still produce grabage, downloaded again but to USB stick plugged into Pi, all works as normal. Ran unmodified get_player against one of the other downloads, no "file exists" exit, rtmpdump detects the existing file decides it's all there quits (as I expected it to do) and avconv proceeds to process it apparently as it should. I've not yet tried to watch anything mind. The NAS (Iomega Home Media Network Hard Drive - Cloud Edition, now under the Lenonov umbrella) started playing up after a firmware update. I can't find a way to downgrade that doesn't involve completely wiping the drive. WTF can't the makers make previous firmwares available as a download and have means of sending that to the device. My other NAS (ZyXEL NSA310 can do that). This Iomega is not happy, takes even longer than it used to to shutdown/boot and has this weird occasional "no response"/"timeout" thing. It's never been a very good NAS, this is the 2nd replacement under warranty, the first replacement was DOA... It's days are numbered, to be replaced by a 1 or 2TB USB drive directly on the RPi. > Of course that does mean that in other situations an incautious script > could generate many files rather than just one. I'd rather not have something grabbing the same thing again and again... I'm on a tariff capped at 100 GB/month which can be a challenge to keep under if No.1 Daughter is home. B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Pick up from Download Completed?
Hi, Is it possible to pickup from the "Download Completed" point? I run get_iplayer on a Raspberry Pi using a NAS as the download location and also processing the files there via SMB. Problem is the NAS is playing silly B's and goes into a sulk after the download completes and the next avconv stage eventually times out/gives up. The downloaded file should be complete as the script had said fired up avconv... I've looked through various pages of get_iplayer options but can't find anything that looks likely. I've got several of these complete "partial" programmes due to trying to work out what was going on. Seems daft to have to download 'em all again. Asking for the programme again is rejected as it's in the history file and suggests --force. Using --force gets a complaint that the file exists and is skipped. B-( I thought I'd be sneaky and replace rtmpdump with a bash script that just returns a 0 exit code. After emulating the --help response so that gip knows rtmpdump's capabilties that didn't work either or maybe it objected to getting the help text at that point? Adjusts that, nope still skips. Actually it doesn't look like it's getting as far as firing up rtmpdump to try and download/resume before deciding to skip the programme. Removed the programmes entry in the history file, still skips. Adds --force still skips. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Post-processing
On Wed, 7 Jan 2015 22:40:30 +, Jon Davies wrote: > You could always consider using the raspberry pi to run get-iplayer - That is were I run Gip. > another message mentioned creating an xbmc metadata file - get-iplayer > can already do this: > --metadata xbmc Ooo, does it do that for everything it downloads? Series are not a problem as xbmc fills in the metadat from thetvdb.com. One offs I'm creating basic .nfo files manually which is a bit of PITA and they are basic... > get-iplayer can also create folder structures to put things in the > right place Between series and one offs? > (though I concede that might not work for you, because as you note it > doesn't seem to like downloading to network drives) RTMP can sometimes fall over but I think that is more down to the stream getting interupted/corupted than anything else. I keep the Pi and it's NAS powered up. My NAS plays up at times, requires a reboot to get it working again. The mount on the Pi fails and so does the NAS web interface but it'll still respond to a ping so it's half alive. When it is up and running it's fine with Gip running on a Pi with Raspxbmc OS. When RTMP falls over it can leave the partial file behind and not be able to resume. I've also had Gip fall over at other stages leaving broken files and worse an entry in the download_history so it silently doesn't try again. This is why I don't run the PVR via cron... -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: James May - Flight Club
On Mon, 29 Dec 2014 22:06:32 -, Peter S Kirk wrote: >> How does one explain Click, the entire last 12 months of episodes are in >> the cache. Or HARDTalk that appears to go back to 2011. Newswatch >> 17/01/2014 to 13/09/2014. Prime Ministers Questions last 12 months. >> Question Time 09/01/2014 to 10/07/2014. Scottish First Minister's >> Questions last 12 months. This Week 09/01/2014 to 11/09/2014. Welsh First >> Minister's Questions last 12 months. Common factor appears to be they are >> all the product of the News department... > > Imho, its not important what is or is not in the cache. The above was more a rant at the inconsistency of the BBC rather than anything else. If some programmes are listed in the cache for the last 12 months why aren't all? OK the cache would then be about 30 Meg, which might be getting a bit unwieldy. > A google search will find the direct link to the iplayer page to copy and > paste into the PVR. I only run get_iplayer from the command line on a Raspberry. I do have a simple wrapper script so I don't have to remember/type the static information though. > Most important is that GiP works, Double plus 1. > I consider the PVR cache a bonus feature and accept its limitations. I have half a dozen or so permanent PVR searches to grab various programmes if/when they appear. Things like The Sky at Night or picking up an episode of a series that was missed for some reason. I just need to run with the --pvr option every few days and anything that matches "just arrives". When the 30 day retention came in I thought I would be able to relax the few days to less than once a week. Doing a web search for each of those programmes then sorting through the hits to spot what is new would be a right PITA. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: James May - Flight Club
On Mon, 29 Dec 2014 18:41:11 +, Andy Stevens wrote: >> James May's Toy Stories - Flight Club (pid b01pmbmx) is not being listed >> in the tv.cache but is available on iplayer (16 odd days left to watch) > > <= 23 days sounds to me like it was broadcast over a week ago, Sun 14 Dec. > Because it's still within the new & improved 30 days availability period > the bbc now provide. OK, does the real iPlayer downloader have the same (confusing) restriction? Can it see everything for 30 days? > At least, that's how I understood the accompanying notes from some of the > recent fixes. Less than a week it's in the cache. More than a week and > less than a month you have to find it on the web site and download via pid > or url. Ah, ISTR something like that. Doh! I see there is a "timeadded" field in the tv.cache. Scope for the cache maintenance code to not remove something from the cache for 30 days after that date. It wouldn't be fool proof though as it looks like the "timeadded" is when the entry gets written to the cache rather than when it became available from iPlayer. It could be modified by the "episode" field or perhaps the "available" but in my cache that is only ever "Unknown". > Unless it's an older "series catch up" episode, in which case it > may still be in the cache too, but that's less common now that things are > generally available for 30 days. How does one explain Click, the entire last 12 months of episodes are in the cache. Or HARDTalk that appears to go back to 2011. Newswatch 17/01/2014 to 13/09/2014. Prime Ministers Questions last 12 months. Question Time 09/01/2014 to 10/07/2014. Scottish First Minister's Questions last 12 months. This Week 09/01/2014 to 11/09/2014. Welsh First Minister's Questions last 12 months. Common factor appears to be they are all the product of the News department... -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
James May - Flight Club
It's probably down to the BBC but just in case it's not. James May's Toy Stories - Flight Club (pid b01pmbmx) is not being listed in the tv.cache but is available on iplayer (16 odd days left to watch) and can be downloaded using --pid=b01pmbmx. I *think* it was listed in the cache a few days ago. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Seeking advice on transfer to new computer
On Sun, 28 Dec 2014 23:36:27 +, Roger Bell_West wrote: >> As the download_history is in the current users space what happens on a >> multi user system when more than one user requests the same programme? >> Does it get downloaded for each individual user request? > > Tempted as I am to say "try it and see", the answer is yes. > > You could get clever with a group-writeable history file and multiple > links to it, I suppose, but I don't think anyone's complained about > the current system. It's what a program on a multi-user machine is > expected to do: the actions of user A don't affect user B. True enough, I guess it comes from being on the 'net since the early '90's via dialup and paying for every second of online time. Even these days I only normally buy 100 GB/month and that can get a bit tight. Implimenting a single file store and maintianing inter-user "privacy" would be too complicated. A file store that was open and avoided duplicate downloads should be a lot easier, the various cache files could usefully come into this as well. Programme file owned rw by whoever downloaded it, group readable, an option to turn it on with a given path (defaults to no path - off), cache files rw by group. Just an idea, I don't expect to see anything unless the itch I have gets to great and I scratch it. B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Seeking advice on transfer to new computer
On Sat, 27 Dec 2014 21:22:43 +, Roger Bell_West wrote: > ~/.get_iplayer/download_history > > > Configuration is stored per user, so there should be no problem. As the download_history is in the current users space what happens on a multi user system when more than one user requests the same programme? Does it get downloaded for each individual user request? -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Is the tv.cache file shrinking because of the season?
On Fri, 26 Dec 2014 18:36:10 +, Jeremy Nicoll - ml get_iplayer wrote: > Does anyone else keep an eye on the number of entries in these files? Only loosely. Just refreshed and got 1952 tv entries. That's on the low side for recently, the high side I'd but at 2200 ish. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [ANN] get_iplayer 2.91 released
On Wed, 24 Dec 2014 21:34:46 -, Peter S Kirk wrote: > Results from a friend: > All return 404 error on Plusnet in West Cornwall ie BBC News is 404 too Beware the wrapped URL in the orginal message ... B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: [ANN] get_iplayer 2.91 released
On Tue, 23 Dec 2014 20:20:17 +, dinkypumpkin wrote: >> I can confirm all except BBC News result in a 404 Error here too. Perhaps >> it's ISP and/or region issue - Virgin Media cable, Scotchland > > Very possibly, though that would suck for testing. Same result here 404 apart from News. A&A via BT edge service router ERX19-SHEFFIELD4. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: PVR search term suggestions
>> You'll find that "^vent$" will only find the item you want not the >> others, such as advent, Coventry etc. > > Alan, > > Thanks, filed for future reference. I messed around with some wildcard > options last night with no success. Is there a name for the format of > those characters in a search string? They are regular expression (regex) pattern matching markers. ^ matches from the start of the string being tested, $ from the end. So this means only the string vent will match. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Help Please with Radio Download
On Sun, 23 Nov 2014 23:18:50 +, Budgie wrote: > I have Rumpole set up on pvr chron job list but during the various > revisions to GiP some of the episodes have incorrect tagging and no > thumbnail. I saw that these episodes were still available so thought I > would download again with the latest Githead version and pid. > Sadly I received the following message:- > > INFO: Episode-only pid detected > INFO: Trying pid: b007jz59 using type: tv Error: "type: tv" clashes with Subject: "Radio download" > (flashhd,flashvhigh,flashhigh,flashstd,flashnormal) available for this > programme with version 'default' (try using > --modes=flashaaclow,flashaacstd,rtspaaclow,rtspaacstd) Have you tried that suggested --modes option (and told it --type=radio)? -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Do Not Flush
> I usually run GIP without -g to load the cache(s), then give a series of > bash commands separated by ';' to leave GIP downloading overnight, > but if one of them relies on an index number, I don't want the cache > reloaded by that or any of the preceding commands, as that will > change the index number. Can you not use the --pvr feature? It grabs things based on a search string contained in a simple to construct text file in the ~/.get_iplayer/pvr directory. Doesn't matter if the index number changes due to a cache reload and a cache reload will only happen once (if at all) as all the pvr files are checked in a single get_iplayer sesssion. Obviously it'll fail if the programme falls out of the cache but if you just run it nightly that isn't likely to happen as stuff normally stays in the cache for at least 7 days. > BTW, like you I also run GIP from my own script, gip.sh, which > merges the configuration, cache, and download_history data > between two machines, to prevent them redownloading the caches > and/or the same programmes, and so that a configuration change > made to one, or a new search term added to one, will replicate to the > other. Seems rather complicated, no doubt you have your reasons over a master/slave set up. Where you could just copy the cache/history/options from the master to the slave. Are the actual programme files dupicated or do the two machines look in the same place for those? TBH I'm having trouble working out why you need two machines running GIP, just have one and ssh into it from where ever you are. B-) ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT MF interference and ADSL {Was: Slow radio downloads - a bit off topic}
On Wed, 19 Nov 2014 21:53:11 +, Colin Law wrote: > However I still don't think the adsl will disconnect and reconnect again > in the morning just because the interference is lower, otherwise we would > all be seeing regular re-syncs. Depends on the interference levels day to night and the current sync speed. I only have about 6 dB change, with a sync speed of just over 6 Mbps it'll be stable even if the error rate is higher overnight (mostly FEC so no data loss). If it resyncs during the day it can be above 7 Mbps but come evening it'll be awful and may well resync lower (though I normally get peed off and tell it to resync). If the diurnal noise range was higher I can well see it seeing the nice relatively noiseless line sometime after sunrise and syncing at a rate that come evening it can't sustain. TBH I don't notice resyncs most of the time but I get an email from my ISP on each down/up transition. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT MF interference and ADSL {Was: Slow radio downloads - a bit off topic}
On Wed, 19 Nov 2014 16:46:02 +, Colin Law wrote: > I know RF interference at night can cause a resync to a slower speed > but in my experience it will not automatically resync in the morning > again, but will stay at the slower speed, so it will not need to slow > down again the next night. Several days of continuous good signal is > needed before it will resync to a higher speed. This explains why if > you get some temporary interference on the line which causes it to > slow down (an extended thunderstorm for example) then it can be > several days before it comes back up to full speed again. I think you might be confusing the sync rate and the BRAS rate. The sync rate is what the modem and DSLAM (in the local exchange) negotiate and constantly monitor and adjust up/down in response to line conditions. This can be simply the diurnal noise level change, an Openreach person fiddling somewhere and a poor connection crackling as it waggles or as you say a thunderstorm. I switch the modem off for the half hour or so that a thunderstorm takes to pass so the bursts of noise don't force repeated resyncs at low speeds. If that happens the DSLAM will notice fairly quickly and signal the network to change the the BRAS rate. The BRAS rate is the maximum rate that your ISP can feed your (virtual) line. There is no buffering within the network so if you feed data in faster than it can get out you end up with packet loss, retries and reduced through put. If the BRAS gets knocked back and the modem/DSLAM negotiate a higher rate it can take the system up to 72 hours to notice the discrepancy and reset the BRAS to something just below the sync rate. They have tweaked the algorithm since the early days and now if there is a big difference between the sync and BRAS rates the system will notice quicker than a small difference. The BRAS rate used to be in 500 kbps steps but I think these days it's far less granular. > I would have thought some electrical event that happens morning and > evening and knocks it out each time is more likely to explain the OPs > problem. It could well be, as I said the evening break being half an hour before sunset strikes me as a bit early. But if you are listening to MF radio that is about the time the sky wave starts produce interference. I don't know how big the diurnal noise level change is on a line with say several hundred meters over head. Ours (only 50 m ish overhead) has about 6 dB change in noise level. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
OT MF interference and ADSL {Was: Slow radio downloads - a bit off topic}
On Wed, 19 Nov 2014 12:57:30 + (GMT), Jim web wrote: > Be interested to hear if anyone else has had the same sort of weird > behavior that seems to be phased with sunset! ADSL is affected by interference from MF broadcast stations. During the day the ionosphere is "wrong" for the long distance recepetion of MF stations and you can only hear local stations via the ground wave. At night the ionopshere changes and reflects the signals from MF stations over the horizon and you can receive them via the sky wave. Under the right conditions it's possible to hear east coast US MF stations in the UK. Normally all you can hear are stations from all over Europe. This added "noise" at night can play merry hell with ADSL2 which uses frequencies from 125 kHz to 1.1MHz (or 2.2MHz for ADSL2+) for the downlink. The MF broadcast band covers 530 kHz to 1.6 Mhz. I know if my ADSL resyncs during the day it'll do so at aroound 7 Mbps, come evening the noise will have increased and the error rate skyrockets, thus reducing throughput and causing the connection to drop, though unless it gets really bad it won't actually resync. Resync at night and it'll be just over 6 Mbps, this produces a stable connection day or night that is relatively error free. What is a bit odd about your "fault" is the fairly regular timing. Sync during the day could well be way above what it can do at night hence the drop at sunset (though that seems a bit early). In the morning the reduced noise prompts the modem into resyncing at a high rate, ready for the evening... Apart from the last 50 m or so our line is undergroud. I can imagine that a line with a lot of overhead would be far more sensitive to this diurnal change in noise level. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
OT RE: Slow radio downloads - a bit off topic
On Tue, 18 Nov 2014 21:36:52 -, George Eycott wrote: >> Who is your ISP? > > BT :-) They have admitted the exchange is in congestion. >From what I've heard/seen BT Openreach(*) are normally pretty good at bringing on extra capacity when it's required, couple of weeks normally. It can be rather longer if they haven't any dark fibre available. However BT Openreach might not notice the lack of capacity until an ISP complains. IMHO BT Internet is so big and most people just accept that "the internet" slows down in the evening that very few people actually complain so it doesn't register with them. With a more "proactive" ISP it's a different story, the likes of A&A, Zen etc. > And the good news is that a new housing estate is being built in the > village so that is going to help Not. It may kick BT Openreach into upping the backhaul, but I wouldn't like to say that would improve your service. It really depends on what BT have available/install and what the developer installs (ducts, cable/fibre etc) and how big the estate is. Bear in mind that the fibre of a FTTC connection may not terminate at the exchange where the POTS line and thus ADSL does. (*) In broad terms, I think the backhaul/network provision is handled by a different section of Openreach to the holes and poles mob, as is 21CN (the move from an ATM based network to IP based). -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Slow radio downloads - a bit off topic
On Tue, 18 Nov 2014 20:20:31 -, Peter S Kirk wrote: > Do you have a strong signal from any of the mobile networks? Plenty of > 3G/4G unlimited packages available, ... Is that using an english definition of the word "unlimited" or a marketing speak definition? That is "unlimited" within the limits applied via an Acceptable Use Policy. I could use a back up for the ADSL, use in the order of 60 to 200 GB /month depending on how many kids are home. If you stand near a window on the right side of house up stairs you can get a 3G signal, so a truely unlimited 3G account could be useful. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Slow radio downloads - a bit off topic
On Tue, 18 Nov 2014 18:46:48 -, George Eycott wrote: >> 5 Mbps, 11 Mbps, 60 Mbps - these are numbers I just don't recognise -:( >> Here in rural Pembrokeshire, West Wales, I consider myself lucky if I get >> the nominal 2Mbps that BT rate the line > > Luxury. I'm lucky, get a reliable sync speed of 6 Mbps with through put over 5 Mbps. Down in the village about 2 km further away it's as you describe, if not worse. However a VDSL cabinet has just sprung up down there, so they should be getting 30 or 40 Mbps in the center of the village by year end. Our line doen't go anywhere that cabinet but at 2 km would only get about 15 Mbps anyway. Another cabinet has popped up outside the exchange 3+ km away, that wouldn't perform much if any better than the current ADSL2. But the *really* galling thing is that the fibre cable to feed the cabinet in the village passes under our forecourt about 15' from the front door. > 2Mb/s download, yep we get that OK until the schoolbus pulls up in the > village in the afternoon then 10 minutes later everything slows to a > crawl. Who is your ISP? I don't get any slow down but others I've spoken to on the same exchnage but use different ISPs do. The congestion may not be at the exchange or on the backhaul but rather closer to the ISP... -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT Slow radio downloads was Re: Slow radio downloads
On Tue, 18 Nov 2014 10:47:26 -0600, artisticforge . wrote: > to get 60Mbps you have either fibre or coax. not going to get 60mbps > over plain old copper twisted pair. er VDSL is delivered over an ordinary copper pair, it's only Fibre to the cabinet. VDSL2 "up to 76 Mbps" ought to deliver > 60 Mbps out to about 500 m line length from the cabinet. Don't fall BT's marketing of "fibre optic broadband" it's not. If it was they'd be offering 100 Mbps symmetrical as a basic service with options up to 1 Gbps or higher. I can see that the huge amount of our money being given to BT to install FTTC is going to backfire in a few years. The technology just isn't up to providing two or three proper, as in equal to DSAT or better Bluray data rate, HD TV streams. Think of a family kids up stairs streaming stuff parents down stairs... > I have a microwave link and I am happy with the 6Mbps . > I do not stream video. no nexflix. no youtube. 6 Mbps is good enough for those but the data they consume might be a problem if you have a data allowance. The 2.5 ish Mbps iPlayer "HD" downloads consume 1+ GB/hour. "HD" in quotes as HD really needs 10 Mbps to look good, Bluray mentioned earlier runs at 40 Mbps. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Slow radio downloads
On Tue, 18 Nov 2014 06:27:36 +, Alan Milewczyk wrote: >> No problems here at 06h15 - seems pretty much what I'm used to at this >> time of the morning. iPlayer is one of the few sites that can fully saturate our meagre 5 Mbps ADSL connection anytime of day or night. No evening slow downs here... > Thanks guys. Very odd, after a few hours of this strange behaviour, all > of a sudden the radio download speeds went back to normal, just like > someone turning the tap on fully. Maybe they did, something "odd" happened here yesterday. Around about 1345 1415 we "lost the internet". Modem was still connected and had the right numbers and was sending packets but ping or traceroute couldn't see anything past the modems router. Reset the ADSL bit only and it all came good. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: iplayer audio to lpcm
On Tue, 11 Nov 2014 09:52:46 + (GMT), Jim Lesurf wrote: >> False assumption that there is only one mix leaving site... or >> even that the same mics are being used across the different services. >> Particulary for broadcasts on BBC1/2, not so sure what happens for BBC4. > > < cough syrup :-) > I know from measurement and from discussions with some > involved that for the Proms on BBC4TV they use the R3 feed for the music. > BBC1/2TV do their own things, though. At times, that shows up clearly in > terms of things like reduced dynamic range on BBC1/2. I more than half expected you to know all that already. B-) Long gone are the days of a pair of analogue music lines leaving site through a spider filled and corroded GPO block terminal then to have some hefty line equalisation applied. Always amused me that the "golden ears" would worry about mono directional oxygen free crystal orientated interconnect cables... > Some quite subtle differences can crop up at times. e.g. > the 'time travel' I found one year. The best guess we reached for it > was the presence of asynch resamplers in a chain. Of course one swaps one set of "problems" for an other. Now we have magic boxes interpreting meta data that can be altered by a rogue magic box enroute which then confuses everybody. Even routine OB's have multiple feeds leaving site, generally embedded but not always (which leads to even greater fun with sync). And all this is orgination, well before transmission/distribution for DTTV/DSAT/Streams/iPlayer get their sticky fingers on it. B-) -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: iplayer audio to lpcm
On Mon, 10 Nov 2014 17:41:05 + (GMT), Jim Lesurf wrote: >> IMO any significant difference in sound is going to be down to relative >> codec efficiency, not due to huge differences in the TX chain. iPlayer >> desktop uses AAC-LC, DSAT is MP2 and AAC for HD, DTT the same albeit at >> lower bit rates. > > In general terms, that's what I'd be expecting. Particularly when my > favourite source material for comparisons has tended to be proms concerts > where I can compare R3 with BBC4, for example. False assumption that there is only one mix leaving site... or even that the same mics are being used across the different services. Particulary for broadcasts on BBC1/2, not so sure what happens for BBC4. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Your message to get_iplayer awaits moderator approval
> 2)I often forget to start get_iplayer with nice, and it's nice to have the > fallback position of the worst offenders being controlled anyway. Write a shell script to run get_iplayer under nice or set an alias in your shell's config? ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: OT: reply-to [was Re: iplayer audio to lpcm]
> Just use reply all. If somebody doesn't like duplicates, they can go > to http://lists.infradead.org/mailman/options/get_iplayer and set > "Avoid duplicate copies of messages?" to yes. Thanks for that, now set. Not an option I've seen before but then I'm not in the habit of exploring mailman options... I'm also well aware that if a list has this "different" behaviour then the chances of it changing are minimal. Having said that if the default for the above setting was yes it would side step the "problem". B-) ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: iplayer audio to lpcm
Me to. Read it in an email list or newsgroup the default reply should be back to the list/group otherwise threads dive off into private email. The use of Reply All means that the sender has to edit the recipient's or the recipient annoyingly gets the posting twice. Probably in the best part of a couple of dozen lists, all but two or three set the Reply To: back to the list. -- Cheers Dave. -Original Message- From: Owen Smith To: get_iplayer Sent: Sat, 08 Nov 2014 13:32 Subject: Re: iplayer audio to lpcm Blasted mailing list, I sent the message below as a personal reply, AGAIN. I simply cannot get my brain to accept how this list works. I'm on half a dozen other mailing lists all of which work the other way round ie. replies go to the list. Mutter. -- Owen Smith Cambridge, UK On 8 Nov 2014, at 12:54, Owen Smith wrote: > This is decoding a lossy format (AAC), not encoding. Provided there are no > digital volume controls or similar being applied, the results should be > identical regardless of which software is used to decode it. It's the > definition of AAC that dictates what an AAC stream decodes to. Encoding yes > there is plenty of room for different implementations to produce different > results, but not decoding. Otherwise it wouldn't be a correct decode of the > AAC. > -- > Owen Smith > Cambridge, UK > > On 8 Nov 2014, at 12:26, Jim Lesurf wrote: >> >> Thanks, I'll look at the above. One of the things I'm curious about is the >> relative performance (in terms of quality, etc) of ffmpeg versus avcodec. I >> come to this from being a long term user of ffmpeg, but knowing nothing >> about the forking or its effects. Given my past I tend to go for using >> ffmpeg as my first intent. But would/will change if it is advantageous. >> >> Jim >> ___ 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: Episode Numbering not working
On Thu, 06 Nov 2014 12:03:52 +, dinkypumpkin wrote: >> I noticed an error message about screen scraping not working if >> HTML::Parser was out of date - so I updated my Perl modules and it seems >> to be working better now. > > That's part of it, but there are some more changes necessary to pick up > episode numbers for programmes not in the cache. Will be in next release. Episode numbering isn't working (for me) with a programme *in* the cache: 834|tv|Horizon|b039grrx|Unknown|2013-2014: Dinosaurs: 4. The Hunt for Life||4|default|3600|Meeting a scientist who may have found signs of dinosaur DNA within their ancient remains.|BBC Two|Factual,Science & Nature,Science & Technology| http://ichef.bbci.co.uk/images/ic/150x84/p01k0prv.jpg|1415398022|| http://www.bbc.co.uk/programmes/b039grrx| Produced filename: s01e01.2013-2014_Dinosaurs_The_Hunt_for_Life.b039grrx.mp4 Options file has "fileprefix ..". OK for use with XBMC/thetvdb.com it's needs changing to s2013e13 anyway but it's not picking up the 4 that is in the cache. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Thank you - great work ....
On Fri, 07 Nov 2014 14:12:27 +, SquarePenguin wrote: >> Only small point is that at the end of a record there are hundreds of >> these - which slows down the Run PVR: >> >> size= 116kB time=00:00:07.39 bitrate= 129.0kbits/s >> size= 163kB time=00:00:10.34 bitrate= 128.7kbits/s > > Aren't those the transcoding rate indicators? After download it > transcodes (I think that's the right word) the flv to mp4 and spits out > the progress reports above. Transcode is the word I'd use for the format conversion. B-) > Not sure if you're using a Raspberry Pi but the conversion bitrate looks > to me like it simply indicates low powered hardware so the conversion is > taking a while to complete. I run get_iplayer on Raspberry-Pi and the bit rate shown during transcoding a HD download is normally around 2500kbits/sec which I have always taken to be the bitrate of the resultant stream. It also reports a "fps" which normally has value of around a couple of 100. If the bit rate was that of the conversion it would be an awful lot higher than 2.5 Mbps... What does happen is that after a while the line grows 1 character longer due to a count going from 999 to 1000+. This then forces the terminal onto a new line, so you end up with this report scrolling up the screen rather than over printing the existing one. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Thank You
Just joined the list to say a *BIG* thank you to the maintainers for getting the search/PVR functionality back into get_iplayer so quickly. When get_iplayer --pvr failed to work the other day and I saw the message in tv.cache I thought that was it. B-( Using the pid or URL method worked but would have been a PITA to use long term. So thank you again. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
