Re: episode oddity

[Alan Milewczyk]

On 11/08/16 08:01, Kenny Routledge wrote:

Hi

All of my HLSHD downloads are failing with

[http @ 05422e00] HTTP error 404 Not Found
[http @ 054232e0] HTTP error 404 Not Found

I've renamed the original saved file, downloaded again and the error message 
occurs in excactly the same point of download.

Can you let us have some PIDs you've been trying to download that give 
you an error message? What method are you using for download, CLI or PVR?



Alan


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

episode oddity

[Kenny Routledge]

Hi

All of my HLSHD downloads are failing with 

[http @ 05422e00] HTTP error 404 Not Found
[http @ 054232e0] HTTP error 404 Not Found

I've renamed the original saved file, downloaded again and the error message 
occurs in excactly the same point of download.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

extremely OT was Re: episode oddity

[artisticforge .]

hello

yes doctors are butchers and lawyers are bottom feeding scum sucking
savengers. Can we stick to the topic at hand, namely, get_iplayer and
gaps?

On Sat, Aug 6, 2016 at 12:22 AM, The Kernel  wrote:
> On 05/08/16 22:32, Alan Milewczyk wrote:
>>
>> the horrendous cocktail of medication
>
>

> OK if you need a broken leg fixing, but otherwise keep well away



-- 
terry l. ridder ><>

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[The Kernel]

On 05/08/16 22:32, Alan Milewczyk wrote:

the horrendous cocktail of medication


Dude, you know they are on the make big time by virtue of the medication 
they dish out!


Those quacks took 15 years trying to help me, until I finally decided to 
take things in to my own hands and go down the natural route


Now I'm in perfect health

OK if you need a broken leg fixing, but otherwise keep well away


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Alan Milewczyk]

On 05/08/16 05:27, Vangelis forthnet wrote:

On Wed Aug 3 21:52:46 BST 2016, Alan Milewczyk wrote:
but one thing puzzles me. For some time now, HLS has been my 
preferred method of fetching the programmes. I never got these error 
messages with v2.94

so is v2.95 reporting errors differently to previous versions?


Hello friend, I do hope your oral health has been restored and no more 
pain-relievers are needed...


Thanks Vangelis, unfortunately not. After three months of problems I'm 
still suffering on and off - the only thing that worked was Ibuprofen 
but that caused me internal bleeding, so I had to stop that option. The 
referral to the dental hospital finally took place today. I saw a 
consultant today who dismissed the previous theory of my pain being 
caused by a gum infection. He's passing me over to one of his colleagues 
who is a pain specialist in the next few days, so hopefully, there will 
be some light at the end of the tunnel soon. (Moral, don't get diabetes 
and coronary heart disease - diabetes screws your immune system and the 
horrendous cocktail of medication I take daily contributes to my dental 
problems.)


Anyway, back on-topic ...


I can't be verbose right now, but:
1. The error messages people get currently when fetching hlshd tvmode 
of some PIDs with 2.95 appears to be a beeb's glitch and I discussed 
some alternatives in another thread post.
2. In GiP 2.94, AppleHLS streams were dumped via FFmpeg; when 
something went awry, most of the messages (errors/warnings) were 
generated by ffmpeg itself.
In GiP 2.95, as explained many times, the recording is realised by 
default via a native ("built-in" the coder calls it) perl HLS 
downloader. Various HLS messages are now printed from that built-in 
downloader, so yes, "v2.95 IS reporting errors differently to previous 
versions." 


