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!
Monday, 31 March 2008
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)