Posted: Tue Feb 24, 2009 4:09 pm Post subject: I found what was causing this for me (+PATCH)

I found that was causing this in my case (IVSm getting the guide from WiRNS). It turns out to be a bug in WiRNS, or more probably, in the .NET library.

Basically, the HTTP request IVSmagic was sending for the guide was causing the HTTP response from WiRNS to not use the chunked transfer encoding. However, the byte stream in the response contained extraneous <CR><LF> where the next chunk would have started.

This all looks OK, and supposedly isn't using chuked encoding. However, the guide snapshot that gets returned is corrupted. If I turn on the export_path option in IVSmagic, I find that the size of the snapshot returned is 113654 - 6 bytes too long.

If I make the same HTTP request without the X- headers, a slightly different response comes back:

This is a chunked response with the first chunk being 0x7ed3 (32467) bytes. After that many bytes, the next chunk is in the data stream:

Code:

^M
00007e66^M

which basically says how long the next chunk is. There's a CR-LF before and after the number, and these 12 bytes marking the chunk are not part of the data stream.

Comparing the raw HTTP response bodies (without removing the chunking), the problem is hinted at (I used diff on the output of hd; the first response is the non-chunked (bad) one, the second is the chunked one):

Right there in the first line of the bad response, you can see an extra 0d 0a. There end up being 3 of these - one for each place there would have been a chunk (each being about 32000 bytes), had the result been chunked.

This bug only happens when getting a guide from WiRNS (not from DVarchive or a real ReplayTV), so it doesn't cover anyone else's report of this.

It makes no sense that these X-* headers should have this affect on the HTTP responses put out from .NET. Any fix for it would have to be ini WiRNS (or in an update to .NET).

However, a workaround for IVSmagic is trivial: just comment-out the two lines adding these extraneous headers.