Ah that explains things perfectly, as always. Thank you. It's a pity 
that some things don't stay the same, but this is life For some 
time, I've been using HLS and recently been getting download speeds of 
between 30 and 100Mb/s but I switched back temporarily to Flash (until 
the HLS problems got sorted). Unfortunately this seems to be a quarter 
of the speed of HLS and I'm not prepared to live with such a speed 
degradation in the normal course of events! :-(


So tonight I decided to switch back to HLS but to log all the 
transactions to a text file - I can then go through this and for any 
downloads reporting an error, I'll repeat those using Flash on a 
one-by-one basis.


(For more, have a look at the code inside: 
https://github.com/get-iplayer/get_iplayer/commit/e2adee8 )




LOL, I think I'll pass on that. "Captain, I'm not a programmer, I'm an 
engineer", LOL.



Have a fine summer day, Vangelis.



Thanks :-) Have a superb weekend, dear friend.

Regards

Alan

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Vangelis forthnet]

On Wed Aug 3 21:52:46 BST 2016, Alan Milewczyk wrote: 

but one thing puzzles me. 
For some time now, HLS has been my preferred 
method of fetching the programmes. 
I never got these error messages with v2.94

so is v2.95 reporting errors differently to previous versions?


Hello friend, I do hope your oral health has been restored 
and no more pain-relievers are needed...


I can't be verbose right now, but: 

1. The error messages people get currently 
when fetching hlshd tvmode of some PIDs 
with 2.95 appears to be a beeb's glitch 
and I discussed some alternatives in another thread post.
2. In GiP 2.94, AppleHLS streams were 
dumped via FFmpeg; when something went awry, 
most of the messages (errors/warnings) 
were generated by ffmpeg itself.
In GiP 2.95, as explained many times, 
the recording is realised by default via a native 
("built-in" the coder calls it) perl HLS downloader. 
Various HLS messages are now printed 
from that built-in downloader, so yes, 
"v2.95 IS reporting errors differently to previous versions." 
(For more, have a look at the code inside: 
https://github.com/get-iplayer/get_iplayer/commit/e2adee8 )


Have a fine summer day, 
Vangelis.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Vangelis forthnet]

On Wed Aug 3 15:54:50 BST 2016, Jim web wrote:


I'm currently using the linux gip (Jan develop version 2.95)
Should the current release version accept the same options?
I'll get it and give it a try, but am wondering
if I'll need to change the way I specify getting the
best hdtv via hls.


Hello Jim and other list company :-)
Back after a short trip, I am now catching up
on list threads - heatwave isn't helping, though :-(

Jim please, if you come here seeking for help,
at least (as you said you are planning to) migrate
to the latest released version of GiP, i.e. 2.95 final,
so we can compare like for like...
"(Jan develop version 2.95)" is as vague as it can ever get!

If you browse the develop repo,
https://github.com/get-iplayer/get_iplayer/commits/develop/get_iplayer?page=4
https://github.com/get-iplayer/get_iplayer/commits/develop/get_iplayer?page=3
https://github.com/get-iplayer/get_iplayer/commits/develop/get_iplayer?page=2
you'll find that no less than fourty one (41) different
commits for the main script were pushed to that repo
on the month of January 2016, so it's practically
impossible for us to tell which specific January 2016
2.95dev snapshot you are on currently!

Develop snapshots are unsupported, but if you or
anybody else is willing to try them, here is a tip:

1.Always visit the develop repo first:
https://github.com/get-iplayer/get_iplayer/commits/develop
2. Note down commit hash of latest snapshot.
At the time of writing, it is "782f04a" and this belongs
to a 2.96dev snapshot.
3. The following URI will always fetch latest dev snapshot:
Latest get_iplayer-dev (main perl script)

https://raw.github.com/get-iplayer/get_iplayer/develop/get_iplayer

I would save this (on Windows) as

get_iplayer-296dev-g782f04a.pl

so I already have an indication of its identity.
But should you use it to replace your original script,
then open it up in an editor and search for

my $version_text = "2.96-dev";

Edit this to

my $version_text = "2.96dev-g782f04a";

or similar; that way, whenever your dev
snapshot is run, you can easily tell its "version"
in time because it's printed out in the Command
Prompt.
(The above was mainly geared for Win users;
I realise Jon Davies is maintaining a separate
PPA for the develop version, I suspect if you
installed from that you can easily tell its git-version...)

