get_iplayer 3.00 released
 

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


--
Pete Forman
https://payg-petef.rhcloud.com

get_iplayer 3.00 released
 

"Pete Forman" wrote in message
...
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

So far it seems to be working just as well as if did before. Despite the
warnings that it will take a lot longer to populate the list of programmes,
I found that after clearing the current list and starting again took about 1
minute, not the 5-10 that they predicted.

About the only difference that I could see was that the programmes no longer
have a thumbnail screen-shot icon beside them - not a major problem.

get_iplayer 3.00 released
 

Pete Forman wrote:

get_iplayer 3.00 for Windows and other systems was released yesterday.

forecast sounds gloomy ... "For whatever life it has left, get_iplayer
will rely more heavily on web scraping"

get_iplayer 3.00 released
 

Andy Burns writes:

Pete Forman wrote:

get_iplayer 3.00 for Windows and other systems was released yesterday.

forecast sounds gloomy ... "For whatever life it has left, get_iplayer
will rely more heavily on web scraping"

I have just rerun a couple of Python scripts I wrote in 2014 that pulled
metadata from the BBC. The XML one fails, obviously. The HTML scraper
needed one change.

--
Pete Forman
https://payg-petef.rhcloud.com

get_iplayer 3.00 released
 

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.

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).

If I hit any problems, I'm sure I'll be able to inject some overdue
activity into the ucol news group before resorting to this one for
further help. :-)

--
Johnny B Good

get_iplayer 3.00 released
 

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.

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).

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.)

Jim

--
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
 

Does this program work with a screenreader and also does it allow selection
of the AD stream on a program that has this. I'd have thought this would be
very trivial to add for them if its not there. When you can confirm these
then give me a download link for a windows built version. Thanks.
Brian

--
----- -
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...

Blind user, so no pictures please!
"NY" wrote in message
o.uk...
"Pete Forman" wrote in message
...
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

So far it seems to be working just as well as if did before. Despite the
warnings that it will take a lot longer to populate the list of
programmes, I found that after clearing the current list and starting
again took about 1 minute, not the 5-10 that they predicted.

About the only difference that I could see was that the programmes no
longer have a thumbnail screen-shot icon beside them - not a major
problem.

get_iplayer 3.00 released
 

"Brian Gaff" wrote in message
...
Does this program work with a screenreader and also does it allow
selection of the AD stream on a program that has this. I'd have thought
this would be very trivial to add for them if its not there. When you can
confirm these then give me a download link for a windows built version.
Thanks.

I'm not sure what needs to be done to a web page to make it work well with a
screen reader. Hopefully the developers can say whether they have tested it
with a selection of screenreader programs.

There is a sub-menu on the web page (on localhost on your PC) which allows
you to select the version of the programme. And you can select that you want
a version that has AD. I'm not sure whether you can set a default value so
for all future programmes you always get the AD version.

One of the potential problems may be that the feedback as to when the
programme has finished downloading is visual: you get lots of info about
downloading the initial version as a TS file, downloading subtitles as a
text file, merging the two together to produce an MP4 file - interesting as
a progress report but the crucial thing is "all finished: now you can watch
/ listen to what you've just downloaded".

I've just had a thought: I wonder if there is a way of only downloading the
soundtracks (programme audio and AD) without needing to download the video
part - that would speed up download considerably.

get_iplayer 3.00 released
 

"NY" wrote in message
o.uk...
"Brian Gaff" wrote in message
...
Does this program work with a screenreader and also does it allow
selection of the AD stream on a program that has this. I'd have thought
this would be very trivial to add for them if its not there. When you can
confirm these then give me a download link for a windows built version.
Thanks.

I'm not sure what needs to be done to a web page to make it work well with
a screen reader. Hopefully the developers can say whether they have tested
it with a selection of screenreader programs.

There is a sub-menu on the web page (on localhost on your PC) which allows
you to select the version of the programme. And you can select that you
want a version that has AD. I'm not sure whether you can set a default
value so for all future programmes you always get the AD version.

