SIOL (IPTV provider) managed to upset its customers once more

I have an IPTV provided by biggest national IPTV/IS provider. The current service is poor at best. We have FTTH (the slowest is 20Mb - that's awesome) but really lousy (~4Mb at best) MPEG2(!) encoded streams. The most obvious consequence of such encoding is pixelation when there is a faster change on the picture and poor quality in general. To make things worse there is a crappy, yet somewhat functional UI that lets you select channels and read EPG. It mostly works (except for occasional ASP.NET 1.1 server too busy error) and its speed is decent. IMO it mostly lacks two features:

  • one can't browse other channel's EPG (electronic program guide) without actually changing channel (IOW watch a channel and read other channel's EPG). I once asked SIOL about this and the response was: "Check out the teletext - you can't perform this stunt in teletext either". So much about understanding the technology progress.
  • one can't mark favorite shows and have an option of notification before the show

Now, both features are minor, yet SIOL isn't capable of implementing them. Since the UI is built around ASP.NET 1.1 (as seen on occasional errors) it shouldn't take more than a week to implement the two features. But they didn't change the UI for years now. Except for upgrading the progress icon to an animated gif.

Then, one day, they started a SIOL TV+ UI. (note the + char). It features a newly organized and richer UI, plus VOD and a recorder through UI (storage is provided on SIOL's server). Sounds great, right? Not at all. Here is the list of consequences:

  1. You have to buy a newer STB (or get one for free if you sign with SIOL for 2 years)
  2. UI is slow as hell. I mean really really slow at the point where it is unusable.
  3. UI is cluttered as hell - it is really bad and a total mess.
  4. It doesn't have favorite channels group.
  5. Recorder doesn't work and even when it will it will be useless: it is enabled only for a couple of Slovene channels (due to legal issues) and those shows will be persisted only for at most 2 days (the total place for storage per user is 6 hrs in total) . It won't be free as well since it uses SIOL's storage. There are other problems with recorder not listed but the question is why they bother at all with such crap service?
  6. VOD: after you pay for the movie you have 24 hours to watch it. The library is poor, at least the last time I've checked it.

True, I didn't check it lately. But for a reason. There were reports that lately people who checked out the new UI couldn't go back to the old, functional, one. The two UIs could coexist until recently.

And now, actually 10 days from now, SIOL is disabling the old UI for good and forcing everybody to new great new one - with or without the new STB. That's indeed a great move, kill the customer's will to watch TV, way to go! On the other side I'll watch less TV and spend more time with other activities I guess.

DirectX HLSL compiler chokes on unicode sources

In a week or so I've created two HLSL effects in two different .fx files. While they were really simple and straightforward, one of them failed to load at runtime in my managed DirectX 3D application (yet both worked in NVidia FX Composer). Why would one fail while another is working? The error information was really non existent (i.e. "there was an error in the application" - DirectX, thanks so much for all of the details...). So I tried the fxc compiler that comes with DirectX SDK. The problematic effect didn't compile, of course. This time the error was more verbose but highly misleading:

ID3DXEffectCompiler: There were no techniques

The problem with this message was that I had a technique defined (remember, the thing was working in FX Composer). Hm. Google didn't help me at all. Then I went with my standard problem solving approach (SPSA) - eliminate pieces step by step (take a working sample and modify it slowly step by step to pinpoint the problem). Ok, so I copied the working effect content into non-working file opened in editor (I did copy&paste of the code, not the file). I tried fxc again and to my surprise it yelled the same error at me. What? How could it be? The content was the same. Perhaps I've drank too much coffee today? So I used KDiff3, a file comparison tool (free), to compare both files. On opening it warned me that while the content is the same the binary content isn't. This info finally triggered my brains - it has to be the unicode signature prefix. To be sure I fired yet another free utility, this time a hex editor called HxD. And there is was a hex prefix of EF BB BF meaning an UTF-8 encoded text. We live in an unicode universe for a bunch of years now and I guess fxc should work with non-ASCII files as well. Or at least it should complain that file isn't an ASCII one.

Using extension methods to make code less cluttered

Here is an example where an extension method is useful. Take this [LGP] code for example:

public EntityCollection<CustomersEntity> GetCustomers() { using (DataAccessAdapter da = new DataAccessAdapter("Data Source=[SERVER];Initial Catalog=Northwind;Integrated Security=True")) { LinqMetaData context = new LinqMetaData(da); var q = from c in context.Customers select c; EntityCollection<CustomersEntity> result = ((ILLBLGenProQuery)q).Execute<EntityCollection<CustomersEntity>>(); return result; } }

It is a simple LINQ to LLBLGenPro select against (we all love) Northwind database. Pay attention at result assignment. To have data returned as a native [LGP] EntityCollection you have to resort to ILLBLGenProQuery interface. You have to use ILLBLGenProQuery.Execute method on IQueryable<T> q. A cast is obviously required because IQueryable<T> doesn't know anything about ILLBLGenProQuery. While this code works it is not exactly elegant - I am referring to the later cast of course.

So, the idea is to have something like this instead:

EntityCollection<CustomersEntity> result = q.Execute<EntityCollection<CustomersEntity>>();

Possible? Sure, just add this static class with a single extension method and you are good to go:

public static class Tubular { public static TResult Execute<TResult>(this IQueryable q) where TResult : IEntityCollection2 { return ((ILLBLGenProQuery)q).Execute<TResult>(); } }

Or perhaps, we can further reduce the cluttering by introducing this extension method:

public static class Tubular { public static EntityCollection<TEntity> Execute<TEntity>(this IQueryable q) where TEntity : EntityBase2, IEntity2 { return ((ILLBLGenProQuery)q).Execute<EntityCollection<TEntity>>(); } }

to achieve this, even less cluttered, line:

EntityCollection<CustomersEntity> result = q.Execute<CustomersEntity>();

Isn't this or former de-cluttered line more readable and more elegant than the original?