A plethora of further commits/changes were
pushed to the 2.95dev repo since Jan 2016,
all these ended up in final 2.95 and have significantly
changed the behaviour you are currently
experiencing in your "Jan 2.95dev" version.

After you have upgraded to 2.95-final,
have a thorough read (and re-read) of the
Release Notes
https://github.com/get-iplayer/get_iplayer/wiki/release295
and the FAQs
https://github.com/get-iplayer/get_iplayer/wiki/faq
(the FAQs are being constantly revised, so do
bookmark them for future re-visits!)

While those links already contain all the answers
to your questions, in relation to what concerns you
the most:
1. "--type=tv" needs not be specified, as the tv.cache
is searched by default.
2. "--type=radio" can be omitted in 2.95, but in reality shouldn't...
3. HLS (tv|radio) modes are now the DEFAULT -
this change was brought on by
https://github.com/get-iplayer/get_iplayer/commit/673793a
in Feb 2016, so not present in your 295dev snapshot!

With 2.95-release, YOU DON'T HAVE TO SPECIFY
--modes=hlshd ; this is now the default.
(NB --tvmode & --modes are valid, --mode is not,
according to longhelp).

In your 2.95dev snapshot,
--modes=best
would fetch the flashhd tvmode (the default then).
To specifically request flashhd in 2.95-release, issue:
--modes=flashhd

On Thu Aug 4 10:22:29 BST 2016, Jim web wrote:


The problem for me with the alternative fetching method
(which here only states it is RTMPDump, but that may be a mislabel)
is rather slower than HLS. This is an minor irritant,


The "alternative fetching method" is, as explained already,
the downloading of the RTMP stream (via the RTMPdump
helper utility, I'm sure you already know it) that corresponds
to the FLASHHD tvmode.
Do not compare downloading speeds between the two,
it's a clear case of apples vs oranges.
1. Different protocols (rtmp vs http)
2. Different streaming method (HLS uses file segmentation)
3. Different CDNs, many miles apart possibly.
4. Add to the above all sorts of random factors
that may control DL speeds, as I recall I discussed
in a previous thread of yours earlier in the year
(where you were comparing DASH to HLS).


However it seems clear there *is* an 'intermittent' problem of some kind.


The issue that started this thread (and possibly
related to the report made at
http://lists.infradead.org/pipermail/get_iplayer/2016-July/009264.html )
appears to be attributed to a glitch
at the Akamai CDN server hosting/serving the HLSHD tvmode
(1280x720p, ~ 2400kbps, 25FPS) of iPlayer TV programmes.
It has manifested itself the last 4-5 days and is more
pronounced on new/recent iPlayer additions.
Over time, some 

Re: episode oddity

[Alan Milewczyk]

On 04/08/16 07:50, Shevek wrote:

On 4 August 2016 at 07:16, The Kernel  wrote:

On 03/08/16 20:12, Shevek wrote:

If I then retry using FLASHHD the download completes without error.


Just to say

If you are working from a connection that would have trouble with HD

I tried flashstd and it too works without error



I have 30MB fibre so HD is never an issue for me. It has only happened
on 2 out many.

Hmm, I have 200Mb fibre which is extremely reliable and can easily cope 
with HD but since switching to v2.95 I'm now getting problems with some 
of the programmes, which wasn't happening before. I'll try the FLASHHD 
option later to see if that sorts the problem for me as it seems to have 
done for a number of contributors on here.


A

A

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Jim web]

In article , The
Kernel  wrote:
> On 03/08/16 20:12, Shevek wrote:
> > If I then retry using FLASHHD the download completes without error.

> Just to say

> If you are working from a connection that would have trouble with HD

> I tried flashstd and it too works without error

More specifically, you may mean, "It worked for me on that occasion,
without error".

However it seems clear there *is* an 'intermittent' problem of some kind.
Alas, as any repairman knows, intermittent problems can be the hardest to
diagnose and fix.

Once again this morning I tried fetching the last episode in the "Saving
lives at sea" series. This halted early at about 40m duration when fetched
using hls.

However the alternative method described in my earlier postings then duly
worked OK.

Indeed, this gave me about 1h 15mins! There seems to be an 'bonus' item
about the RNLI people added on at the end, following a blank gap of some
seconds after the end credits of the actual broadcast. I didn't see the
live over-air TX so wonder if this was aired or is meant to be a 'bonus'
file which might have been planned to be obtainable from iplayer.

What I can't tell, of course, is if the problems are down the something the
BBC are doing that is 'wrong', or if some rare aspect of the system is
catching out hls fetching with gip. But either way, it now seems clear that
something is going wrong on some occasions.

The problem for me with the alternative fetching method (which here only
states it is RTMPDump, but that may be a mislabel) is rather slower than
HLS. This is an minor irritant, but nevertheless, something somewhere isn't
always working as it should.

Jim

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Shevek]