One of the potential problems may be that the feedback as to when the
programme has finished downloading is visual: you get lots of info about
downloading the initial version as a TS file, downloading subtitles as a
text file, merging the two together to produce an MP4 file - interesting
as a progress report but the crucial thing is "all finished: now you can
watch / listen to what you've just downloaded".

I've just had a thought: I wonder if there is a way of only downloading
the soundtracks (programme audio and AD) without needing to download the
video part - that would speed up download considerably.


If you want to try it (maybe with a sighted person to help with initial
navigation around the screens until you work out how best to drive it from a
screen reader) then the URL is:
https://github.com/get-iplayer/get_i...yer-3.00.0.exe

The Release Notes are at
https://github.com/get-iplayer/get_i...iki/release300


The installation instructions are fairly wordy but as far as I remember from
when I initially installed an older version, from which I've periodically
upgraded, you run the EXE file and end up with a desktop icon Web PVR
Manager which starts various components, the main one being a web page in
your default browser which allows you to: update the list of available
programmes (the thing that caused all the hassle when the BBC withdrew the
older source of this information); search this list for matching programmes;
schedule programmes to be downloaded to a default Windows directory.

A typical programme is about 800 MB for a 1-hour programme in 1280x720
resolution which seems to be default, so you'll need to work out download
times based on your download speed. One of the options on the Recording tab
allows you to specify "recording modes" and you can at least reduce time by
selecting "good" rather than the default "better" which gives you SD rather
than HD. The "programme version" on the same tab has options such as
"audiodescribed".

Incidentally, those controls could be implemented *so* much better if they
were drop-down boxes with a finite set of choices that allowed you (in the
case of resolution) to choose using real units (eg "SD 720x576", "sub-HD
1280x720", "HD 1920x1080" rather than woolly adjectives like "good",
"better", "best" that you have to type in a text box) :-)

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 ;-)

get_iplayer 3.00 released
 

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?

--
(\_/)
(='.'=) "Between two evils, I always pick
(")_(") the one I never tried before." - Mae West

get_iplayer 3.00 released
 

WEll using the raw new iplayer I cannot find the tools and ways to watch any
more. The problem being that when you select yes I have a tv licence the
damn thing starts playing making the screenreader pointless and drowned out
I'll do another thread later on about using the newly botched up pages of
Iplayer that worked well previously.
Brian

--
----- -
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...

Blind user, so no pictures please!
"NY" wrote in message
o.uk...
"Brian Gaff" wrote in message
...
Does this program work with a screenreader and also does it allow
selection of the AD stream on a program that has this. I'd have thought
this would be very trivial to add for them if its not there. When you can
confirm these then give me a download link for a windows built version.
Thanks.

I'm not sure what needs to be done to a web page to make it work well with
a screen reader. Hopefully the developers can say whether they have tested
it with a selection of screenreader programs.

There is a sub-menu on the web page (on localhost on your PC) which allows
you to select the version of the programme. And you can select that you
want a version that has AD. I'm not sure whether you can set a default
value so for all future programmes you always get the AD version.

One of the potential problems may be that the feedback as to when the
programme has finished downloading is visual: you get lots of info about
downloading the initial version as a TS file, downloading subtitles as a
text file, merging the two together to produce an MP4 file - interesting
as a progress report but the crucial thing is "all finished: now you can
watch / listen to what you've just downloaded".

I've just had a thought: I wonder if there is a way of only downloading
the soundtracks (programme audio and AD) without needing to download the
video part - that would speed up download considerably.

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.

get_iplayer 3.00 released
 

In article , Johnny B Good
wrote:
On Mon, 01 May 2017 17:13:48 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:



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?

It may depend on what version, fetching mode, if you want to tag or clean,
etc. The change that 3.00 makes is to deal with the BBC ceasing to provide
XML. That 'broke' the way metadata was cached and used to name the fetched
files, etc. Using the above fileprefix is a simple way to get the file name
as that still seems to work.

