HD content still unavailable

[David Woodhouse]

On Thu, 2010-11-04 at 01:54 +0000, Kris LeC wrote:
> 
> Sure, here it is: http://paste2.org/p/1071011

The important part of that is:

DEBUG: SWFSHA256:
DEBUG: c4 e8 99 6c 5f 69 1a 32 3a 36 23 ed 07 9c 72 67
DEBUG: 98 eb 24 9c 95 d6 7a 6f f6 73 29 d1 6c b1 bc 2a
DEBUG: SWFSize  : 1020525

That's wrong. The SHA256 and size of the current player SWF are what I
posted to the list on October 19th:

DEBUG: SWFSHA256:
DEBUG: 75 6e f5 b1 b3 3f 59 e8 86 80 ba 06 bc bc 96 7e
DEBUG: 34 46 8c 82 11 9d f9 e3 78 99 65 51 3e 7e 57 f5
DEBUG: SWFSize  : 1023131

Your .swfinfo file should look something like this:

url: http://www.bbc.co.uk/emp/10player.swf
ctim: Thu, 04 Nov 2010 02:12:46 GMT
date: Mon, 05 Jul 2010 14:58:49 GMT
size: 000f9c9b
hash: 756ef5b1b33f59e88680ba06bcbc967e34468c82119df9e3789965513e7e57f5

This is an rtmpdump bug. It's too aggressive in its caching --
especially given that the URL in question has actually _changed_ (from
http://www.bbc.co.uk/emp/10player.swf?revision=18269_19216 to
http://www.bbc.co.uk/emp/10player.swf?revision=18269_21576 )

It's not as if it'd be hard to store the ETag and *check* if the file
has changed since the information was cached.

You need to find where it's storing this out-of-date information on your
operating system, and remove it.

-- 
dwmw2