On 4 August 2016 at 02:50, artisticforge .  wrote:
> hello
>
> i would note that the Warning:
> 
>> "WARNING: Segment not found (xxx)"
>> "WARNING: There may be a gap near yyy secs in programme"
> 
>
> Indicates that there "MAY BE A GAP", the operative word being "MAY"
> it is not saying that there is definitely a gap.
> given the wording of the warning message, it would seem that one would
> have to view the program in its entirety to determine if such a gap does in
> fact exist.
>
>

Yes, however, I process all my files with a self-built tool which
checks them using MediaInfo and this is reporting an FPS mismatch for
these files. When I re-download them using FLASHHD the tool passes
them, as it does with other HLSHD files.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[The Kernel]

On 03/08/16 20:12, Shevek wrote:

If I then retry using FLASHHD the download completes without error.


Just to say

If you are working from a connection that would have trouble with HD

I tried flashstd and it too works without error


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[The Kernel]

On 03/08/16 20:12, Shevek wrote:

On 3 August 2016 at 17:27, Jim web  wrote:

In this case it isn't a problem I recall encountering before. Yet it has
now happened many times in the space of a few days. So the simplest answer
may be that something has actually changed. The question then being, what?


I am seeing similar here

It has happened with 2 different programs in the last week - initial
downloads via HLSHD result in broken files and if I retry I see 2
errors, repeated:

"WARNING: Segment not found (xxx)"
"WARNING: There may be a gap near yyy secs in programme"

If I then retry using FLASHHD the download completes without error.

So, it appears that the beeb's HLS encoding/streaming is producing
corrupt files.

I just retried one that failed this morning (The Living and the Dead -
Episode 6, BBC One, p03wv7v0) and I am still getting the errors - one
at 27.7% (Segment 93, 920 secs) and another at 64.6% (Segment 214,
2130 secs)

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer


And for me to


eg


WARNING: Segment not found (132) 
http://cp401489-vh.akamaihd.net/i/iplayerstream/secure_auth/,800kbps/modav/bUnknown-a19c3df7-9e81-4591-9694-c09d952a5a66_b07n2wbg_1469376289050,1500kbps/modav/bUnknown-a19c3df7-9e81-4591-9694-c09d952a5a66_b07n2wbg_1469378577114,3200kbps/modav/bUnknown-a19c3df7-9e81-4591-9694-c09d952a5a66_b07n2wbg_1469378574430,.mp4.csmil/segment132_2_av.ts

WARNING: There may be a gap near 1310 secs in programme


That's just using the pid=



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[artisticforge .]

hello

i would note that the Warning:

> "WARNING: Segment not found (xxx)"
> "WARNING: There may be a gap near yyy secs in programme"


Indicates that there "MAY BE A GAP", the operative word being "MAY"
it is not saying that there is definitely a gap.
given the wording of the warning message, it would seem that one would
have to view the program in its entirety to determine if such a gap does in
fact exist.