The difficulty here, though, is that I think that distro versions of ffmpeg
/ avconv vary. So you may need a suitable version for some fetched stream
files.

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!).

There may be an option to reduce the verbose output or redirect it to a log
file. Dunno. I just let that wash though the terminal and discard it once
fetching and conversion are done.



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.

I suspect that was a SNAFU somewhere upstream.

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'.

I doubt that because they have made plain that other approaches are
available. Their standard position is that gip isn't their concern. In
practice it means they don't have to take it into account when making
changes for any reason.

How would you or I determine how many people are using gip? I suspect it
remains a minority because getting it going is quite a geeky process. But I
don't know how we'd tell.

Jim

--
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
 

"Huge" wrote in message
...
On 2017-05-03, Roderick Stewart wrote:
On 3 May 2017 09:59:45 GMT, Huge wrote:

[23 lines snipped]

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.

Agree with every word. The (spit) Samsung TV has excellent picture
quality. Everything else about it is garbage.

We have a Samsung flat-screen TV and an LG DVD/BluRay player, both about
2007 vintage.

Try as I might, I cannot adjust the TV so it doesn't clip the highlights,
usually for only one or two of the three colours so you get a colour cast on
highlights. Even on minimum brightness and contrast (which produces a dark,
muddy picture, as you'd expect) there are *still* clipped highlights :-(

One thing I've noticed is that BluRay films often have a predominance of
faint turquoise shading which isn't there on DVD films, though I've never
had chance to compare a BluRay and DVD of the *same* film.

It would be nice if there was a way of altering the TV's response (eg
brightness/contrast/chrominance) for each of its HDMI inputs separately.
When we play off-air recordings via our Roku box and Plex server, the
colours are very muted compared with an off-air broadcast (through the TV's
DVB decoder) or compared with live/recorded TV from the Sky box.

get_iplayer 3.00 released
 

On Wed, 03 May 2017 13:32:03 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:
On Mon, 01 May 2017 17:13:48 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:



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?

It may depend on what version, fetching mode, if you want to tag or
clean, etc. The change that 3.00 makes is to deal with the BBC ceasing
to provide XML. That 'broke' the way metadata was cached and used to
name the fetched files, etc. Using the above fileprefix is a simple way
to get the file name as that still seems to work.

The difficulty here, though, is that I think that distro versions of
ffmpeg / avconv vary. So you may need a suitable version for some
fetched stream files.

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!).

There may be an option to reduce the verbose output or redirect it to a
log file. Dunno. I just let that wash though the terminal and discard it
once fetching and conversion are done.

