DLNA in the real world

In my very first post of 2007 I talked about the promise of DLNA and that with compliant devices you could enjoy freedom to consume your digital media wherever or however you wanted. Unfortunately, as I have experienced first hand, the reality is far from the convenient ideal that DLNA professes to provide.

I currently have a Linksys Media Hub NMH410 and a Sony Bravia 32V5500 television connected to my network. Both are DLNA-compliant devices and support streaming pictures, audio and video over the network. The Media Hub runs Twonky Media Server which, to all intents and purposes, is the reference implementation of a DLNA server. The Bravia has a DLNA compatible renderer, similar to the PS3 which can also stream content over a network.

The trouble is that, while I can view photos from the Media Hub on the TV fine, both audio and video fail to work. I can browse audio files on the Media Hub however only the first 20 seconds of each file will play and after that I get a "Playback not available" error. Video files on the other hand are a non-starter and can't be browsed or played.

I suspected my network or the format of files I was trying to stream may have been to blame but after a (lengthy) process of elimination I took both out of the equation. Installing Twonky Media Manager on my PC, which acts as both a server and client, I was able to stream all the content types off the Media Hub fine and was also able to stream content to the TV fine. It was just the particular version of Twonky on the Media Hub and the renderer in the TV that didn't like each other.

Threads on a fair few forums across the net show that lots of folk are experiencing the same issues:

• Playback not available on Sony KDL-37V5500 on Linksys' forum
• KDL40W5500 and NAS on AVForums
• Sony Bravia TVs and Twonky on NAS not working together on Twonky's forum

I found this all very odd as surely the DLNA badge on both devices ensures that they're compatible and will have no trouble in streaming the content. This is apparently not the case and Sony themselves confirmed this to me by e-mail saying:

Unfortunately the KDL-32V5500 Media compatibility results with DLNA Media servers are as follows for Twonky Media 1.0.0.115 you can play back JPG formats. This information is the result of tests performed in Sony laboratories.

In other words their DLNA-compliance for that particular server only extends to pictures. Quite how they can call this compliance I don't know but luckily they have a nice get out clause:

Unfortunately the Twonky Media software versions you are currently using are not guaranteed to work, as third party software developers are susceptible to modify the features of their software.

So basically, "even though we're DLNA-compliant and you're using a DLNA-compliant server we give you no guarantees they'll work together whatsoever". If this is the way companies behave with their DLNA certification, if they can just get around any non-compliance issues by saying "it's the other guy's problem" then one really does wonder what the point of DLNA is.

SQL Server Error Severity and .NET

I actually wrote this almost a year ago but forgot to post it.

The other day I noticed some oddness in the Messages window of SQL Server Management Studio when using RAISERROR with different error severities. Running the following:

PRINT 'Start.'
RAISERROR (N'Error.', 16, 1)
PRINT 'End.'

produces...

Start.
Msg 50000, Level 16, State 1, Line 2
Error.
End.

However if you increase the severity to 17 or 18 you get this...

Start.
End.
Msg 50000, Level 18, State 1, Line 2
Error.

Odd as the error message has now moved from between the "Start" and "End" to after the "End". Wondering what the significance of the change from severity 16 to 17 was and why Management Studio should treat them differently I headed over to SQL Server Books Online which says:

• 0-10 are informational messages
• 11-16 are errors that can be corrected by the user
• 17-19 are application errors that the user can't correct
• 20 and above are fatal errors

So there is a difference but that still doesn't explain Management Studio's behaviour. Management Studio uses the .NET SqlClient for running queries so a brief look at the docs shows the SqlConnection class has a FireInfoMessageEventOnUserErrors property which, when set to true, reports any errors of severity less than 17 to the InfoMessage handler rather than throwing a SqlException.

I've put together a quick Snippet Compiler script to test this out which you can download here. The script has a connection string at the top which is looking for a local SQL Express instance with integrated security by default so you may need to amend this.

Results

Queries 3 and 4

These two queries show the differences observed in Management Studio quite nicely with the InfoMessage handler being fired for the severity 16 error but a SqlException being thrown for the severity 18.

-------------------------------------
Executing Query 3:


PRINT 'Start.'
RAISERROR (N'Error.', 16, 1)
PRINT 'End.'


Messages:

Info message fired: Start.
Info message fired: Error.
Info message fired: End.


Result:
Success.
-------------------------------------
Executing Query 4:


PRINT 'Start.'
RAISERROR (N'Error.', 18, 1)
PRINT 'End.'


Messages:

Info message fired: Start.
Info message fired: End.


Result:
SqlException.
Error severity: 18
Message: Error.
-------------------------------------

Query 5

Query 5 causing a severity 20 error (a fatal error) displays some slightly different behaviour as it both fires the InfoMessage handler and throws a SqlException.

-------------------------------------
Executing Query 5:


PRINT 'Start.'
RAISERROR (N'Error.', 20, 1) WITH LOG
PRINT 'End.'


Messages:

Info message fired: Start.
Info message fired: Process ID 51 has raised user error 50000, severity 20. SQL
Server is terminating this process.


Result:
SqlException.
Error severity: 20
Message: Error.
A severe error occurred on the current command.  The results, if any, should be
discarded.
-------------------------------------

Queries 6, 7 and 8

These show how the RAISERROR interacts with a SQL TRY...CATCH block. The RAISERROR within the TRY block only fires the InfoMessage handler in the severity 20 case with the RAISERROR in the CATCH block only firing the handler in the severity 16 case.

Conclusion

It seems like you could build in some quite nice fine grain logging into your SQL statements, stored procs etc by using hooking up a SqlConnection InfoMessage handler and setting FireInfoMessageEventOnUserErrors to true. What's more is that you could write this information out to your application's log file along with the Debug or Trace calls from your code. Considering in some cases you may have quite a lot of logic in a stored procedure especially it may turn out to be really helpful having all your debugging information in one place.

Windows Update KB977165 causes BSoD

Had fun and games with Kath's laptop last night as it had mysteriously started blue screening with a PAGE_FAULT_IN_NONPAGED_AREA error on startup. Safe mode was also affected with the boot getting as far as mup.sys and then failing.

She's running Windows XP dual-boot on a MacBook however OS X was unaffected so a hardware issue seemed unlikely. I suspected a recent Windows Update may be to blame although I've never come across such a severe failure resulting from an update before.

After a quick Google search (using Safari) I found this thread on the Microsoft forums entitled "BLUE SCREEN, UNABLE TO BOOT AFTER WINDOWS XP UPDATE TODAY". The thread currently has 336 replies and 132,262 views so it's a fair bet a lot of people's machines have been affected.

Reading the replies to the post it seems only XP and Vista are affected with the BSoD although the patch applied to all recent versions of Windows. Some replies speculate that it may be down to a previous virus infection which Kath's laptop has had so this could well be the case.

The culprit is one of Tuesday 9th February's Windows Updates, KB977165, and you need to boot into Recovery Console using an XP CD and run some commands in order to uninstall it - full details are in Kevin Hau's answer in the thread.

That's fine for people with an XP CD but pre-installed shop-bought PCs don't normally come with one and Netbooks don't even have a CD drive. Anyone without access to an XP CD will have to either buy a copy or consider upgrading to Windows 7. I suppose any bad publicity Microsoft may get from this won't concern them as they'll be busy watching their Win 7 uptake figures get a healthy bump this month. Of course, maybe people will decide to go with OS X or Ubuntu instead.

Links

• MS update gives some XP boxes the Blue Screen
  The Register
• Windows patch cripples XP with blue screen, users claim
  Computerworld