On Wed, Aug 3, 2016 at 2:12 PM, Shevek  wrote:
> On 3 August 2016 at 17:27, Jim web  wrote:
>>
>> In this case it isn't a problem I recall encountering before. Yet it has
>> now happened many times in the space of a few days. So the simplest answer
>> may be that something has actually changed. The question then being, what?
>>
>
> I am seeing similar here
>
> It has happened with 2 different programs in the last week - initial
> downloads via HLSHD result in broken files and if I retry I see 2
> errors, repeated:
>
> "WARNING: Segment not found (xxx)"
> "WARNING: There may be a gap near yyy secs in programme"
>
> If I then retry using FLASHHD the download completes without error.
>
> So, it appears that the beeb's HLS encoding/streaming is producing
> corrupt files.
>
> I just retried one that failed this morning (The Living and the Dead -
> Episode 6, BBC One, p03wv7v0) and I am still getting the errors - one
> at 27.7% (Segment 93, 920 secs) and another at 64.6% (Segment 214,
> 2130 secs)
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer



-- 
terry l. ridder ><>

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Jon Davies]

On 3 August 2016 at 20:12, Shevek  wrote:
> [...]
> "WARNING: Segment not found (xxx)"
> "WARNING: There may be a gap near yyy secs in programme"
>
> If I then retry using FLASHHD the download completes without error.
>
> So, it appears that the beeb's HLS encoding/streaming is producing
> corrupt files.
> [...]

I was just listening to some radio on my iPad using the BBC Radio app,
which I believe downloads/streams hls behind the scenes.  This skipped
in a couple of places, and got stuck in a loop somewhere else.  I'm on
the end of a rock-solid fibre connection with oodles of bandwidth, so
I'm content that it's not a sticky internet connection.

So if the beeb's own applications can't get a solid programme without
gaps and errors, get-iplayer won't be able to either.

Jon

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Alan Milewczyk]

On 03/08/16 20:12, Shevek wrote:

On 3 August 2016 at 17:27, Jim web  wrote:

In this case it isn't a problem I recall encountering before. Yet it has
now happened many times in the space of a few days. So the simplest answer
may be that something has actually changed. The question then being, what?


I am seeing similar here

It has happened with 2 different programs in the last week - initial
downloads via HLSHD result in broken files and if I retry I see 2
errors, repeated:



So, it appears that the beeb's HLS encoding/streaming is producing
corrupt files.


I'm having the same experience here, but one thing puzzles me. For some 
time now, HLS has been my preferred method of fetching the programmes. I 
never got these error messages with v2.94 so is v2.95 reporting errors 
differently to previous versions?


A

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[artisticforge .]

hello

I run into premature terminations several times a week. I chalk them
up to 'Internet Hiccups'. Restart and everything is fine.

Remember Occam's Razor:
"Among competing hypotheses, the one with the fewest assumptions
should be selected." or paraphrased: "The simplest answer is normally
the correct answer." or "The simplest answer is normally the best
answer."

"Hiccups" explain many things. ;-)



On Wed, Aug 3, 2016 at 9:54 AM, Jim web  wrote:
> I encountered this problem again this morning. This time for two programmes
> with the pids b0085b0s and b07n2hmt. As before my usual hls fetch method
> ended prematurely without gip reporting any actual errors. But using
>
> --type=tv --mode=best
>
> then worked for both. Albeit rather more slowly than my using method.
>
> I'm currently using the linux gip (Jan develop version 2.95) Should the
> current release version accept the same options? I'll get it and give it a
> try, but am wondering if I'll need to change the way I specify getting the
> best hdtv via hls.
>
> Jim
>
> --
> Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
> Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
> Audio Misc  http://www.audiomisc.co.uk/index.html
>
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer



-- 
terry l. ridder ><>

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Jim web]

I encountered this problem again this morning. This time for two programmes
with the pids b0085b0s and b07n2hmt. As before my usual hls fetch method
ended prematurely without gip reporting any actual errors. But using 

