I've been playing with the DLLs which ship with Mediacenter (MCE) over the past week to try and find a way to get MCE to remove a timer from its recording schedule programmatically. Irritatingly (in MCE 2005) the API Microsoft have provided does not allow the removal of a timer. To get around this I've been probing some of the DLLs which make up MCE and eventually I found a hidden API which does allow me to manipulate the schedule list.
One issue with this however, has been updating the list of timers once a timer has been removed. The list is kept in an XML file, but MCE only writes that file out when it feels it needs to. I'm using an undocumented API of course, so MCE doesn't know that I've changed anything and the file does not get written.
Fortunately after some further experimentation, I have found a way to make MCE write the file on demand (by setting a key property to itself). This updates the XML on demand, and I can read it immediately with the updated information inside. I'm pleased I've found a way to do this, because it was one feature of the Nebula interface which I couldn't get to work in MCE.
In poking around at this level I have also found out how to read the MCE EPG data direct from its database, which is useful if XMLTV is not available, or if you prefer the level of detail you get in MCE's EPG. I've modified the guide application to abstract away the implementation of how the guide is populated - and created a new "plug-in" interface which fills the guide with data. As a result, you can now choose which plug-in you want to use - either MCE or XMLTV - just by modifying the configuration file. I think this is of limited use at present as the XMLTV data works fine for me, but if I ever decide to sell this application, it makes sense to support something other than XMLTV.
Finally I've added an RSS feed from the web site which will allow you to subscribe with your favourite reader and see which recordings have been set automatically each day. If you click on a feed entry, you are sent to the description page on the website for that programme. A friend requested this feature, and I'm happy to oblige.. ;-)
Monday, 22 October 2007
Wednesday, 10 October 2007
TV Guide on the Mac
I suppose it was only a matter of time until I managed to get some Mac screenshots of the guide to complete the picture! Here are some with the guide running in Safari:
My virtual machine was running OS X 10.3 which presented a bit of a Java version problem, but once I'd targetted my build at Java 1.4.12, everything was fine. I see that Apple have updated to at least Java 1.5 on the latest OS X, so that would not be a problem on a real machine.
Here it's possible to see the search screen. Bear in mind all of these pages are designed to be seen from an armchair rather than your computer screen..

The Mac, as usual, does a lovely job of rendering the Java applet and web pages. I feel like I've been writing native Mac applications all my life ;-)
From my testing, I can see that the design will probably need a little modification to suit every platform, and given that there is less information displayed in the web TV guide than the Windows version (by default, to reduce load times) I think the channels could be a bit thinner and the vertical programme height a bit shorter. These are easily solvable however, and then it should be working just how I want it!
My virtual machine was running OS X 10.3 which presented a bit of a Java version problem, but once I'd targetted my build at Java 1.4.12, everything was fine. I see that Apple have updated to at least Java 1.5 on the latest OS X, so that would not be a problem on a real machine.Here it's possible to see the search screen. Bear in mind all of these pages are designed to be seen from an armchair rather than your computer screen..

The Mac, as usual, does a lovely job of rendering the Java applet and web pages. I feel like I've been writing native Mac applications all my life ;-)
From my testing, I can see that the design will probably need a little modification to suit every platform, and given that there is less information displayed in the web TV guide than the Windows version (by default, to reduce load times) I think the channels could be a bit thinner and the vertical programme height a bit shorter. These are easily solvable however, and then it should be working just how I want it!
Tuesday, 9 October 2007
TV Guide under Ubuntu
Well I finally got around to testing the new web-based guide under Linux, on my favourite Linux flavour, Ubuntu. Here are a couple of screenshots showing how it looks:
The first shows the main page, with the new Java applet running exactly as expected. The trimmings around the applet are standard ASP.NET generated HTML.
And then the Now and Next page, which of course does not use Java, just ASP.NET to serve up the dynamic content.
I'm pleased with the results, and to be honest in comparison with converting the .NET application to run under Mono, or trying to draw the guide using HTML/JavaScript, the Java solution has been remarkably straightforward.
I really hope that Silverlight can provide the same kind of ease of use cross-platform, and if it can, it's surely a winner for Microsoft. Until that day comes though, Java rules!
The first shows the main page, with the new Java applet running exactly as expected. The trimmings around the applet are standard ASP.NET generated HTML.
And then the Now and Next page, which of course does not use Java, just ASP.NET to serve up the dynamic content.
I'm pleased with the results, and to be honest in comparison with converting the .NET application to run under Mono, or trying to draw the guide using HTML/JavaScript, the Java solution has been remarkably straightforward.I really hope that Silverlight can provide the same kind of ease of use cross-platform, and if it can, it's surely a winner for Microsoft. Until that day comes though, Java rules!
Monday, 8 October 2007
First look - web interface
Here's a first look at the web (cross platform) interface for the TV guide, running as a Java applet in Firefox on Windows. I hope you agree it's pretty close to the native Windows version!

The programme descriptions are deliberately cut short by default to save network data bandwidth, but if you double-click on a programme, the full data is then loaded and cached.
All I need now is a Mac user to test this ;-) Remember you still need a windows PC to serve the website at the moment.
I'll be giving it a go under Linux later to check that it works on that platform, but I'm pretty confident that it'll be fine, seeing as Java support is widespread.

The programme descriptions are deliberately cut short by default to save network data bandwidth, but if you double-click on a programme, the full data is then loaded and cached.
All I need now is a Mac user to test this ;-) Remember you still need a windows PC to serve the website at the moment.
I'll be giving it a go under Linux later to check that it works on that platform, but I'm pretty confident that it'll be fine, seeing as Java support is widespread.
Saturday, 6 October 2007
New look once again
Perhaps I have a low attention threshold, but I've changed the UI appearance of the guide once again.
I thought that it needed to be modernised a bit, and to be a little less bold in its choice of colours. This has been carried through to the web interface too, so there's a themed look to all the applications now.

Hopefully you'll agree with me that it looks a little more professional now, and hopefully I won't have to change it again for a little while ;-)
I thought that it needed to be modernised a bit, and to be a little less bold in its choice of colours. This has been carried through to the web interface too, so there's a themed look to all the applications now.
Hopefully you'll agree with me that it looks a little more professional now, and hopefully I won't have to change it again for a little while ;-)
Wednesday, 3 October 2007
Web enablement and Cross platform development
A good friend of mine suggested to me that I should web-enable my TV guide application, so that it would operate cross-platform.
Seeing as I'm still considering a low cost Linux based PC as a mediacentre, this definitely sparked my interest.
In this blog, I've previously covered my exploits with trying to get the guide to run natively under Mono which would immediately enable it to be run on Linux and the Mac. Although that has potential, my initial work with it has not produced a reliable enough version of my guide which will run on Linux (yet).
Keeping it running on a Windows machine and having it served up to a browser however does initially sound like a great idea. Why bother worrying about getting it to run natively on a non-Windows machine?
The issue with this is that providing the same level of graphical appearance and interaction is not straightforward using HTML and JavaScript. Google have got it down, with their Calendar, Mail, Word Processor and Spreadsheet applications, but they have a few more developers available to them than I do ;-)
Generally, my experience of JavaScript and the associated web development has been painful - browser wars aside - I feel JavaScript is a poor competitor to languages such as Java and C#. I'm not saying it can't be done in JavaScript with enough effort, but in comparison with how quickly I can put together an application in other languages, I find JavaScript too big a hill to climb.
That's not to say that a lot of what the TV Guide provides cannot be web-enabled. Setting up recording rules and searching for programmes etc can easily fit into a less graphical interface. I'm an experienced ASP.NET developer, and there's no issue with me writing that functionality on top of my existing core guide functionality.
The key area however which requires the interaction is the main guide display..
Alternatives to JavaScript
Seeing as I am a software developer by profession, and have invested much time in the Microsoft camp, the recent announcement of Silverlight has me very interested. Silverlight is Microsoft's answer to Flash, which some are reporting has the potential to be a flash killer. That remains to be seen however (it's very early days), and Adobe are bound to have something to say about it.
In its present incarnation (1.0), Silverlight provides mainly flash-like capabilities such as animation and video playback. Programmatically, Silverlight currently uses JavaScript which is not ideal for me for the reasons above. In Silverlight's next incarnation (1.1) however it will bring .NET language support (VB and C#). That will be a real change of direction for Microsoft, as they have already produced the Silverlight plugin for the Mac and are working with Novell and the Mono project for the Linux version. Scott Guthrie (the General Manager of the .NET development teams at Microsoft) recently confirmed this partnership.
I'm hoping that Silverlight 1.1 will allow me to produce cross-platform, flash-like quality graphics and interaction using C# which will require minimal changes to my existing C# code base. 1.1 is due out early 2008, but I will probably play around with the beta before then, which is out now.
In the meantime, I'm left with just one cross-platform contender - Java.
Java and .NET interaction
I have always tried to keep the span of technology for my guide to the minimum. It's harder to maintain multiple code streams in multiple language technologies, so what has changed my mind? Simply that I can produce a Java applet that displays the graphical portion of my TV guide in only a few days. Behind the scenes, the data is still provided by my .NET server code base, and made available to the applet via a .NET XML web service. I've already written much of that connectivity code in a past project, so grabbing it for this makes that part of the project much quicker.
The remainder of the Java code is regarding the drawing of the guide, the display of programme details on double-click, and the ability to set recordings. Beyond that, as I see it, the rest can be implemented using traditional ASP.NET web pages rather than in Java - keeping my cross-language code to a minimum. Hopefully to the web user this will be transparent, as the applet will itself just be embedded in one of the web pages.
I've started this Java project as an exercise, and already have the guide displaying with my required interactivity inside a web page. I have yet to try it on other platforms, but as long as Java can be installed on the Mac or Linux, it should work without issue. The benefit of that cross-platform ability vs the cost of maintaining two sets of code in my mind is not an issue as the majority of the code is still behind the server, and not in the applet.
I'll post more about this project as I finish parts of it.
Seeing as I'm still considering a low cost Linux based PC as a mediacentre, this definitely sparked my interest.
In this blog, I've previously covered my exploits with trying to get the guide to run natively under Mono which would immediately enable it to be run on Linux and the Mac. Although that has potential, my initial work with it has not produced a reliable enough version of my guide which will run on Linux (yet).
Keeping it running on a Windows machine and having it served up to a browser however does initially sound like a great idea. Why bother worrying about getting it to run natively on a non-Windows machine?
The issue with this is that providing the same level of graphical appearance and interaction is not straightforward using HTML and JavaScript. Google have got it down, with their Calendar, Mail, Word Processor and Spreadsheet applications, but they have a few more developers available to them than I do ;-)
Generally, my experience of JavaScript and the associated web development has been painful - browser wars aside - I feel JavaScript is a poor competitor to languages such as Java and C#. I'm not saying it can't be done in JavaScript with enough effort, but in comparison with how quickly I can put together an application in other languages, I find JavaScript too big a hill to climb.
That's not to say that a lot of what the TV Guide provides cannot be web-enabled. Setting up recording rules and searching for programmes etc can easily fit into a less graphical interface. I'm an experienced ASP.NET developer, and there's no issue with me writing that functionality on top of my existing core guide functionality.
The key area however which requires the interaction is the main guide display..
Alternatives to JavaScript
Seeing as I am a software developer by profession, and have invested much time in the Microsoft camp, the recent announcement of Silverlight has me very interested. Silverlight is Microsoft's answer to Flash, which some are reporting has the potential to be a flash killer. That remains to be seen however (it's very early days), and Adobe are bound to have something to say about it.
In its present incarnation (1.0), Silverlight provides mainly flash-like capabilities such as animation and video playback. Programmatically, Silverlight currently uses JavaScript which is not ideal for me for the reasons above. In Silverlight's next incarnation (1.1) however it will bring .NET language support (VB and C#). That will be a real change of direction for Microsoft, as they have already produced the Silverlight plugin for the Mac and are working with Novell and the Mono project for the Linux version. Scott Guthrie (the General Manager of the .NET development teams at Microsoft) recently confirmed this partnership.
I'm hoping that Silverlight 1.1 will allow me to produce cross-platform, flash-like quality graphics and interaction using C# which will require minimal changes to my existing C# code base. 1.1 is due out early 2008, but I will probably play around with the beta before then, which is out now.
In the meantime, I'm left with just one cross-platform contender - Java.
Java and .NET interaction
I have always tried to keep the span of technology for my guide to the minimum. It's harder to maintain multiple code streams in multiple language technologies, so what has changed my mind? Simply that I can produce a Java applet that displays the graphical portion of my TV guide in only a few days. Behind the scenes, the data is still provided by my .NET server code base, and made available to the applet via a .NET XML web service. I've already written much of that connectivity code in a past project, so grabbing it for this makes that part of the project much quicker.
The remainder of the Java code is regarding the drawing of the guide, the display of programme details on double-click, and the ability to set recordings. Beyond that, as I see it, the rest can be implemented using traditional ASP.NET web pages rather than in Java - keeping my cross-language code to a minimum. Hopefully to the web user this will be transparent, as the applet will itself just be embedded in one of the web pages.
I've started this Java project as an exercise, and already have the guide displaying with my required interactivity inside a web page. I have yet to try it on other platforms, but as long as Java can be installed on the Mac or Linux, it should work without issue. The benefit of that cross-platform ability vs the cost of maintaining two sets of code in my mind is not an issue as the majority of the code is still behind the server, and not in the applet.
I'll post more about this project as I finish parts of it.
Subscribe to:
Posts (Atom)