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