--type=tv --mode=best

then worked for both. Albeit rather more slowly than my using method.

I'm currently using the linux gip (Jan develop version 2.95) Should the
current release version accept the same options? I'll get it and give it a
try, but am wondering if I'll need to change the way I specify getting the
best hdtv via hls.

Jim

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[RS]

From: Jim web
Sent: Thursday, July 28, 2016 12:12 PM


I'd tried twice on the morning after the broadcast. Then a couple of times
on later days. Got the same "halt after about 2 mins".



I tried again using the same method yesterday after seeing  a reply here.
Still stopped. I then tried the



--type=tv --mode=best



and this worked OK. This method mentioned RTMPDump but I guess it wasn't
RTMP as I thought that had ceased (?)


That's interesting.  I have --tvmode best in my preferences and I 
used --type tv on the command line, although I gather both are now defaults. 
As I have said previously, that caused a HLSHD download, which ran to 
completion but for the missing segment 13.  After a few days I gave up with 
HLSHD and then used --tvmode flashhd and that downloaded completely using 
rtmpdump but it may be it would have failed if I had tried it sooner.


The difference between us seems to be I used --tvmode and you used --mode, 
which includes --radiomode.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[Jim web]

I'd tried twice on the morning after the broadcast. Then a couple of times
on later days. Got the same "halt after about 2 mins".

I tried again using the same method yesterday after seeing  a reply here.
Still stopped. I then tried the

--type=tv --mode=best

and this worked OK. This method mentioned RTMPDump but I guess it wasn't
RTMP as I thought that had ceased (?)

However I now have the programme OK, but remain baffled by the behaviour
when using --tvmode=hlsbest!

Other programs have continued to fetch OK using my normal method.

Jim

In article <24f3383c-81f0-bd6e-f59c-e73ab84df...@googlemail.com>, Alan
Milewczyk  wrote:

> Yes I had the same problem with the episode you mention when it was
> aired a week or so back, stopping at 2m21secs. All I know is that when I
> discovered the truncated download the following day and forced another
> download, everything was fine that time. That was on my main PC using
> Windows 7 x64 GIP v2.94 (modes=hlshd). I've just repeated the process on
> the same PC without problem.

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: episode oddity

[artisticforge .]

hello

downloaded fine here.

I use
../get_iplayer-2.96-dev/get_iplayer --type=tv --mode=best --pid=

on devuan linux.

On Wed, Jul 27, 2016 at 9:50 AM, Jim Lesurf  wrote:
> I've been fetching and watching the recent 'Forces of Nature' BBC1 TV
> series presented by Brian Cox. There are four episodes and I've had no
> problem getting episodes 1, 2, and 4. But episode 3 seems different for
> some reason.
>
> For now, I've continued using a development version from Jan of 2.95 as it
> has otherwise worked fine. I fetch individual programmes with the
>
> --tvmode=hlsbest  and -- pid=
>
> settings. However for episode 3 (pid = b07l1zvw) the fetch always halts at
> about 2 mins from the start.
>
> Anyone else had this problem or knows how to to fix it?
>
> Jim
>
> --
> Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
> Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
> Audio Misc  http://www.audiomisc.co.uk/index.html
>
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer



-- 
terry l. ridder ><>

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

episode oddity

[Jim Lesurf]

I've been fetching and watching the recent 'Forces of Nature' BBC1 TV
series presented by Brian Cox. There are four episodes and I've had no
problem getting episodes 1, 2, and 4. But episode 3 seems different for
some reason.

For now, I've continued using a development version from Jan of 2.95 as it
has otherwise worked fine. I fetch individual programmes with the

--tvmode=hlsbest  and -- pid=

settings. However for episode 3 (pid = b07l1zvw) the fetch always halts at
about 2 mins from the start.

Anyone else had this problem or knows how to to fix it?

Jim

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer