I just found this petition aiming to get EPG data for Australia. Go sign up if you're interested in any form of PVR type service in AU.

While preparing for the first tutorial in the new web services subject that I'm tutoring I came across the following exception: "Request format is unrecognized for URL unexpectedly ending in '/ConvertTemperature'". Unfortunately Google failed me so I decided I'd post the fix I found.

Simply changing the address from "http://localhost/..." to "http://127.0.0.1/..." fixed it right up. I haven't bothered searching for the exact cause of the problem, for a change I'm happy enough with just finding a solution. I do remember coming up against a very similar problem recently so perhaps one day I'll get around to explaining this fully. In the meantime this is an adequate solution.

So next time you get the error "Request format is unrecognized for URL unexpectedly ending in '/???'" while developing asmx web services in ASP.NET 2.0 try this as a solution.

I've slowly been continuing development on my BDA library (see Introduction To Scanning DVB-T Digital TV). Recently I've been working on getting program guide data from the Event Information Table (EIT). In directshow all of these MPEG-2 data tables are provided through the IMpeg2Data interface of the MPEG-2 Sections and Tables filter.

There's 3 methods that provide data GetTable, GetSections and GetStreamOfSections. Originally I was using GetTable and all was working fine, though I did notice I was getting some strange data through which I assumed was just part of the actual broadcasted data. I wanted to move over to using GetStreamOfSections as it provides a more asynchronous approach.

After some playing I got GetStreamOfSections working in .NET and suddenly discovered that the quality of my data suddenly improved. That strange data that I'd assumed was in the broadcast disappeared. This was excellent! Unfortunately I soon discovered that GetStreamOfSections seemed to break when the graph was retuned to a new frequency. I'll try to blog soon about that issue and what I did about it. For the moment all you need to know is that I ended up returning to the synchronous methods.

When I returned to using GetSection (I still don't really know the difference between GetTable and GetSection as they seem to return very similar data) I decided I would try to get to the bottom of the strange data issue. After stepping through the methods that parsed the MPEG-2 tables I discovered the length field being read from the data was significantly more than the length of data actually read. This explained the strange data - I was reading past the end of the data - but why was this wrong when it had been correct in the GetStreamOfSections case? A quick glance at the two values quickly showed that the byte order of the field read was incorrect!

Bingo! This would fix all my problems in one swoop.

But unfortunately further investigation discovered that it actually depended on which table I was reading as to whether the field was in the correct order or not! And furthermore sometimes the field and the data length supplied to me had no relation at all.

So unfortunately, that is where I'm at. I have guide data reading correctly. I have channel scanning working. But the data is still not reading 100% unless I use GetStreamOfSections which has its own issues (see non-existant future blog post for details). If anybody has any idea why this would be I'd love to hear it.