![]() |
|
General Discussion General discussion about SageTV and related companies, products, and technologies. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
#1
|
||||
|
||||
![]() WARNING: Posting contains technical jargon not suitable for all readers! I like SageTV. I've used many other Media Centers, and SageTV really does take the prize, especially when you factor in the cost effective media extenders. I've seen many posting on what people would like to see in the next SageTV, but my post is about what you can't see in the next SageTV.... ie, it's about the architecture and not the functionality. I started to write a media center some time ago, but I abandoned the project, once I stumbled upon SageTV. Most of what I've outlined here are ideas that I have implemented or started to implement in my own Media Center project. I've provided it here in hopes that Sage developers can look at this and maybe take some of these ideas for their next rewrite of SageTV. What I would keep....
What I would change....
Sage Developers.... I would love to see OSGI in your next platform release. Good Luck,
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#2
|
||||
|
||||
Interesting. I have to admit that I'd not heard of OSGi until you brought it up. Are there any OSGi implementations in the htpc arena that would provide a compelling reason to move this way? A quick look at http://en.wikipedia.org/wiki/OSGi and http://www.osgi.org/About/Members didn't show up any current applications that made me think that OSGi would provide a quantum leap in capabilities. Admittedly I haven't yet looked at any of the detail.
Nice ideas re: splitting the stv into multiple files. This sounds similar to the way that some standards such as IMS content packaging works with submanifests referred to as required. This might simplify the process of loading stvi's in that if you installed three plugins a, b and c then decided to remove b you may not need to revert and reload. Someone who actually develops for sage/sagemc would be better placed to offer an opinion though. I think that opening the database is generally a terrible idea. API's are a good idea in that they can be independent of the underlying technology. If you've given 3rd party developers direct access to the database then you've locked yourself into considering the impact that schema changes will have on existing plugins. As it stands Sage could decide to implement a different database technology and schema without affecting any 3rd party plugins and tools (afaik). Mick. |
#3
|
||||
|
||||
Quote:
Quote:
I think that if you ask yourself these questions in a project, then OSGI is a potentental good fit. 1. Do I want a modular system 2. Do I want to support a dynamically loadable plugin system 3. Do I want to enables services 4. Do I want a clean separation between services and their implemenations 5. Do I want to enable user contributed modules and or extensions ... Using an OSGI framework to support this would be beneficial since it provides the framework and implemenation to add these abilities. Anyone that has ever written the code to support dynamically loadable/unloadable plugins, and dynamic classpath loaders, etc, will welcome the fact that this has been done for you. The problem with OSGI is that it requires you to build software in a different way than we normally would think (or have been trained to think). Quote:
![]()
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#4
|
||||
|
||||
I'm not sure why you put such a high premium on dynamic loading. My impression is that most Sage users (as opposed to plugin writers) don't do a lot of tinkering with their systems. They install a few plugins they like and then they mostly leave it alone. So I'm not seeing what practical benefit these users will get from dynamic loading.
Once you let go of the requirement for dynamic loading, then it seems to me a lot of what you want can be done in the existing architecture. Modular, layered UI designs using XML and CSS could be coded outside of Studio using browser-based apps, and then transformed or compiled into Studio-compatible XML for execution by Sage. Again, end users aren't really going to care what the underlying technology is or how the various modules get combined into a functioning UI, so long as it's relatively painless and automatic. Similarly, nothing in the existing architecture prevents third-party devs from creating alternate UIs that aren't based on Studio at all (e.g. Neil's web server). I also think it's rather unlikely that the Sage devs will consider it a good use of their time to completely re-engineer a mature product that's already highly extensible as is. By the way, count me among those who had never heard of OSGI until you mentioned it. Without having delved too deeply into it, I'm not really seeing what sets it apart from other modularity frameworks like COM, CORBA, or loadable Java classes for that matter.
__________________
-- Greg |
#5
|
||||
|
||||
Greg,
My posting was more of a blog than a "Hey Sage... Do this...", that's why it starts with "IF I..." ![]() ![]() I totally agree that most, if not all, Sage users do not care about the actual technology, they just want it to work. Do Tivo users care that their box runs linux? Probably not. And the same is true of Sage users.... But my article was meant to look at the architecture, in a hypothetical way, and suggest an alternative. In a way, it's not much different than how SageMC compares to SageTV. SageMC looks as Sage and says, "hey, if I were to redo the Sage User Experience.... what would I do differently?" and before you know... SageMC is born ![]() Quote:
![]() I wouldn't dismiss the OSGI technology, just because you haven't heard about it. You have heard about Eclipse and RCP and it's foundation is OSGI. At some point in time, you didn't know about Java and Xml, but they are key technologies the Sage platform. Just think how your programming experience would be different if you dismissed Java and Xml just because you hadn't heard about it before. Maybe you interpreted my email as a criticism to Sage developers because they didn't choose OSGI. That is not the case. I can't expect them to use a technology that didn't really exist when they started out. I simply posted an article about what I would do differently. I'm willing to bet that most of the core Sage developers would do something different given the state of technology today, than when they started the project. Because they would choose to do something different doesn't mean it was done wrong in the first place. Sage will continue to innovate, and I wouldn't be surprised to see changes in thier core technology over time. In fact I'd probably be a bit disappointed if in 5 years, SageTV was still the exact same product.
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#6
|
|||
|
|||
The OP was a good read. Add me to the list of those who hadn't heard of OSGi (then again, I'm mostly a Windows Delphi programmer, very old school indeed).
The open database is not only a good idea, it's a great idea. The closed nature of wiz.bin always scares me, and it makes data manipulation a pain in the back side. Open the DB back end and programmers will come up with some neat add-ins, no doubt. (and for that matter, name one other application of this sort that runs its own database engine). - Jeff |
#7
|
||||
|
||||
![]()
I think that most people, unless you spend your time time in Java/Eclipse and/or embedded devices probably haven't heard about OSGi. But, in case people think that OSGi is not a "real" technology
![]() There is Eclipse http://www.eclipse.org/equinox/ And Apache http://felix.apache.org/site/index.html And Google (Well not quite Google, but OSGi can run on Android ![]() http://www.infoworld.com/article/08/...Android_1.html And Sun (Glassfish at least) http://blogs.sun.com/dochez/entry/gl...3_runs_on_osgi And IEEE has a paper that you can't read (unless you are member, I'm not) http://ieeexplore.ieee.org/Xplore/lo...number=4341564 And yes, surprisingly enough there is actually a media center (go figure) using OSGI (not that I was aware of it before writing this article ![]() http://mediacenterlinux.org/ The list goes on... and on.... especially if you start including embedded solutions....
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#8
|
||||
|
||||
I would port parts or the entire application to a much faster Language. Java is very very slow.
Dave Last edited by davephan; 04-15-2008 at 06:03 PM. |
#9
|
||||
|
||||
Not biting..... Must.... resist.... the.... urge... to... defend.... Java....
![]()
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#10
|
||||
|
||||
If this is just a hypothetical here's-how-I-would-have-done-it, then fine; I don't see much to object to in the original post. However your closing line ("I would love to see OSGI in your next platform release") gave me the impression that you're lobbying for a major architectural change in the actual product, and that's what I was reacting to.
If I had free rein to redesign Sage (and get someone else to do the coding), there are a lot of things about Studio, widget language, and the STV file format that I'd do differently. (I'd probably use XSL templates to transform abstract menu structures into concrete UI widgets at STV load time, to name just one idea.) But I've found it more productive to focus on how far I can go within the existing framework, and quite often that turns out to be a lot farther than I thought. So I guess my point, to the extent that I have one, is don't let new tech envy stop you from doing cool stuff with the existing tech.
__________________
-- Greg |
#11
|
||||
|
||||
Quote:
Quote:
S |
#12
|
||||
|
||||
Quote:
I agree that it would be nice to have this data available in a known format. I disagree that it would be a good thing for developers to access the data directly. Would you write an Exchange Server application that accesses the .edb files (or whatever they're using in Exchange 2007 now) directly? I wouldn't. I'd make sure that the supplied API was used to retrieve and manipulate data. This would ensure that I could expect not to need to rewrite my application/plugin with each update of the platform. As a software vendor would I be happy to provide support to customers who have been bypassing my business objects and writing directly to the db? Probably not. Mick. |
#13
|
||||
|
||||
Quote:
The part of SageTV that I would fix is the part that seems to have bottlenecks in the code. For example, when searching for programs. As each letter is typed, the result field narrows. The search results are displayed very slowly compared to they way it performed a couple of years ago even when using a much slower computer at that time. I also notice a lot of spinning circle waiting symbols in other program areas, even with a fast dual-core. If the user interface is causing the slow down, maybe that should be replaced with a faster language than the very slow Java. Dave |
#14
|
||||
|
||||
#15
|
|||
|
|||
Quote:
We're not talking about enterprise level email systems, so I think that example is besides the point. On the other two, they both sound open to me, no? I agree that directly accessing the underlying db can be dangerous and must be done carefully, but we're talking about tv program/recording (meta) data here, not exactly the stuff of rocket science. - Jeff |
#16
|
||||
|
||||
Quote:
![]() Seriously though... I would think that the slowdown in the search screen is more likely related to a poor index in the Wiz.bin data model. But since it's a closed database, we'll never know. Lucene could probably help with fast indexing and it could still be used in conjunction of the Wiz.bin. I've done searches across ~6.5 million records using Lucene, and I've seen results come back in less than 20ms.... So I think the folks in the Lucene project have optimized it fairly well. If OSGi was used, and the data persistence engine was an open set of services, then someone could/would have written a faster data search/persistence engine. As for the comment about about the only parts of Sage being Java is the UI and Studio.... I'm not sure if Wiz.bin is being handled natively or in Java. I would think that all performance intensive parts like decoding video for playback, and transcoding would be done natively, but there's no reason for the data model to be handled natively. Handling Tuners would obviously be done natively as well.... Which is a similar model as JMF and JTV. In my original post I mentioned Java as being a part that I would not change... I probably should have put Java/Native since I would continue to use mplayer as the movie engine and native tuner handling such as linuxdvb. Quote:
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#17
|
||||
|
||||
Surprised no one mentioned a solution for the filesystem. Yes currently 64K NTFS gets by, but really it just barely gets by when handling 4 or more tuners. Faster raid arrays help but a file system with larger clusters would help even more. Sure having a non-standard for windows filesystem means that you would have to dedicate a partition for your recordings, but we pretty much have to do that anyhow so not sure requiring that is too big a leap. With so many good free tools for resizing partitions this should not be that difficult to even add to the installer.
Other thing that needs work, the model used for tuner guide service. I need to be able to have custom channels for each tuner, as it stands I have to hunt for local "similar" cities guides to use for each tuner. Also a system to NOTIFY me when my channel lineup changes would be nice too. |
#18
|
||||
|
||||
Quote:
But, if you are seeing a long delay after the timeout period, then disable the one-touch NTE search, since that uses regular expressions and is slower. And searching can be slower depending on what type of search you are doing -- searching 'all fields' is slower than just searching 'title', for example. If you really want to see what searching is like w/o the input timeouts, then check out the search/delayXXX properties, though I don't really suggest changing them. - Andy
__________________
SageTV Open Source v9 is available. - Read the SageTV FAQ. Older PDF User's Guides mostly still apply: SageTV V7.0 & SageTV Studio v7.1. - Hauppauge remote help: 1) Basics/Extending it 2) Replace it 3) Use it w/o needing focus - HD Extenders: A) FAQs B) URC MX-700 remote setup Note: This is a users' forum; see the Rules. For official tech support fill out a Support Request. |
#19
|
||||
|
||||
Greg,
Quote:
Quote:
__________________
Batch Metadata Tools (User Guides) - SageTV App (Android) - SageTV Plex Channel - My Other Android Apps - sagex-api wrappers - Google+ - Phoenix Renamer Downloads SageTV V9 | Android MiniClient |
#20
|
||||
|
||||
Quote:
Davephan - When Java was originally introduced it was severely slow. It's matured significantly since then, and is very competitive with other languages on speed. C# is largely a wash, and while C and C++ can be faster in certain ways the difference is not terribly significant for a large interactive application (as opposed to a small number-crunching benchmark). You could even argue that it frequently can be faster than C/C++ because you don't have to be as skilled a programmer to have fast, optimized code. Cheers, Slipshod
__________________
SageTV V7 (WHS), Diamond UI Server: WHS with Xeon X3350, 4GB ECC, ASUS P5BV-C/4L, recording into a 6.6TB Drive pool Tuners: 4 (2x HDHR) Clients: 2x HD300, 1x HD200 Extenders, 1x Placeshifter 2x Roku XD |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Who is in charge here? HDHR, Sage or My New Location. | camus | SageTV EPG Service | 4 | 03-13-2008 03:01 PM |
Important Version 6 Upgrade Information | Narflex | SageTV Beta Test Software | 449 | 01-18-2008 07:17 PM |
Microsoft to charge per commerical skipped! | judoGTI | The SageTV Community | 10 | 10-12-2005 11:14 AM |
Need help designing a solution | Brian | Hardware Support | 4 | 11-16-2004 12:19 AM |
If Sage needed to charge a small monthly EPG fee, would you pay it. | mdmint | SageTV EPG Service | 75 | 11-04-2004 10:32 AM |