Yes, of course, I do the same (it's not as if I have much choice). It's
just that it seems to be the victim of verbosal diarrhoea :-( It
wouldn't matter too much except that I usually have to scroll back to
copy a pid from the download request list to paste into a recalling of
the --force --pid xxxxxxx command line to force the issue. I'm re-
downloading previously downloaded files so GiP can apply the ffmpeg
process to create mp4s which despite VLC's shortcomings, are usually
significantly smaller than the mkvs created by Handbrake out of the
raw .ts files. The only time I process the mp4 files with Handbrake now
is when dealing with pillar boxed 4:3 AR material, widescreen movies
(typically cuts out the DOG) and cartoons which do usefully shrink in
size.




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.

I suspect that was a SNAFU somewhere upstream.

After getting today's episodes in 1280 by 720, I had another go at
downloading yesterday's episodes. One of them completed the 1280 by 720
version download ok but the other one remains resolutely stuck in that
weird oddball 960 by 540 mode (and both had previously been downloaded in
the higher resolution early November last year).


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'.

I doubt that because they have made plain that other approaches are
available. Their standard position is that gip isn't their concern. In
practice it means they don't have to take it into account when making
changes for any reason.

Well, let's hope that remains true. If they're going to continue to
offer a download service to allow their less fortunate viewers to watch a
delayed playback free of buffering glitches due to limited bandwidth,
there'll always be a way for gip users to work around whatever other
obstacles may arise in the 'useability' of gip.


How would you or I determine how many people are using gip? I suspect it
remains a minority because getting it going is quite a geeky process.
But I don't know how we'd tell.


I wouldn't bank on them *not* knowing how much of their traffic is
serving request from gip users (or at least an equivalent downloading
utility that defeats the expiry functionality built into the official
iplayer media players or apps).

Also, don't forget the existence of the windows versions of gip which
has a much wider audience than the mac/*nix geek community, lest you
under-estimate the true size of a gip tooled up audience. Not *every* gip
user is a mac/linux/bsd geek. :-)

What raises my suspicions is the greater prevalence of 960 by 540
versions in place of the 1280 by 720 versions. There's always been an
element of randomness in the quality, not just between programme series
but between episodes within any one series.

A year or so back when I first discovered the joys of downloading from
the iPlayer servers, it was a pretty reliable source of semi HD versions
of the broadcast SD material I was recording at the time.

The only reason I got interested enough to go to the trouble of getting
gip to work on this Linux Mint Desktop in the first place was to retrieve
cocked up off-air recordings due to scheduling errors (rarely of my own
making I have to say) which were the result of BBC programme scheduling
****tery, often due to unscheduled breaking news events (excusable to
some degree) or else "unpredictable" sports event over-runs (or even,
worse still, *under-runs* but in either case, both inexcusable when they
have that run-off feature known as "The Red Button Service" to save them
the embarrassment of acting like bloody minded ****s).

Now that iPlayer has lost the plot with regard to 1280 by 720
availability, it's beginning to look more and more like an avenue of last
resort in the event of scheduling ****tery rather than a compromise
halfway solution to a dual tuner DVB-T2 upgrade that should give me
access to "Full HD" quality recordings via off-air Freeview broadcasts.

I'm now going to embark on yet another search for a cost effective Linux
compatible dual tuner DVB-T2 PCI or PCIe adapter and hope I have better
luck *this* time round. If successful, that'll mean a lot less
involvement with the Beeb's iPlayer concession stand and its staff of
seemingly incompetent eejits.

--
Johnny B Good

get_iplayer 3.00 released
 

In article , Johnny B Good
wrote:
On Wed, 03 May 2017 13:32:03 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:
On Mon, 01 May 2017 17:13:48 +0100, Jim Lesurf wrote:




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'.




How would you or I determine how many people are using gip? I suspect
it remains a minority because getting it going is quite a geeky
process. But I don't know how we'd tell.


I wouldn't bank on them *not* knowing how much of their traffic is
serving request from gip users (or at least an equivalent downloading
utility that defeats the expiry functionality built into the official
iplayer media players or apps).

Erm. I was referring to your own comments *presuming* that :

"
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...

"

Also, don't forget the existence of the windows versions of gip which
has a much wider audience than the mac/*nix geek community, lest you
under-estimate the true size of a gip tooled up audience. Not *every*
gip user is a mac/linux/bsd geek. :-)

What raises my suspicions is the greater prevalence of 960 by 540
versions in place of the 1280 by 720 versions. There's always been an
element of randomness in the quality, not just between programme series
but between episodes within any one series.

FWIW I've found in the past that different versions tend sometimes to
appear over a few days. It seems to me a matter of how the people
generating the 'on demand' sources work. Not knowing when they take a
coffee break or forget something, the results can be hard to predict! :-)


Now that iPlayer has lost the plot with regard to 1280 by 720
availability,

I fetched some files this morning. So far as I an tell they were still the
type I've been getting in the past. FWIW I think I noticed on the gip list
a comment about 320k aac audio now being available as well. But I've not
yet checked this out. Could be handy for the proms! :-)

Jim

--
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
 

Jim Lesurf wrote:

I think I noticed on the gip list a comment about 320k aac audio now
being available as well. But I've not yet checked this out. Could be
handy for the proms!

Didn't the FLAC test page also mention the proms?

get_iplayer 3.00 released
 

En el artículo , Huge
escribió:

That's about it, I think.

A disappointingly short list.

--
(\_/)
(='.'=) "Between two evils, I always pick
(")_(") the one I never tried before." - Mae West

get_iplayer 3.00 released
 

In article , Andy Burns
wrote:
Jim Lesurf wrote:

I think I noticed on the gip list a comment about 320k aac audio now
being available as well. But I've not yet checked this out. Could be
handy for the proms!

Didn't the FLAC test page also mention the proms?

The history of this is confused as the original announcement of the 'trial'
said it would run for months. i.e. Over the period of the Proms. This was
altered once people at the BBC were asked about it, and the trial was then
reduced to 'weeks'.

Later on, a separate announcement was made that the Proms this year will
also be Flac streamed. But this is, apparently, *only* the Proms. i.e.
*not* everything on R3 during those weeks. Just the Proms.

I'm still waiting for clarification about when the stream will start/stop
for each individual Prom. I'm hoping it will start at least 5 - 10 mins
beforehand to give people scope to start listening before the actual Prom
and not miss anything.

Jim

--
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
 

In article , Johnny B Good
wrote:
After getting today's episodes in 1280 by 720, I had another go at
downloading yesterday's episodes. One of them completed the 1280 by 720
version download ok but the other one remains resolutely stuck in that
weird oddball 960 by 540 mode (and both had previously been downloaded
in the higher resolution early November last year).


The gip list is currently discussing hls mode 'missing segment' errors
which have been said to cause the fetch to abruply change to a lower
resolution. These seem to have started happening in the last few days.

IIRC there were missing segment problems in the past which then vanished
again once whoever was involved twigged and fixed the cause.

Jim

--
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 Thu, 04 May 2017 14:18:54 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:
After getting today's episodes in 1280 by 720, I had another go at
downloading yesterday's episodes. One of them completed the 1280 by 720
version download ok but the other one remains resolutely stuck in that
weird oddball 960 by 540 mode (and both had previously been downloaded
in the higher resolution early November last year).


The gip list is currently discussing hls mode 'missing segment' errors
which have been said to cause the fetch to abruply change to a lower
resolution. These seem to have started happening in the last few days.

IIRC there were missing segment problems in the past which then vanished
again once whoever was involved twigged and fixed the cause.

Roll on, the advent of a functioning DVB-T2 twin tuner!

Anyway, Jim, thanks for that information. :-)

--
Johnny B Good

get_iplayer 3.00 released
 

On Thu, 04 May 2017 19:48:48 +0000, Johnny B Good wrote:

On Thu, 04 May 2017 14:18:54 +0100, Jim Lesurf wrote:

In article , Johnny B Good
wrote:
After getting today's episodes in 1280 by 720, I had another go at
downloading yesterday's episodes. One of them completed the 1280 by
720 version download ok but the other one remains resolutely stuck in
that weird oddball 960 by 540 mode (and both had previously been
downloaded in the higher resolution early November last year).


The gip list is currently discussing hls mode 'missing segment' errors
which have been said to cause the fetch to abruply change to a lower
resolution. These seem to have started happening in the last few days.

IIRC there were missing segment problems in the past which then
vanished again once whoever was involved twigged and fixed the cause.

Roll on, the advent of a functioning DVB-T2 twin tuner!

Anyway, Jim, thanks for that information. :-)

Further to this issue of the missing segments, it does seem to be
getting worse. I've decided to copy and paste the programmes from the
search list that downgraded to 960 by 540 due to this problem so I can
more readily retry them on a daily basis. The fact that one of the two
afflicted Shaun the Sheep episodes downloaded in 1280 by 720 the
following day suggests it might be worth retrying these 'borked'
programme downloads until either I succeed or their time on the server
expires.

Oddly enough, I hit the same problem with "The Undiscovered Peter Cook"
programme which, after transferring to my temporary holding pen folder,
led to the discovery of an earlier broadcast from November last year
which I had converted into a 1.1GB mkv file from the .ts file download so
I was able to delete the low grade version I'd just downloaded this
morning. This serendipitous experience providing yet more proof that this
inexcusable situation is getting worse rather than better. :-(

--
Johnny B Good