I've just received an Asus Eee-Box which I've had on pre-order for the last few weeks.
One word: Wow!
This thing is amazing - it's size has to be seen to be believed, especially the thickness, and I love that it comes with a Vesa mounting bracket so you can attach it to the back of your monitor for storage!
I ran it up last night, and it works exactly as expected. It comes with WinXP Home by default and I'm as yet undecided whether I should replace that with Ubuntu, however seeing as the Windows licence has already been paid, there's less of an argument.
It took only 15 minutes for me to get my TV software installed and immediately I was watching streamed TV from the server. I opened the TV Guide and could see all the programmes. All that client-server work seems to have paid off!
There were three areas I was concerned about before buying this device:
1) Did it have a powerful enough graphics card to display high resolution widescreen on an LCD TV?
2) Was the Atom processor enough to play back a minimum of 720p HD?
3) How quiet was it? Would it be noticeable in a lounge type environment?
All, I'm happy to report, work perfectly. The graphics chip is one pinched from a laptop as far as I can see, and it can produce 1280x1024 without a problem, probably more (although my monitors don't support higher as yet!)
The Atom has been a very pleasant surprise. It out-performs my old AMD 1.5Ghz PC with no issues, and plays back 720p smoothly. I've not tried it with 1080p yet, but I will do and will report back. No doubt the graphics card has something to do with this.
In terms of the noise level, it's extremely hard to hear it at all. Yes there is a fan, but unless you're within 2 feet with no other noise in the room, you can't hear it.
Overall from my first hours with this PC, I'm hugely impressed, especially what it can do for the price - just £200.
I'm going to get another one shortly for another room so that any TV/Music/Video/Web/Email can be tapped into anywhere in the house.
Finally I'm realising the vision I've had for so long now, an affordable networked home.
Tuesday, 21 October 2008
Tuesday, 26 August 2008
RTFM
I've been battling with MediaPortal TV Server over the last few weeks. I have been creating a new TV server machine, and wanted to get it as "clean" as possible by installing from scratch.
I initially thought it was a good idea to get Windows up to date as much as possible, then install applications. This usually results in a stable system. In addition, I took partition backups throughout the process so that if something went wrong, I could restore to a clean position.
PING
I realised that there's no need to buy a tool such as Norton Ghost any more as there are plenty of solutions available for free (which use Linux under the hood). One such example is PING which conveniently comes as a tiny bootable ISO cd image - allowing you to use it without affecting your filesystem.
It backs up a partition using PartImage, to either a network share or another disc on the host computer. When playing around with configuring a new PC, this tool makes it so much easier to experiment with drivers for example without getting your Windows installation in a mess.
TV Server Problem
All was going well until I reached the point of installing the Azurewave DVB-T cards and MediaPortal's TV Server.
No matter what I did, I could not get TV server to tune the cards. The error message was cryptic as it was in the depths of the BDA architecture. This was very frustrating because I already have a machine on which TV server works perfectly well with the Azurewave cards.
I set about restarting my install from various points (thankfully using PING) but it took me an age to find out what was causing the problem. I reinstalled many of the Windows updates, as generally I don't entirely trust that they won't have broken something, and also other applications which I'd installed in advance of the TV tuners.
Coincidentally enough, in the end, it was a classic case of PICNIC (Problem In Chair Not In Computer) because I'd tried to take a shortcut.. Recently MediaPortal have started to ship their application in a new deployment package. Seeing as I didn't want the full MP, just the TV Server, I'd extracted the deployment package and retrieved the TV Server installation. Had I not done that, it would probably have worked first time (sigh).
In my enthusiasm, I'd forgotten to run on a dependency before installing the TV Server. The deployment package automatically checks for this and tells you, but I wasn't running that.
Tail between my legs, I'm forced to admit (as a software developer by profession) that I fell for something that I tell users all the time - read the instructions on the box (or similar, but in fewer words!)
I guess we're all susceptable to making a mistake from time to time, and of course as a developer I always think I know better than anyone else when it comes to these funny interweb boxes!
I have made a note not to be so cocky again...
I initially thought it was a good idea to get Windows up to date as much as possible, then install applications. This usually results in a stable system. In addition, I took partition backups throughout the process so that if something went wrong, I could restore to a clean position.
PING
I realised that there's no need to buy a tool such as Norton Ghost any more as there are plenty of solutions available for free (which use Linux under the hood). One such example is PING which conveniently comes as a tiny bootable ISO cd image - allowing you to use it without affecting your filesystem.
It backs up a partition using PartImage, to either a network share or another disc on the host computer. When playing around with configuring a new PC, this tool makes it so much easier to experiment with drivers for example without getting your Windows installation in a mess.
TV Server Problem
All was going well until I reached the point of installing the Azurewave DVB-T cards and MediaPortal's TV Server.
No matter what I did, I could not get TV server to tune the cards. The error message was cryptic as it was in the depths of the BDA architecture. This was very frustrating because I already have a machine on which TV server works perfectly well with the Azurewave cards.
I set about restarting my install from various points (thankfully using PING) but it took me an age to find out what was causing the problem. I reinstalled many of the Windows updates, as generally I don't entirely trust that they won't have broken something, and also other applications which I'd installed in advance of the TV tuners.
Coincidentally enough, in the end, it was a classic case of PICNIC (Problem In Chair Not In Computer) because I'd tried to take a shortcut.. Recently MediaPortal have started to ship their application in a new deployment package. Seeing as I didn't want the full MP, just the TV Server, I'd extracted the deployment package and retrieved the TV Server installation. Had I not done that, it would probably have worked first time (sigh).
In my enthusiasm, I'd forgotten to run on a dependency before installing the TV Server. The deployment package automatically checks for this and tells you, but I wasn't running that.
Tail between my legs, I'm forced to admit (as a software developer by profession) that I fell for something that I tell users all the time - read the instructions on the box (or similar, but in fewer words!)
I guess we're all susceptable to making a mistake from time to time, and of course as a developer I always think I know better than anyone else when it comes to these funny interweb boxes!
I have made a note not to be so cocky again...
Monday, 19 May 2008
TV Server and Azurewave
I bought a new dual tuner last week, the Azurewave DVB-T AD-TU700 USB2. The reason for this was two fold: Firstly my Pinnacle Dual USB had been losing the ITV/Ch4 multiplex occasionally and although I'm sure it's mainly to do with the quality of my aerial, it was getting annoying. Secondly, the Azurewave is a remarkable one third of the cost of a dual Nebula card and half the cost of the Pinnacle. (That is assuming that you can buy a Nebula now that they appear to have gone under). For just £30, I can have a dual DVB-T tuner which has had generally good reviews on the web.
When it arrived I switched out the Pinnacle and was pleased to see that the Azurewave only requires a single aerial connection rather than the Pinnacle's two. Unfortunately, no matter what I tried I couldn't get MediaCenter to recognise it. That was strange because it claims to be MCE compliant, and using the provided viewing software it worked ok. Similarly, later tests with other BDA compatible software also worked ok. I've put it down to something odd about my MCE installation, and as you'll see shortly it won't prove to be a problem.. It does also appear to be more sensitive than the Pinnacle as it solves the ITV/Ch4 issue.
TV Server
So, on to the reason why MCE doesn't matter any more: If you remember a post or two ago I was explaining how I'd managed to get over-the-network streaming of my live tv working using MediaPortal's TV Server. My aim is to move to that software full time, using it to record television and provide the streaming capability. It's important that it controls both as otherwise it can clash with MCE when they both try and use the tuners. (It's worth noting that MediaPortal has reached 1.0.0.0 RC 1 and is more stable than ever. It's also worth noting that you don't need to install MediaPortal to use TV Server on its own).
I installed the latest TV Server and set it scanning. It found all freeview channels immediately using the new card, and the scan process is a lot quicker than MCE which is a nice change.
As usual when I change tuners/recording systems (see previous posts!) I need a new plugin for my TV Guide application. Fortunately TV Server is written in .NET and uses SQL Server as its backend database. It only took a few minutes for me to find the table which creates recording requests and insert one myself.
The new plugin architecture of the TV Guide makes it incredibly easy to add new types of recording systems without changing any of the functionality of the TV Guide. 10 to 15 lines of code later, I had it all working.
My set up is now that I use TV Server and the Azurewave card for my primary recording, with the Nebula available for viewing or as a backup tuner for recording. TV Server supports recording multiple channels from a single multiplex too, which was not available with MCE. This means that there's rarely a need to use the Nebula. I've missed that functionality (Nebula had it) and it's great to have it back.
As time passes, I will retire the Nebula altogether however, and switch to watching TV entirely via the TV Server - across the network too if I so wish. When I do that, and based on the success of the Azurewave, I can see myself adding another of those cards to provide capacity for whole house TV with no clashing.
Transport Streams
The TV Server has the option to convert Transport Streams (.TS) into MPG as it records. I found this only to work on some multiplexes however. There was no problem with viewing all multiplexes, just with recording some of them.
That's a little strange, but I do know that there are big differences in quality (bitrate) between multiplexes and that might be the problem. I switched the TV Server to record in .TS format instead (pretty much what comes over the air) and it works fine on all multiplexes now. I simply use my existing post-processing tool to convert it into MPG using ProjectX . This is not much different from post-processing DVR-MS files created by MCE into MPG. It takes a matter of seconds.
I'll report back on how well TV Server performs over time. Of course reliability is everything, and one thing that MCE generally did very well, so I'm interested in how TV Server will hold out.
When it arrived I switched out the Pinnacle and was pleased to see that the Azurewave only requires a single aerial connection rather than the Pinnacle's two. Unfortunately, no matter what I tried I couldn't get MediaCenter to recognise it. That was strange because it claims to be MCE compliant, and using the provided viewing software it worked ok. Similarly, later tests with other BDA compatible software also worked ok. I've put it down to something odd about my MCE installation, and as you'll see shortly it won't prove to be a problem.. It does also appear to be more sensitive than the Pinnacle as it solves the ITV/Ch4 issue.
TV Server
So, on to the reason why MCE doesn't matter any more: If you remember a post or two ago I was explaining how I'd managed to get over-the-network streaming of my live tv working using MediaPortal's TV Server. My aim is to move to that software full time, using it to record television and provide the streaming capability. It's important that it controls both as otherwise it can clash with MCE when they both try and use the tuners. (It's worth noting that MediaPortal has reached 1.0.0.0 RC 1 and is more stable than ever. It's also worth noting that you don't need to install MediaPortal to use TV Server on its own).
I installed the latest TV Server and set it scanning. It found all freeview channels immediately using the new card, and the scan process is a lot quicker than MCE which is a nice change.
As usual when I change tuners/recording systems (see previous posts!) I need a new plugin for my TV Guide application. Fortunately TV Server is written in .NET and uses SQL Server as its backend database. It only took a few minutes for me to find the table which creates recording requests and insert one myself.
The new plugin architecture of the TV Guide makes it incredibly easy to add new types of recording systems without changing any of the functionality of the TV Guide. 10 to 15 lines of code later, I had it all working.
My set up is now that I use TV Server and the Azurewave card for my primary recording, with the Nebula available for viewing or as a backup tuner for recording. TV Server supports recording multiple channels from a single multiplex too, which was not available with MCE. This means that there's rarely a need to use the Nebula. I've missed that functionality (Nebula had it) and it's great to have it back.
As time passes, I will retire the Nebula altogether however, and switch to watching TV entirely via the TV Server - across the network too if I so wish. When I do that, and based on the success of the Azurewave, I can see myself adding another of those cards to provide capacity for whole house TV with no clashing.
Transport Streams
The TV Server has the option to convert Transport Streams (.TS) into MPG as it records. I found this only to work on some multiplexes however. There was no problem with viewing all multiplexes, just with recording some of them.
That's a little strange, but I do know that there are big differences in quality (bitrate) between multiplexes and that might be the problem. I switched the TV Server to record in .TS format instead (pretty much what comes over the air) and it works fine on all multiplexes now. I simply use my existing post-processing tool to convert it into MPG using ProjectX . This is not much different from post-processing DVR-MS files created by MCE into MPG. It takes a matter of seconds.
I'll report back on how well TV Server performs over time. Of course reliability is everything, and one thing that MCE generally did very well, so I'm interested in how TV Server will hold out.
Monday, 31 March 2008
Linux/Mono TV Streaming
Well I've had some success with porting the streaming TV client application to Linux under Mono. All of the credit remains with the developers of MediaPortal for their excellent server application, however for my part I was able to fix a few incompatibilities between .NET on Windows and that on Mono.
I found that there were three main problems:
Remoting between a Mono client and a Windows server
.NET remoting is used in this application to provide the remote-control capability between the client and the server. This allows the client to change the channel being streamed, remotely from the client.
Remoting is the remote procedure call mechanism that superceded DCOM (COM+) in the older Microsoft COM technologies. It is a mechanism for a client machine to make a call to a server, and hold a connection to that server, in an object orientated way. Calls from the client are routed to the server in this case in a binary serialised format. Maintaining the compatibility of this mechanism between Mono and Windows is a big ask, but true to form the Mono Project have achieved that.
I had to do some debugging to work out what was causing this area to fail initially in my tests, but once I'd seen how it worked and installed the correct Mono runtimes, it turned out not to be a problem at all, merely that I needed to use an IP address rather than the server host name.
Live EPG
The second problem I had was the connection to the SQL Server backend of the TV Server application. MediaPortal use the Gentle Framework to provide database independence for the application. The database stores information like the EPG as well as the list of available cards and channels. I could not get the Gentle Framework to work on Mono, although I suspect that again might be partly down to me. I'll look into it further at some point as it might only be due to missing runtimes once again. When I find which are missing, they're easy to install.
For the moment, I created a web service which runs on the server and provides the information required by the client. Using web services is very simple in .NET and so this resolved the issue immediately.
Windows Forms UI
As the client application provided by MediaPortal was intended for Windows, it worked, but not very well, under Linux. I decided to rewrite it using Gtk# as explained in my previous posts so that it would look more native on both platforms.
The result
I now have a panel type application which has a button for every channel tuned on the server. These are discovered automatically by the client from the server. Simplying clicking on the channel starts the server streaming, and then starts VLC to receive that stream on the client. Clicking on an alternative channel stops VLC, changes the streaming channel on the server and restarts VLC.
I can't believe how long I've been searching for a solution to this problem and thanks almost entirely to the team at MediaPortal and the impressive Mono platform for Linux, I have at last achieved exactly what I want.
I will be able to increase the tuner count in the server in a single location in my house (where the TV signal comes in), and then use those tuners from any machine connected to the network. There's no problem with multiple clients on multiple channels simultaneously, and it's all cross-platform to boot. Excellent!
I found that there were three main problems:
Remoting between a Mono client and a Windows server
.NET remoting is used in this application to provide the remote-control capability between the client and the server. This allows the client to change the channel being streamed, remotely from the client.
Remoting is the remote procedure call mechanism that superceded DCOM (COM+) in the older Microsoft COM technologies. It is a mechanism for a client machine to make a call to a server, and hold a connection to that server, in an object orientated way. Calls from the client are routed to the server in this case in a binary serialised format. Maintaining the compatibility of this mechanism between Mono and Windows is a big ask, but true to form the Mono Project have achieved that.
I had to do some debugging to work out what was causing this area to fail initially in my tests, but once I'd seen how it worked and installed the correct Mono runtimes, it turned out not to be a problem at all, merely that I needed to use an IP address rather than the server host name.
Live EPG
The second problem I had was the connection to the SQL Server backend of the TV Server application. MediaPortal use the Gentle Framework to provide database independence for the application. The database stores information like the EPG as well as the list of available cards and channels. I could not get the Gentle Framework to work on Mono, although I suspect that again might be partly down to me. I'll look into it further at some point as it might only be due to missing runtimes once again. When I find which are missing, they're easy to install.
For the moment, I created a web service which runs on the server and provides the information required by the client. Using web services is very simple in .NET and so this resolved the issue immediately.
Windows Forms UI
As the client application provided by MediaPortal was intended for Windows, it worked, but not very well, under Linux. I decided to rewrite it using Gtk# as explained in my previous posts so that it would look more native on both platforms.
The result
I now have a panel type application which has a button for every channel tuned on the server. These are discovered automatically by the client from the server. Simplying clicking on the channel starts the server streaming, and then starts VLC to receive that stream on the client. Clicking on an alternative channel stops VLC, changes the streaming channel on the server and restarts VLC.
I can't believe how long I've been searching for a solution to this problem and thanks almost entirely to the team at MediaPortal and the impressive Mono platform for Linux, I have at last achieved exactly what I want.
I will be able to increase the tuner count in the server in a single location in my house (where the TV signal comes in), and then use those tuners from any machine connected to the network. There's no problem with multiple clients on multiple channels simultaneously, and it's all cross-platform to boot. Excellent!
Tuesday, 25 March 2008
Eureka!
I've finally found a workable solution for streaming live tv around the network. I knew of MediaPortal a good while ago, before I had Windows Mediacenter. It's basically an open source MCE clone for windows, written almost entirely in .NET.
When I looked at it previously it wasn't very stable. Certainly it did not compete with MCE for reliability or presentation. More recently however I've heard better things about it. In questions about streaming TV posted on various fora, the answers often have pointed at MediaPortal. I have not had a chance to check it out until now.
The key new feature is their TV Server engine. It runs as a service on your central server where the tuners are located. It provides the ability to stream any channel from any number of BDA compatibile tuners via the standard streaming protocol RTSP, to multiple clients on the network. Critically it also allows the client to change channels remotely. That's the feature which other solutions I've used have not had - and is what makes them all but useless for my requirements.
By default the client application is another instance of MediaPortal (MP), but searching around the MP website I saw that one of the developers had produced a small .NET application which provides the TV streaming without the rest of MP. Now don't get me wrong, MP is a much more polished solution these days and it does seem to be more reliable, however it is a bit overkill for what I want to do and will not run under Linux. Having a lightweight solution is more appropriate, at least to start with.
The client application basically looks after the connection and remote control of the server. It instructs the server to start broadcasting a specific channel to a client on the network. The application then starts the prevalent VLC player to receive the stream. This is great because it does only the bear minimum required. Change channel in the client application, and VLC is restarted pointing at the new stream.
Multiple clients can connect to the server and as long as there are free tuners available, they can tune into other channels simultaneously. On top of that, each stream seems to take only around 6% of the CPU on the server in comparison with other solutions I've seen where it can take more than 20%. That makes it quite scaleable for multiple tuners.
I've had a look at the code in the client application too, as it's written in C#. It's really not complicated, and relies on a small featureset of MP. I'm going to have a go at porting it to Mono under Linux as there would seem to be no reason why it wouldn't work. VLC already exists for Linux so that would allow me to use this solution over cheaper client workstations rather than having to install Windows on each of them.
When I looked at it previously it wasn't very stable. Certainly it did not compete with MCE for reliability or presentation. More recently however I've heard better things about it. In questions about streaming TV posted on various fora, the answers often have pointed at MediaPortal. I have not had a chance to check it out until now.
The key new feature is their TV Server engine. It runs as a service on your central server where the tuners are located. It provides the ability to stream any channel from any number of BDA compatibile tuners via the standard streaming protocol RTSP, to multiple clients on the network. Critically it also allows the client to change channels remotely. That's the feature which other solutions I've used have not had - and is what makes them all but useless for my requirements.
By default the client application is another instance of MediaPortal (MP), but searching around the MP website I saw that one of the developers had produced a small .NET application which provides the TV streaming without the rest of MP. Now don't get me wrong, MP is a much more polished solution these days and it does seem to be more reliable, however it is a bit overkill for what I want to do and will not run under Linux. Having a lightweight solution is more appropriate, at least to start with.
The client application basically looks after the connection and remote control of the server. It instructs the server to start broadcasting a specific channel to a client on the network. The application then starts the prevalent VLC player to receive the stream. This is great because it does only the bear minimum required. Change channel in the client application, and VLC is restarted pointing at the new stream.
Multiple clients can connect to the server and as long as there are free tuners available, they can tune into other channels simultaneously. On top of that, each stream seems to take only around 6% of the CPU on the server in comparison with other solutions I've seen where it can take more than 20%. That makes it quite scaleable for multiple tuners.
I've had a look at the code in the client application too, as it's written in C#. It's really not complicated, and relies on a small featureset of MP. I'm going to have a go at porting it to Mono under Linux as there would seem to be no reason why it wouldn't work. VLC already exists for Linux so that would allow me to use this solution over cheaper client workstations rather than having to install Windows on each of them.
Monday, 17 March 2008
Gtk# TV Guide
Here are the screen shots promised in the last post. These are running as .NET applications on Windows and Ubuntu Linux using the Gtk libraries for the windowing. On Linux the application is running under Mono. This is an early version, so the channel names are not showing yet.
Windows
Linux
The reason I'm so happy with this is that the rendering performance is the same on Linux as it was using Windows.Forms on Windows, and the performance of GTK on Windows is equally quick. Cairo provides some very fast painting!
Also critical is the fact that on under both environments the application looks "native" which is the result I've been looking for.
Windows
Linux
The reason I'm so happy with this is that the rendering performance is the same on Linux as it was using Windows.Forms on Windows, and the performance of GTK on Windows is equally quick. Cairo provides some very fast painting!Also critical is the fact that on under both environments the application looks "native" which is the result I've been looking for.
Latest News
It's been a long time since I have managed to update the blog, and that's mainly because I've not been doing much work on the TV Guide recently. Generally it works fine for my purposes now, so little has been updated.
One area I have made some small changes to is in permitting it to work in a more client-server fashion. One PC must be considered to be the server, and it is responsible for organising recordings and downloading the XMLTV data. Once the data has been downloaded however, other machines on the network can share that data as if it were local.
Of course, the remote TV Guides all talk to the server to coordinate and set their recordings, and the server will distribute those recording requests around the tuners on the network if set up to do so.
This is irrelevant if you're using the web interface as that is always server based, but for me my cross-platform Java implementation still does not have the polish of a locally installed version. Now the data is shared, you can run a full version on any PC you like just by copying the installation files over.
I've also updated the AutoConvert tool so that it can be set just to convert from DVR-MS to MPG and not to XVid if required. This is because some people don't care for XVid but still want to play the recorded files on their Mac for example. It's also been changed to copy the final files somewhere else on the network, again heading down the line of the central PC doing the processing locally, and then the files getting deposited on a NAS for example.
Finally, I fixed a bug in the XMLTV parsing which was struggling with odd characters in the XML feed. I'm using the .NET XMLTextReader now which is far more reliable than the old system. If your guide is not updating, you might need this fix.
Eee PC
I've had my eye on one of these for a while, as they seem to combine both the functionality, the extreme compactness and the price all together in one package. I wouldn't use it for serious work, but as a machine to take on holiday to process images, or browse the net, it's just about perfect.
Great news is that Asus are launching a 9" screen version later this year, which will put aside the only thing which has stopped me from picking one up already.
They also plan to create a desktop version, which if it's priced right could be a perfect low cost client for other rooms in the house.
Mono and GTK
One area of development I have been playing around with (once again) is Mono under Linux. I was both initially impressed and then disappointed with it's performance when moving the TV Guide as it stood to Linux but that turned out to be a problem with my expectation rather than with Mono. It's a lot to expect Windows.Forms to work well under Linux, and given the complexity of achieving this, actually it's no surprise.
Instead I've been playing with GTK# which is a .NET wrapper over the GTK+ UI which Gnome uses. This initially might seem like a step completely the other way, but the reason I've had success with it is because there's an excellent Windows port of GTK+ which performs as well as Windows.Forms on the Windows platform. Even the user-drawn parts of the TV Guide are no problem using a mixture Cairo and Gdk.
Finally it seems I could have a single code base which would look as good (and as native) on Windows as it will on Gnome Linux. That's serious credit to everyone behind Mono and Gtk#.
To credit Mono once again, it's also amazing that it's only the UI which needs to be updated for the whole of the TV Guide application to run on Linux. The core (probably 85-90% of the application) runs flawlessly on both Windows and Linux, even to the point of binary compatibility with serialised and deserialised objects for example. That's quite amazing technologically.
Anyway I hope to get some screen shots of the GTK# front end on the blog shortly, so you can see just how it looks on both platforms.
There's only one downside to GTK+ and that's that it does not look "native" on Mac OSX. That's a real shame, and I suspect that it's only a matter of time until someone works on that. There is another option with Cocoa#, but that will require me to write a separate UI just for the Mac. At present (as I don't have a Mac!) I'm not going to do that.
One area I have made some small changes to is in permitting it to work in a more client-server fashion. One PC must be considered to be the server, and it is responsible for organising recordings and downloading the XMLTV data. Once the data has been downloaded however, other machines on the network can share that data as if it were local.
Of course, the remote TV Guides all talk to the server to coordinate and set their recordings, and the server will distribute those recording requests around the tuners on the network if set up to do so.
This is irrelevant if you're using the web interface as that is always server based, but for me my cross-platform Java implementation still does not have the polish of a locally installed version. Now the data is shared, you can run a full version on any PC you like just by copying the installation files over.
I've also updated the AutoConvert tool so that it can be set just to convert from DVR-MS to MPG and not to XVid if required. This is because some people don't care for XVid but still want to play the recorded files on their Mac for example. It's also been changed to copy the final files somewhere else on the network, again heading down the line of the central PC doing the processing locally, and then the files getting deposited on a NAS for example.
Finally, I fixed a bug in the XMLTV parsing which was struggling with odd characters in the XML feed. I'm using the .NET XMLTextReader now which is far more reliable than the old system. If your guide is not updating, you might need this fix.
Eee PC
I've had my eye on one of these for a while, as they seem to combine both the functionality, the extreme compactness and the price all together in one package. I wouldn't use it for serious work, but as a machine to take on holiday to process images, or browse the net, it's just about perfect.
Great news is that Asus are launching a 9" screen version later this year, which will put aside the only thing which has stopped me from picking one up already.
They also plan to create a desktop version, which if it's priced right could be a perfect low cost client for other rooms in the house.
Mono and GTK
One area of development I have been playing around with (once again) is Mono under Linux. I was both initially impressed and then disappointed with it's performance when moving the TV Guide as it stood to Linux but that turned out to be a problem with my expectation rather than with Mono. It's a lot to expect Windows.Forms to work well under Linux, and given the complexity of achieving this, actually it's no surprise.
Instead I've been playing with GTK# which is a .NET wrapper over the GTK+ UI which Gnome uses. This initially might seem like a step completely the other way, but the reason I've had success with it is because there's an excellent Windows port of GTK+ which performs as well as Windows.Forms on the Windows platform. Even the user-drawn parts of the TV Guide are no problem using a mixture Cairo and Gdk.
Finally it seems I could have a single code base which would look as good (and as native) on Windows as it will on Gnome Linux. That's serious credit to everyone behind Mono and Gtk#.
To credit Mono once again, it's also amazing that it's only the UI which needs to be updated for the whole of the TV Guide application to run on Linux. The core (probably 85-90% of the application) runs flawlessly on both Windows and Linux, even to the point of binary compatibility with serialised and deserialised objects for example. That's quite amazing technologically.
Anyway I hope to get some screen shots of the GTK# front end on the blog shortly, so you can see just how it looks on both platforms.
There's only one downside to GTK+ and that's that it does not look "native" on Mac OSX. That's a real shame, and I suspect that it's only a matter of time until someone works on that. There is another option with Cocoa#, but that will require me to write a separate UI just for the Mac. At present (as I don't have a Mac!) I'm not going to do that.
Subscribe to:
Posts (Atom)