|
|
get_iplayer 3.00 released
Top posted for Brian:
gip is essentially command line. Others have built various other programs around it. Given that it can be installed and run on Windows, it should be possible to run it there in a terminal. (I don't use Windows so can only take those points for granted here.) On that basis I'd suspect that as Brian can type he can type in a simple command. Either into the terminal, or to write a simple script file that will run gip. All that is then needed in principle is for Brian to be able to read the pid shown for each programme in the iplayer listings pages. Then give gip that pid to fetch. The difficult part would, I assume, be setting this all up in the first place. But it should then be easy to use assuming the above. It also occurs to me to wonder if someone who uses Windows could write a suitable 'wrapper' program for those who have sight impairments and make this easier. I also wonder if gip can be made to just fetch the required *audio* streams for TV programs as this would mean people who don't actually want the video could save the bother, etc, of getting it and have smaller, more quickly fetched, files to play. Have these issues been covered in the past? Jim In article , NY wrote: Get iPlayer is good nd gets the job done, but it does have a slightly geeky feel to its UI, as if they hastily bolted a Windows front end onto a real-men-use-command-lines user interface ;-) -- Please use the address on the audiomisc page if you wish to email me. Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
get_iplayer 3.00 released
On 02/05/17 08:38, Mike Tomlinson wrote:
En el artículo , Andy Burns escribió: forecast sounds gloomy ... "For whatever life it has left, get_iplayer will rely more heavily on web scraping" I don't understand this. If get_iplayer is having to evolve to keep up with changes the BBC make (and I'm not sure what those changes are), doesn't that render older set-top boxes, TVs and other devices that have iPlayer baked into their firmware obsolete? The BBC iplayer site presented on end devices is a web site hosted from somewhere. Manufacturer's proxy or straight to the BBC CDN, not sure. The clients are lightweight and within a specification window that is outside obsolescence (well, for the moment...) -- Adrian C |
get_iplayer 3.00 released
On Mon, 01 May 2017 17:13:48 +0100, Jim Lesurf wrote:
In article , Johnny B Good wrote: On Mon, 01 May 2017 09:25:21 +0100, Pete Forman wrote: get_iplayer 3.00 for Windows and other systems was released yesterday. The main feature is: Restored functionality broken by the BBC Some features that were deprecated previously have now gone. Caching has been revised, you will need to rebuild. https://github.com/get-iplayer/get_i...iki/release300 Thank you for that timely news, Pete. I'm running LM 17.1 KDE 64 and have been putting off an update to ffmpeg that appeared in the update manager list several days back. The new version number bears so little resemblance to 3.0 (7:3.3.0~trusty), I was afraid to allow the update in case it broke my especially installed ffmeg ver 3.0. FWIW I keep different versions of ffmpeg in different places. GiP lets you specify where to find the version it should use for a command you give to it. Well, GiP provides an awful lot of 'BackChat' (noise more like) whenever it's downloading and processing each recording, including pointless warnings about possible failure to ffmpeg a file correctly in spite of the required version being accessable both before and after this recent ffmpeg update which was joined by the latest GiP update (also from the trusty PPA repository) in the Update Manager list a few hours after posting my misgivings about the trusty PPA sourced version of ffmpeg. I guess I can 'let it rip' now and see whether my fears were justified since any remediation work it might cause will be 'lost in the noise' of a major (to me) update task (as in the, "It's nothing on a big ship" philosophical point of view). I wanted to process my list of yesterday's PIDs before chancing complete breakage of my GiP setup by allowing the ffmpeg update. The delay proved useful since the trusty PPA repository I'd added meant the latest GiP version, given the extra time, refreshed Linux Mint's update manager. I was less leery of applying these associated updates so happily signed off on the updating tasks. FWIW2 I've experimented and found that with my old version of GiP simply using --fileprefix \"title_pid\" added to the command string I build to feed to gip means I get files that have a sensible title and include the pid. N.B. I'm escaping the " chars above because I use a sprintf() to assemble a command string which is then used to launch gip. (And as per above I include an --ffmpeg option to point to the version gip should use.) It seems a little odd to me that having installed the latest and greatest version of ffmpeg just prior to ditto for GiP, that there is *still* the need for this. Has this *always* been the case with every install of GiP? I mean, if this is SOP for every single installation of GiP, then so be it. If it suppresses some of the needless 'backchat' from a rather 'gobby' GiP, I'm only too happy to oblige (noblesse and all that, don't y'know!). Taking note of the benefit in filtering the sources to speed up indexing, I've eliminated regional and local variants, adding back the wanted exceptions as well as excluding unwanted channels (BBC News, CBeebies and Parliament). Refreshing the cache still overflowed the Konsole buffer and it took me a while to figure out how to completely purge it before getting the index list down to a manageable size. Since I couldn't find an obvious command line incantation, I just unhid the user folders to access the GiP working folder to remove the cache files to elsewhere to permit a fresh start sans all the unwanted sources that had been cluttering up the cache. Later perusal of the vast list of user options suggested I'd merely missed the desired option to do what I'd been forced to do by manually manipulating the files directly. The further perusal being in the pursuit of preventing Gip using underscores in place of whitespace (amongst other options of interest that I'm still trying to get my head around). I'm not complaining since I'm only too aware of the need for this (perceived) complexity that arises when a non-trivial program attempts to offer the end user a solid helping of customisation to their almost unique blend of requirements. One of the settings in user preferences that I tried was to up the tv quality to best. Unfortunately, this action (seemingly unneeded on account it happens to be the default anyway) coincided with what appears to be some more sabotage on the part of the eejits in charge of the Beeb's iPlayer concession stand. In attempting to refresh episodes from series 5 of "Shaun The Sheep" which had previously *not* been processed into mp4 files by ffmpeg but processed directly from their raw ts format by Handbrake into mkv files, I hit a strange problem during the downloading. As previously, they started off as the 1280 by 720 120MB file size until hitting the 17.1MB mark, at which point the source was changed to the 960 by 540 96MB due to lost/corrupted packets in the HD source. Since this problem afflicted *both* of today's episodes, I'm inclined to the theory of it being sabotage, plain and simple rather than some curious accident. Disabling the servers in turn (Akamei and Limelight) didn't change the outcome, just the question of the starting filesize. Personally speaking, I'm of the conviction that the untimely removal of the metadata sources wasn't a matter of inconsiderate incompetence but an active act of sabotage for a rapidly increasing number of GiP users that the Beeb now see as a licensing and rights issue they can no longer ignore on the basis of 'insignificance'. Never mind that they are a Public Broadcasting Service whose viewership includes a portion keen enough to provide a "Free Cloud Storage Backup Facility" to protect against loss of priceless one off classics due to parsimonious cockups such as those that afflicted "Doctor Who" and "Dad's Army" resulting in episodes which are now lost forever (quite possibly, such parsimony may be the reason why other more worthy classics such as "The Goodies" and "Steptoe and Son" have never been repeated by the Beeb). The risk of loss is no longer a case of wiping a programme recording on very expensive videotape for re-use (a £70 videotape for just a single programme back when £70 was real money rather than the pocket change of today, capable of buying more than enough of the highest quality storage for the Beeb's total weekly output). The risk of 'lost episodes' these days is going to arise from "Finger Trouble" or "Brain Farts" since the efficiency of file deletion is now several orders of magnitude greater in both quantity and speed than good old fashioned bulk erasure of videotapes. The Beeb ought to be showing this willing band of volunteer backup storage providers less disdain and a hell of a lot more respect for their efforts in providing a tertiary level of backup protection, in my considered opinion. -- Johnny B Good |
get_iplayer 3.00 released
On Tuesday, 2 May 2017 08:38:26 UTC+1, Mike Tomlinson wrote:
En el artÃ*culo , Andy Burns escribió: I don't understand this. If get_iplayer is having to evolve to keep up with changes the BBC make (and I'm not sure what those changes are), doesn't that render older set-top boxes, TVs and other devices that have iPlayer baked into their firmware obsolete? It certainly does. My main TV is a so-called "smart" TV, and it has now joined the Wii with a non-working iPlayer app. GiP is now my only way of transferring iPlayer content to my TV. Ian. |
get_iplayer 3.00 released
On 02/05/2017 18:02, Johnny B Good wrote:
snip The Beeb ought to be showing this willing band of volunteer backup storage providers less disdain and a hell of a lot more respect for their efforts in providing a tertiary level of backup protection, in my considered opinion. I can only think: a. you missed the point about the BBC not owning the intellectual property in everything it broadcasts; or b. you believe that all property is theft. -- Robin reply-to address is (intended to be) valid |
get_iplayer 3.00 released
On Tue, 02 May 2017 19:48:59 +0100, Robin wrote:
On 02/05/2017 18:02, Johnny B Good wrote: snip The Beeb ought to be showing this willing band of volunteer backup storage providers less disdain and a hell of a lot more respect for their efforts in providing a tertiary level of backup protection, in my considered opinion. I can only think: a. you missed the point about the BBC not owning the intellectual property in everything it broadcasts; or b. you believe that all property is theft. If that's all you can (erroneously) think, it seems to me that you aren't using your brain to its full potential. FTAOD, both thoughts are completely wrong BTW. -- Johnny B Good |
get_iplayer 3.00 released
On 2 May 2017 18:22:00 GMT, Huge wrote:
If get_iplayer is having to evolve to keep up with changes the BBC make (and I'm not sure what those changes are), doesn't that render older set-top boxes, TVs and other devices that have iPlayer baked into their firmware obsolete? It certainly does. My main TV is a so-called "smart" TV, and it has now joined the Wii with a non-working iPlayer app. GiP is now my only way of transferring iPlayer content to my TV. FWIW, my Samsung SMART TV is still fine. Although deeply **** in a number of other ways.h I have an Amazon box, and a stick, both of which are still working fine with iPlayer and all the other stuff, and a great deal more briskly than any "smart" TV or PVR I've ever used. But then, Amazon regularly update their gadgets, which are quite cheap to buy in the first place, no doubt knowing full well what would happen to their customer base if they didn't. This is probably a consequence of the supplier of the gadgets also being the supplier of services that go with them, a condition that doesn't apply to TV sets. It's probably inevitable. Rod. |
get_iplayer 3.00 released
Huge wrote:
I shall never buy another Samsung product as long as I live. Do you expect to run out of manufacturers and newsagents to blacklist before you kick the bucket :-) |
get_iplayer 3.00 released
On 3 May 2017 09:59:45 GMT, Huge wrote:
If get_iplayer is having to evolve to keep up with changes the BBC make (and I'm not sure what those changes are), doesn't that render older set-top boxes, TVs and other devices that have iPlayer baked into their firmware obsolete? It certainly does. My main TV is a so-called "smart" TV, and it has now joined the Wii with a non-working iPlayer app. GiP is now my only way of transferring iPlayer content to my TV. FWIW, my Samsung SMART TV is still fine. Although deeply **** in a number of other ways.h I have an Amazon box, and a stick, both of which are still working fine with iPlayer and all the other stuff, and a great deal more briskly than any "smart" TV or PVR I've ever used. But then, Amazon regularly update their gadgets, which are quite cheap to buy in the first place, no doubt knowing full well what would happen to their customer base if they didn't. This is probably a consequence of the supplier of the gadgets also being the supplier of services that go with them, a condition that doesn't apply to TV sets. It's probably inevitable. I freely admit that the Samsung SMART TV was a mistake. It's a festering PoS. I shall never buy another Samsung product as long as I live. I have several Samsung displays, including the TV, and they're all excellent - at displaying pictures. I just don't expect the TV to do anything other than display pictures. The clever stuff is best left to other devices, for the reason I suggested above. I suspect the same would apply regardless of what brand of TV I had. Rod. |
| All times are GMT +1. The time now is 08:01 AM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
HomeCinemaBanter.com