iplayer change or...

[Jim Lesurf]

In the last couple of days I've experienced some change in the behaviour of
gip when fetching HDTV. I'm not sure why it is happening or what to do.

For some time I've been fetching TV items OK using a simple 'C'  program
that lets me choose the gip options  and run a fetch for a pid. This then
reads a text file listing what I want, and the fetching options for each
item.

The default HDTV options I have are:

--tvmode=best --no-tag --pid <pid> --output <output location>

for my 't' option set and

--tvmode=best --no-tag --exclude-supplier=akamai --pid <pid> --output
<output location>

for my 'x' option set.

Until Tuesday morning I'd been routinely using the 'x' options because I
kept finding that the 't' options tended to stall or fail in various way.
Avoiding akamai seemed to deal with this. Perhaps a clear sign that the two
user-facing machines are *not* the same!

On Tuesday morning I found that nearly all the TV programs fetched were
832x468, not 1280x720. Even when they were marked as 'HD' in the Radio
Times and were in a series where earlier examples *were* 1280x720.

So spent some time yesterday experimenting. The overall result was that
although failing to exclude akamai tended to fail (more details below) it
often showed what it was getting as 1280x720 whereas excluding akamai
showed items as being 832x468. Sometimes 't' did run OK. But yesterday I
was mindful of my DSP 'cap' so ctrl-C'd after amd checked the result to
confirm that it was, indeed, 1280x720 whilst 'x' kept finding 832x468.

This morning the pattern was similar, but 't' failed time after time. I
tried it at about 7am, and a few times after that. Finally at 8:45am it
started to work OK. Here is the test text list I was running to help make
sense of what follows:

t b01q04ry
t b069gxy7
t b06b7k4z
t b05n8f3n
t b069g53h
t p0109jny
t b00z6zc7

These programs were all transmitted on Monday.

Running though them, the first items failed and I ctrl-C'd on down the
list, until at about 8:45 I got to 't b05n8f3n'. This chose flashhd1 mode
and fetched 1280x720 with no problems.  Both 't b069g53h' and 't p0109jny'
also worked fine and gave 1280x720. Then 't b00z6zc7' stalled at 0% fetch.
It was showing the item as being 1280x720 but simply stalled before getting
anything. (Note the ' signs above are there just to show the lines in this
report.)

Using 'x' the programs still show up as 832x468.

The failures vary in how they present. From previous tries using 't' I can
indicate the behaviour:

b01q04ry => flashhd1 but immediately stalls showing 343% fetched! Nothing
actually fetched.

b05n8f3n => flashvhigh1 then
Handle Invoke sanity failed no string method in invoke packet

p0109jny => flashhd1 RTMP_ReadPacket failed to read rtmp packet body

b00z6zc7 => flashhd1 sanity fail

My impression is that the apparent error reports are so random that they
are just surface signs of a more basic problem. My ignorant guess is that
packets are arriving too fast in too irregular an order, and something
somewhere is being confused because it can't keep up with sorting out the
flow into proper order.

That the 't' option worked for a while looked to me like the connection was
now 'slow enough'. as others had started to make use of the net.

I have in the past found that the 't' option was more likely to work during
the day than the early morning. But was slower *and* counted toward my DSP
cap, so I prefer getting items before 9am.

FWIW I have a nominally 70meg connection and when all is well, at about 7-8
am I have no trouble fetching HDTV items at about x10 'real time' - at
least using the 'x' option. I'm also using a fairly fast machine with a
wired network. Normally I can easily do things like fetch one program
whilst watching another and the CPU use still seems low.

Having said all the above I realised this morning that I'm still using gip
2.93 as the changed for 2.94 didn't seem relevant to me when they were
made. So I'll get 2.94 today and give it a try when I can in case this is a
problem with 2.93. But I'll send this report in case anyone else can
diagnose the problem, etc.

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