![]() |
|
SageTV Github Development Discussion related to SageTV Open Source Development. Use this forum for development topics about the Open Source versions of SageTV, hosted on Github. |
![]() |
|
Thread Tools | Search this Thread | Display Modes |
#1
|
||||
|
||||
![]()
I there is a discussion going on over in the SageTV Plugin Issues thread about issues with some plugins, but I'd this area to focus on how to we can change/enhance the plugin system.
Here are my thoughts... I like the SageTV plugin model, but there are definately some things that I'd like to change
Tom's List
Greg
jars added as dependencies not plugins I think plugins should register their dependencies, as they do now, BUT, dependency .jar file files DO NOT have to be in the "SageTV plugin repository". Instead, jar files, would be downloaded via jcenter or maven central, on demand. MANY of the plugins that are in the SageTV plugin repository are in fact just repackaged jar files, etc, and it's quite tedious to update them ![]() When multiple plugins depend on the same .jar dependency and they specify different versions, then the latest version is selected. IFa plugin specifies a Max Version for their jar dependency and the version that is selected is greater than their Max Version, then the plugin depending on the lesser version is disabled. We can probably notify the user at the time that they try to install the plugin that doing so would disable another plugin because of a version issue. The goal here is to streamline the usage of .jar file dependencies and to make it consistent with existing java dependency models that are used in gradle, maven, ivy, etc, and it would turn make it easier for developer to manage their "real" plugin instead of a bunch of .jar files. plugins get their own plugin directory This is minor thing, but plugins have other related artifacts, and as such, I think that each plugin should be extracted into a separate plugin directory, and their artifacts contained in there as well. Plugins have the concept today of a resource area, but its optional, and there is no enforcement that a plugin actually use it. personally I'd like to see the plugin api extended with api calls for getCacheDir(), etc, that would return a cache specific location for a Plugin (probably under their plugin dir). In this way, cleaning up a plugin, and then mess of files they may leave behind, would be trivial... The plugin manager would delete the Plugin specific directory on removal. plugins jars loaded OUTSIDE of sagetv JARs I'd like dependency jar files to be put in a shared area, maybe, "JARsDEP". Plugins that ship a jar file as part of their activator would actually live in the plugin's specific directory. In no cases would I want to see anything actually contribute jar files to the main JARs area. SageTV JARs would always be loaded FIRST in the classpath and cannot be overridden. The plugin manager might actually validate this. multiple plugin repositories (ability to add repository URLs) Currently SageTV uses a single Plugin xml for all plugins plus a developer plugin xml. I'd rather see the ability to register multiple plugin repositories and sagetv would build a plugin xml from all the sources, in order. In that way developers could provide beta plugin repositories to users and simplify the process of testing/sharing plugins. Simplified plugin manifest I find it tedious to manage a Plugin's manifest. I'm not sure about the what to do about it... but I think I'd like to see a simplified model for building the manifest, etc. (And maybe this wouldn't such an issue, if all the .jar files are removed as plugins and treated as dependencies) Ability to publish using non-interactive means Today the publishing process for adding a new plugin or updating a plugin is very interactive with emails being used to validate, etc. I'd like to move to a more streamlined approach whereby a build system can actually publish plugins directly (as is done is most Maven projects). This makes it easy to keep plugins up to date. Personally the biggest reason I don't my plugins, very often, is the hassle of having to do it interactively. Ability to turn off MD5 checksum I think the MD5 check is great, but I also think it should be optional. There have been a few times when a remote system has somehow changed the MD5SUM of my jar, but, the jar file iteself has been fine. I think they were adding a signature to the file, which changes the MD5. I'd like the ability to "force" an install if that happens. Scriptable (Jython, Groovy, JavaScript) plugins Today, a plugin class has to be a Java class, and I'd like the ability to provide a Plugin class as JavaScript, Python, or Groovy.... with the requirement being that such a plugin would have to also dependon jython, groovy, etc. This would make it easier for non-java developers to contribute plugins using other scriptable languages. Once scripts are loaded in java, they are compiled and run as byte code, so there is not real performance issue for not doing this. API to register new SageTV apis that are plugin scoped It would cool if plugins could register SageTV API commands to the core SageTV. Plugins can kinda do this today, simply by being class file with static methods (I auto generate these classes in Phoenix), but it might be handy if plugins could simply register their API command, much like how sagetv does it internally. This would also enable scriptable plugins to register new APIs. The Plugin's start() method could actually manually register whatever APIs they want, and sagetv would auto-remove them when the plugin is deactivated. Who is going to "host" Google has already said that they are not going to release an open source product, and I'm wondering how plugins are going be managed, moving forward. ie, Do we still submit them like we do today, or should we go ahead with the Multi repository approach and we start to move away from the google hosted plugins? Do we care about S7 plugin compatibility? I think the question says it alll, but I'm curious as to whether or not S7 plugin compatibilty is an issue. ie, I think we'll be able to load S7 plugins, but, should we care if S9 plugins are compatible with S7?
__________________
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 Last edited by stuckless; 08-19-2015 at 05:03 AM. |
#2
|
||||
|
||||
I feel the JARs as dependencies and not plugins might be a bit further than we need to go. If a plugin is manifested ideally, any jar's it depends on would be in a separate 'library' manifest, and would show up in a different section of the plugin manager. We might simply hide that tab in the manager by default. This would at least keep version tracking the same between STVI's, JARs, etc., all being within the same manifest system.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#3
|
||||
|
||||
Regarding S7 compatibility, if we do things right, I don't see a reason to focus too heavily on any new development working on the old versions. Upgrading SHOULD be painless, and free, once we work out the launchers and installation mechanics. I believe the only S7 functionality that isn't currently working on S9 is the SD EPG, which I believe Andy was going to be looking at in the near term. Once that is working, I don't see any reason for anyone to stay on S7, and that would get most the 'customers' on the same codebase.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#4
|
||||
|
||||
With multiple potential plugin manifests, it will likely be more of an issue actually keeping track and advertising what plugin sources are available. One option is to actually maintain the manifests (which are nothing more than xml files) in the git itself. This would of course require more people to be authorized to merge in pull requests, which would likely work if we branched 'master' development to a more community managed branch (instead of the google one which is only open to google employees).
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#5
|
||||
|
||||
Quote:
![]() Consider that with a typical Maven/Gradle/Ivy development environment where updating to a new dependency jar (and getting transitive jars) is as trivial as just changing the version number and re-run the build command. I tested 5 different versions of JOGL on the weekend in about 30 minutes, which is less time than it generally takes me to repackage a single jar file for SageTV plugin ![]()
__________________
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
|
||||
|
||||
Thanks for starting this thread. As somebody who has written a log of plugins I agree that some changes would be nice.
I would add to your list: - Right now a "General" Plugin can't contain an STVi component. This means if you want to have a plugin that uses the functionality available as a General (Standard) plugin and you want it to modify the STV, you need to make two plugins and have one as a dependency of the other. - When a plugin is uninstalled I'd like to see all of the dependencies that are not needed for other plugins removed too. I agree with most of what you have suggested and have a few comments: - I see no need to simplify the manifests. They are very straight forward now. - I think v9 should run v7 plugins but v9 plugins do not necessary have to work on V7. This is already taken care of by the MINVERSION tag in the manifest. - Mutiple repositories is something I've wanted for a long time. I think this can actually be done in the STV and may not require any core changes at all. I'll look at that in the next few days. - I don't understand the usefulness of registering plugin APIs with the core. Why would the core need to know this?
__________________
Sage Server: 8th gen Intel based system w/32GB RAM running Ubuntu Linux, HDHomeRun Prime with cable card for recording. Runs headless. Accessed via RD when necessary. Four HD-300 Extenders. |
#7
|
||||
|
||||
Quote:
I've added you 2 additions to the main post, since I fully agree with them. The simplify the manifest is probably closer to your second point. ie, simplify "what is a plugin". For jar files, maybe it's a matter that the "manifest" is IN the jar, and not a .jar + manifest in another zip... it's that type of stuff when I say "simplify". Quote:
Quote:
Phoenix works around this by auto-generating "API" stubs and then if you want to use them from the remote apis, you can EVAL them, (or use the phoenix auto-generated apis).
__________________
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've obviously never had to maintain the numbers of plugins that you two have, but I'm curious which part of maintaining the manifests is the difficult part? How much of the difficulty is the requirement to make changes via the web form? How much easier would it be if it was as simply as altering a line or two in the SageTVPlugins.xml file on the GIT instead?
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#9
|
|||
|
|||
I think it's tedium more than degree of difficulty. It's even more frustrating when everything you need already sits in an online repository that handles transitive dependency management, etc. (i.e. maven)
My biggest complaint about the plugin situation in Sage over the years is when I wrote something like SJQ, which depended on various Apache Commons jars, etc. So to deliver that plugin I first had to package up all those dependent jars as separate plugins. And these 3rd party plugins are nothing more than downloading the jar from maven, zipping it up, creating the xml manifest, finding another place on the internet to host this zip file and then submitting it for inclusion in the repo. If nothing else, why can't I just point to the jar file in maven as the download source? (This alone would be a massive improvement.) Then I discover that I'm using version n of commons-codec but someone else already delivered version (n - 1), but I need version n. So now I've got to beg that owner to update their plugin so that mine will work. Maybe they will, maybe they won't. Just as bad... later on I want to upgrade my plugin to use a newer version of commons-io but then I don't bother because that involves the tedium of zipping up a jar file, updating a manifest and resubmitting that plugin before I update my own plugin code, update that manifest and resubmit -- just as stuckless said, more times than not I just didn't bother. With maven, all of these external jar files are sitting in a repository already. Even better, there are tools that handle transitive dependencies among these jars. So I want to use Apache's fluent-hc client... I tell maven that and it knows that I also need Apache http-client, etc, etc. Done. I want to use the latest and greatest version in my next release? Change the fluent-hc client version in my build/manifest/whatever and that's it. I don't need to go zipping up jar files and resubmitting those ahead of time. Even better would be we store Sage plugins (at least the jars) as a maven repo itself. Tell the repo you want plugin-xyz then thru transitive properties it knows what other jars need to be pulled down with it. Not sure how feasible this actually is, but it just seems like we should be trying to leverage existing repositories (and all the features they bring) instead of having to rezip jar files on an ongoing basis. In the current system, I tend to punt on an update if I find that I need to repackage a bunch of 3rd party jar files as part of my planned update. In some cases, I just manually updated the jars on my own system, made my code change and dropped my new jar over the old one. Yes, I broke the plugin manager's state, but it saved me a tonne of work.
__________________
Twitter: @ddb_db Server: Intel i5-4570 Quad Core, 16GB RAM, 1 x 128GB OS SSD (Win7 Pro x64 SP1), 1 x 2TB media drive Capture: 2 x Colossus STB Controller: 1 x USB-UIRT Software:Java 1.7.0_71; SageTV 7.1.9 Clients: 1 x HD300, 2 x HD200, 1 x SageClient, 1 x PlaceShifter Plugins: Too many to list now... |
#10
|
||||
|
||||
Quote:
Code:
[sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml | grep stuckless | wc -l 28 [sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml | grep -i fuzzy | wc -l 10 [sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml | grep -i tmiranda | wc -l 37 [sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml | grep -i slugger | wc -l 60 ![]() But to answer you question, yeah, the web post is tedius... and I general skirt that process for updates using a script for but new plugins (jars)... it's building the manifest, creating the zip, and upload the zip "somewhere", then manually posting the web form, and waiting for the URL... and then of course if you have jar with transitive dependencies,then repeat for each jar, and then wait between posts for the email, or else they fail. Hosting our own zipped jar files, when maven already hosts them, just seems wrong. And, Maven hosts the md5s for each jar as well, etc. https://repo1.maven.org/maven2/org/a...mons-io/1.3.2/ I think that if i build a plugin, I need to specify the dependencies, but I don't think that I should be made to re-host all these dependencies, when they are already being hosts somewhere else. And, other people are free to use a newer version of a jar without having to have me manually upgrade it for them, just because they need to use a newer api. (Something that I've had happen about 10 times now) Leveraging maven central simplifies that process for everyone. And it could be done in a backward compatible way. ie, the <Dependency> tag could be ammended like.. Code:
<Dependency> <Plugin groupid="commons-io">commons-io</Plugin> <MinVersion>2.4</MinVersion> </Dependency> Code:
<Dependency> <Plugin>commons-io:commons-io:2.4</Plugin> </Dependency> ![]()
__________________
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 |
#11
|
||||
|
||||
FYI on the break down of different Plugin Package Types...
Code:
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort |uniq <PackageType>ChannelLogo</PackageType> <PackageType>JAR</PackageType> <PackageType>STVI</PackageType> <PackageType>STV</PackageType> <PackageType>System</PackageType> [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | wc -l 376 [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep JAR | wc -l 162 [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep STVI | wc -l 131 [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep System | wc -l 67 [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep ChannelLogo | wc -l 6 [sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep '>STV<' | wc -l 10
__________________
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 |
#12
|
||||
|
||||
I agree with creating plugin-specific directories. It would help keep the system organized and help the uninstaller clean them up, as well as help us create a class loader per plugin.
Getting rid of jar plugins is a good idea. However, I don't like the idea of plugins referencing the maven central repo or of having a shared jar directory for all plugins. Maven can be a headache and I think that should be limited to the developer's machine. I'd rather not introduce that on user's machines. The jars and other artifacts/resources should be built into the plugin's zip file and unzipped into the plugin-specific directory that's being proposed. This fits well with the plugin-specific directories. Both of these ideas would help minimize the problems of different plugins using different versions of the same dependency. Plugins should be isolated from each other as much as they are from the core. I like the idea of multiple plugin repositories. That would help developer and beta testing. Scripted publishing would be nice. I don't know whether to go with hosting it on a web server or on GitHub. If it's on GitHub I'd suggest having it under a different repo than the core. That would help with managing access to the repos. I don't think the MD5 problem will be an issue if everything is delivered in the plugin.zip file and that results in one entry in the plugin repository. As far as scriptable plugins, any JVM language is already supported. Are you talking about letting developers deliver the script source, then having the core compile them when the plugin is installed? I like the idea. That would lower the burden on developers delivering scripts. For API registration, do the sagex APIs "natively" support new APIs, or does the client have to put an eval into the URL? I think it would be great if the sagex APIs didn't need to be renegerated whenever the APIs change. A more dynamic implementation would make it a lot more flexible. Or maybe it already does this and I haven't kept up with it ![]()
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun. Extender: STP-HD300, Harmony 550 Remote, Netgear MCA1001 Ethernet over Coax. SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client, Java 1.6. Plugins: Jetty, Nielm's Web Server, Mobile Web Interface. |
#13
|
||||
|
||||
If the dependencies are already hosted elsewhere, you shouldn't have to host them yourself, just point the manifest to their otherwise hosted location. or am I missing something?
I'll be honest and say that I have absolutely no idea what Maven is - I was more trying to understand the insufficiency of the current system.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer) unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers. Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA. Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S Other Clients: Mi Box in Master Bedroom, HD-200 in kids room |
#14
|
||||
|
||||
It's not so much the hosting itself, it's more about dependency conflicts. I've worked on projects that use Maven and if dependencies of dependencies conflict it can be a real headache. I don't want somebody's Sage system to get that headache
![]()
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun. Extender: STP-HD300, Harmony 550 Remote, Netgear MCA1001 Ethernet over Coax. SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client, Java 1.6. Plugins: Jetty, Nielm's Web Server, Mobile Web Interface. |
#15
|
|||
|
|||
Quote:
Quote:
__________________
Twitter: @ddb_db Server: Intel i5-4570 Quad Core, 16GB RAM, 1 x 128GB OS SSD (Win7 Pro x64 SP1), 1 x 2TB media drive Capture: 2 x Colossus STB Controller: 1 x USB-UIRT Software:Java 1.7.0_71; SageTV 7.1.9 Clients: 1 x HD300, 2 x HD200, 1 x SageClient, 1 x PlaceShifter Plugins: Too many to list now... |
#16
|
||||||
|
||||||
Quote:
Today, we take jars, and wrap them in ZIP files. Code:
<Description>SageTV Dependency JAR Plugin for commons-io-1.4.jar - no need to download directly</Description> <Location>http://sourceforge.net/projects/sagetv-addons/files/3rd_party_libs/commons-io-2.4.zip/download</Location> Quote:
ie, I don't want to re-host already pre-built jars somewhere else. In terms of a maven repository, fundamentally it's nothing more than a http filesystem that has artifacts organized in a structured way, such that, tools like Mavan, Ant, Ivy, and a slew of other build tools can actually resolve artifacts. Quote:
Quote:
![]() Quote:
<ImplementationClass>MyPlugin.py</ImplementationClass> or <ImplementationClass>MyPlugin.js</ImplementationClass> Where the plugin would contina the .py/.js plugin implementation and by loaded like normal class. The first time loading, it would compile it. 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
|
||||
|
||||
Quote:
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun. Extender: STP-HD300, Harmony 550 Remote, Netgear MCA1001 Ethernet over Coax. SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client, Java 1.6. Plugins: Jetty, Nielm's Web Server, Mobile Web Interface. |
#18
|
||||
|
||||
Quote:
Regarding hosting plugins....many are hosted on download.sagetv.com. If you put your plugin on the semi-public FTP Server at download2.sagetv.com, then it automatically copies it over to download.sagetv.com for hosting after processing the manifest. Having to put JARs in ZIP files does sound annoying. ![]() And I recall originally not requiring JAR files to be in separate library plugins (and I'm pretty sure it's still not required)...but then everyone started doing that to deal with JAR conflicts between plugins...which seemed like a decent solution to the problem. I do understand a lot of the desire to change things here...as I haven't contributed any SageTV plugins that I can recall...so I don't see things from the other end. But definitely take a look through the current system first and get an understanding of how it functions internally; many changes may be a lot easier than you expect....or vice versa. ![]() I'm not against changing the system, I just want to be sure it's better for both users and devs in the end if that's done....and not break something that's currently *working*...because I know for sure it was a huge PITA building the whole plugin architecture in SageTV. ![]()
__________________
Jeffrey Kardatzke Founder of SageTV |
#19
|
||||
|
||||
Quote:
__________________
Server: Intel Core i5 760 Quad, Gigabyte GA-H57M-USB3, 4GB RAM, Gigabyte GeForce 210, 120GB SSD (OS), 1TB SATA, HD HomeRun. Extender: STP-HD300, Harmony 550 Remote, Netgear MCA1001 Ethernet over Coax. SageTV: SageTV Server 7.1.8 on Ubuntu Linux 11.04, SageTV Placeshifter for Mac 6.6.2, SageTV Client 7.0.15 for Windows, Linux Placeshifter 7.1.8 on Server and Client, Java 1.6. Plugins: Jetty, Nielm's Web Server, Mobile Web Interface. |
#20
|
||||
|
||||
Quote:
![]() ![]() 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 |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
PlayOn Plugin Linux Discussion | evilpenguin | SageTV v7 Customizations | 35 | 01-23-2013 12:18 AM |
Linux install problem, wrong architecture 'i386' | davephan | SageTV Linux | 40 | 03-25-2011 12:03 PM |
Architecture advice | rykr | Hardware Support | 4 | 10-27-2010 02:18 PM |
Multi-Task Architecture | glbrown | SageTV Software | 1 | 11-24-2003 04:34 PM |
SageTV Client<-> Master Architecture question | IVB | SageTV Software | 4 | 11-12-2003 08:00 PM |