SageTV Community  

Go Back   SageTV Community > SageTV Development and Customizations > SageTV Github Development

Notices

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.

Reply
 
Thread Tools Search this Thread Display Modes
  #581  
Old 06-28-2015, 11:48 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
Quote:
Originally Posted by nyplayer View Post
I totally agree with you and I also do not see licensed users jumping to the OS anytime soon.... at least until EPG data is addressed in OS version.
This is just the opposite of my intentions. I mean, licensed users are the only ones who, at release, will HAVE EPG data in the OS version... I intend to run it if nothing more than to provide support for others jumping in. Ultimately, I'd like to get Schedules Direct in there, but I will likely be switching much sooner than that.
__________________
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
Reply With Quote
  #582  
Old 06-28-2015, 11:49 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
A question i do have, is if sagex will be built in. It appears to be in use on Google Fiber, and I doubt it's via a neutered plugin system implementation.
__________________
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
Reply With Quote
  #583  
Old 06-29-2015, 05:44 AM
stanger89's Avatar
stanger89 stanger89 is offline
SageTVaholic
 
Join Date: May 2003
Location: Marion, IA
Posts: 15,186
Quote:
Originally Posted by nyplayer View Post
I totally agree with you and I also do not see licensed users jumping to the OS anytime soon.... at least until EPG data is addressed in OS version.
Jeff already said licensed users will have "native" (Sage/Google) EPG in the OS version via their [server] license key.

Quote:
Originally Posted by Monedeath View Post
Well, an update to support h265 on the server side would cause a problem for the extenders unless there is a way to update them as well, as already mentioned. But the solution for that is easy, don't record/transcode to h265 if you want to have native playback on the older extenders.
1) How would you record in H.265, no cards support it and no broadcasters use it.

2) Why would you transcode to it, you don't need H.265 for 1080p, not even remotely. For quite a while to come H.265 is just going to be a headache, unless you're talking 4K content.
Reply With Quote
  #584  
Old 06-29-2015, 07:00 AM
tmiranda's Avatar
tmiranda tmiranda is offline
SageTVaholic
 
Join Date: Jul 2005
Location: Central Florida, USA
Posts: 5,805
Quote:
Originally Posted by Slugger View Post
... As I've discussed else where, my Schedules Direct plugin won't work with the OS version of Sage as is. So to move to the OS version, I have to fix/rewrite my epg plugin or move back to the Sage epg (and lose features of my plugin I've come to take for granted)...
IMHO getting the SD EPG plugin to work is the first thing that needs to happen. A DVR without EPG data is useless.

I know you don't need it for your needs but the community does. What will it take to convince you to make the plugin work on the open source version? The community needs you Slugger
__________________

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.
Reply With Quote
  #585  
Old 06-29-2015, 08:40 AM
SHS's Avatar
SHS SHS is offline
Moderator
 
Join Date: Mar 2003
Location: Vinita, Oklahoma
Posts: 4,415
Quote:
Originally Posted by Wayneb View Post
If people have DVB-S2 cards, there has already been some H.265 broadcast on satellite, some newer cameras like the NX1 and NX500 from Samsung record in H.265.
Odd that though going become more practical in 2017-18.
Reply With Quote
  #586  
Old 06-29-2015, 09:16 AM
trk2 trk2 is offline
Sage Aficionado
 
Join Date: Jan 2006
Location: Maine
Posts: 341
Quote:
Originally Posted by Slugger View Post
And a year for something significant? I'd even suggest that's best case scenario. Let's assume Narflex has been working at prepping the code base for release since his announcement. That's a few months and no sign of an imminent release coming so he's still working on it. How long does it take the community OS devs to read and comprehend this code base before it can start to be modified meaningfully? And yes, he's definitely not working on it full time, but that's also a very important point. No OS devs are going to be working on features full time either. A feature that takes 3 weeks to implement, might take that person 6 months to complete if they can only work on it a few hours a week. That's going to be the reality of the OS version. So I'd agree a year after the code is available seems like a minimum for "major" new features unless there's an major influx of new devs wanting to join in, which hopefully there will be.
I suspect this might be a Google Friday project, which means Narflex is only on this roughly 20% of the time assuming no vacations.
Reply With Quote
  #587  
Old 06-29-2015, 09:34 AM
Monedeath Monedeath is offline
Sage Expert
 
Join Date: Sep 2009
Location: Idaho
Posts: 508
Quote:
Originally Posted by stanger89 View Post
2) Why would you transcode to it, you don't need H.265 for 1080p, not even remotely. For quite a while to come H.265 is just going to be a headache, unless you're talking 4K content.
Haven't tested it myself, as I don't use anything that can play back h265 encoded content without transcoding it back to something else. Which makes the effort somewhat pointless for me(and most others) right now. But there are claims out there that it has even more efficient compression than h264 does, so even smaller file sizes for the same quality of content. Some of the claims out there are of h265 encodes being up to half the size of their h264 counterparts.

So the reason is comparable to why people would transcode mpg2 recordings into h264 recordings a few years ago, even before the streaming set top boxes started dropping native mpg2 support.
Reply With Quote
  #588  
Old 06-29-2015, 10:21 AM
stanger89's Avatar
stanger89 stanger89 is offline
SageTVaholic
 
Join Date: May 2003
Location: Marion, IA
Posts: 15,186
Quote:
Originally Posted by Monedeath View Post
Haven't tested it myself, as I don't use anything that can play back h265 encoded content without transcoding it back to something else. Which makes the effort somewhat pointless for me(and most others) right now. But there are claims out there that it has even more efficient compression than h264 does, so even smaller file sizes for the same quality of content. Some of the claims out there are of h265 encodes being up to half the size of their h264 counterparts.
True but the gains get smaller and smaller as you decrease file sizes. H.264 (which is supported by everything) can get a 1 hour (45 minute) show that's 1080p down to 1GB (Netflix uses 3Mbps for "standard" 1080p), I've seen some stuff even less.

H.265 would only get that down to (after a few more years of encoder development improving efficiency) about 500MB. Compare that to MPEG 2, OTA broadcasts are (up to) 19.2Mbps, or about 9GB/hr about 7GB or so for a 45 minute show. H.264 is capable of more like a 85%+ reduction in storage.

My point is, H.265 is exciting and a big deal for UHD, and maybe even mobile streaming, but for home use? I just don't see the point of transcoding to that instead of (or from) H.264.
Reply With Quote
  #589  
Old 06-29-2015, 10:45 AM
hb4 hb4 is offline
Sage Advanced User
 
Join Date: Sep 2008
Location: Seattle, Wa
Posts: 172
Quote:
Originally Posted by Fuzzy View Post
I intend to run it if nothing more than to provide support for others jumping in.
Thank you for that. It will go a long way towards any general popularity of Sage going forward.
__________________
Server: AMD Phenom II, 4GB memory, Windows 7 Home Premium 64 bit, Sage 7.1 with Comskip
Capture: OTA; Comcast to HD-PVR, HDHR, HDHR Prime with Firmware version 20150826 and OpenDCT version 0.5.13 beta
Storage: 1Tb HD on Server, 2Tb Buffalo NAS
Network: Gb Buffalo Router, Gb 8-port Netgear Switch connected to Server, HD-200, NAS, HDHR, Prime, LAN
Playback: HD-200, Server to HDTV; Emby for off-site playback
Tech Level: Hobbyist
Reply With Quote
  #590  
Old 06-29-2015, 11:29 AM
wayner wayner is offline
SageTVaholic
 
Join Date: Jan 2008
Location: Toronto, ON
Posts: 6,579
IMHO the first thing would be to fix or improve the core of SageTV to bring it up to 2015 standards. That means supporting 64 bit Java and allowing you to run more than three extenders without the server throwing up. In the last few years the PC world has moved much more towards 64 bit so the application has certainly fallen behind on those fronts. Of course the downside to this is those of us that prefer to use Firewire for channel changing.

The other thing to fix is Placeshifter which has never worked properly with 1080i content - presumably this would also help streaming to all lightweight clients, including mobile.

The other thing to develop is mobile clients, that has also developed hugely since the Google acquisition. I would love to see a proper iPad client.
__________________
New Server - Sage9 on unRAID 2xHD-PVR, HDHR for OTA
Old Server - Sage7 on Win7Pro-i660CPU with 4.6TB, HD-PVR, HDHR OTA, HVR-1850 OTA
Clients - 2xHD-300, 8xHD-200 Extenders, Client+2xPlaceshifter and a WHS which acts as a backup Sage server
Reply With Quote
  #591  
Old 06-29-2015, 11:56 AM
aaronb aaronb is offline
Sage User
 
Join Date: Dec 2008
Posts: 69
Something I'd like to see in the beginning is improving on the transcoding options and speed. I never got MediaShrink to work the way I wanted it to, and the transcoding withing Sage had limited options, and doesn't max out my CPU so it's quite a bit slower than doing things manually in Handbrake. The latter works just fine, and by maintaining the file names I am able to keep everything within Sage with metadata etc, but it requires the additional manual work.
__________________
Server:
Rosewill RSV-L4411 server case, Core i5 4590, 16 GB RAM, 1 Hauppauge Colossus, 1 HDHomeRun, 500GB SATA recording drive, 14 TB JBOD for media, SageTV 7, Win7 Pro, Ubuntu 14.04 VM with Plex Server and Subsonic

Frontend:
ASUS Chromebox running Kodi with SageTV add-on
Reply With Quote
  #592  
Old 06-29-2015, 02:37 PM
Slugger Slugger is offline
SageTVaholic
 
Join Date: Mar 2007
Location: Kingston, ON
Posts: 4,008
Quote:
Originally Posted by tmiranda View Post
IMHO getting the SD EPG plugin to work is the first thing that needs to happen. A DVR without EPG data is useless.

I know you don't need it for your needs but the community does. What will it take to convince you to make the plugin work on the open source version? The community needs you Slugger
A few things:

First, I don't think a plugin is the right way to go now that we know new open source users are locked out of the Sage EPG server. Schedules Direct needs to be made a first class citizen of the core, so to speak. The plugin's architecture uses a 3rd party library and application (that I wrote, but that's irrelevant) to pull and access the EPG data externally and then Sage accesses it thru the external source via the 3rd party APIs. The architecture of it all fits the plugin model quite nicely, but isn't the way I'd do it for this open source approach.

Second, I'm just not all that excited about going down this road again. I might get there, but I'm just not there yet. I feel like I conquered this project a few years back and I don't have the desire to climb this mountain again. My setup is not 100% perfect, but pretty darn close. So close, in fact, I haven't updated anything on my server in ~3.5 years except for upstream fixes to keep my epg plugin compatible with Schedules Direct. If I were to upgrade to the OS version and wanted to write some code, rewriting stuff I've already written doesn't excite me. I'd definitely want to dive into new areas so at the very least, reimplementing the Schedules Direct APIs within Sage just isn't going to get me excited. It actually has the opposite effect. I'd be more than willing to share my thoughts and experiences working with the APIs within Sage with others, but I just can't see myself redoing what I've already done, especially when what I've already done does what I want.

Third, as per my annual policy, I'm on personal project hiatus until the fall. As a matter of fact, I'm heading north out of cell range and no inet access for a few weeks here shortly. The earliest I would commit to even starting on anything would be probably after (Canadian) Thanksgiving (so mid October).

Finally, my personal projects have changed over the last few years. From 07-12 it was mostly, if not exclusively, SageTV stuff. Since then, I've found other projects of interest. Not that there's no room for new Sage projects, it's just that there's less room. And there's less time for those projects. And when there is time, sitting up all night writing code is a lot less attractive an idea in my 30s than it was in my 20s. I used to do it for work & play, but now I'd be hard pressed to remember the last time I had such a marathon coding session. I like to think I code smarter these days, which I'm sure is somewhat true, but mostly it's just 16 hours of coding just doesn't do it for me anymore. 8 hours at the office is enough.
__________________
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...

Last edited by Slugger; 06-29-2015 at 02:39 PM.
Reply With Quote
  #593  
Old 06-29-2015, 02:56 PM
stanger89's Avatar
stanger89 stanger89 is offline
SageTVaholic
 
Join Date: May 2003
Location: Marion, IA
Posts: 15,186
Quote:
Originally Posted by Wayneb View Post
Netflix streaming uses about a third of all the downstream traffic at peak periods, why wouldn't they want to halve their bandwidth usage?
I'm sure Netflix will care, I don't see why I will for my own local media, or anything I will ever conceivably play through Sage.

Quote:
Originally Posted by Slugger View Post
First, I don't think a plugin is the right way to go now that we know new open source users are locked out of the Sage EPG server. Schedules Direct needs to be made a first class citizen of the core, so to speak. The plugin's architecture uses a 3rd party library and application (that I wrote, but that's irrelevant) to pull and access the EPG data externally and then Sage accesses it thru the external source via the 3rd party APIs. The architecture of it all fits the plugin model quite nicely, but isn't the way I'd do it for this open source approach.
I still don't really understand the problem with the EPG being a plugin, it seems like a natural, elegant solution. Install Sage, setup the EPG grabber that best suits your needs. If you need XMLTV, use that, if you want SD, use that, if you're somewhere that provides EIT data, you don't need to set anything up.

Sure, we could probably update the setup wizard, or the new source wizard to make things easier/more obvious for new users, but that's an STV issue (and could be done, OS or not), and I don't really see what building it into the core gets us.
Reply With Quote
  #594  
Old 06-29-2015, 04:45 PM
Slugger Slugger is offline
SageTVaholic
 
Join Date: Mar 2007
Location: Kingston, ON
Posts: 4,008
Quote:
Originally Posted by stanger89 View Post
I'm sure Netflix will care, I don't see why I will for my own local media, or anything I will ever conceivably play through Sage.



I still don't really understand the problem with the EPG being a plugin, it seems like a natural, elegant solution. Install Sage, setup the EPG grabber that best suits your needs. If you need XMLTV, use that, if you want SD, use that, if you're somewhere that provides EIT data, you don't need to set anything up.

Sure, we could probably update the setup wizard, or the new source wizard to make things easier/more obvious for new users, but that's an STV issue (and could be done, OS or not), and I don't really see what building it into the core gets us.
Reimplementing it as a plugin could also work. Either way, my plugin needs modifications to work with the OS version of the Sage jar, that's a given. The plugin today uses an external app to pull down your epg data into an external data source (zip file) and then there's plugin code to get the data from that zip file into wiz.bin.

The plugin is "ok". You have to install the plugin and restart Sage even though the plugin manager won't tell you a restart is needed (because the plugin mods your Sage.props file out of necessity). So there are manual steps that aren't elegant. Uninstalling is even worse because you have to manually modify the Sage.props file to undo the installation changes because there's no event to detect an uninstall of a plugin so removing the plugin is also manual and if you don't mod Sage.props then you end up with no epg access and so on. It works, I wouldn't call it the best solution. It could be done better, that's all I'm saying. Either integrate it into the core or add some extra events to allow better automated install/uninstall, etc. But I'd also like to remove the extra zip file of cached epg data hanging around. You're basically storing the epg twice. And yes it's only 50MB in the zip file, etc. but I'm just saying if I had to rewrite the plugin (which will need to be done to get it to work with the Sage8 jar) then I'd probably just scrap it and do something different. But as it stands, my preference is to just stick with 7.1.9.
__________________
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...
Reply With Quote
  #595  
Old 06-29-2015, 10:34 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,957
Quote:
Originally Posted by stanger89 View Post
I'm sure Netflix will care, I don't see why I will for my own local media, or anything I will ever conceivably play through Sage.



I still don't really understand the problem with the EPG being a plugin, it seems like a natural, elegant solution. Install Sage, setup the EPG grabber that best suits your needs. If you need XMLTV, use that, if you want SD, use that, if you're somewhere that provides EIT data, you don't need to set anything up.

Sure, we could probably update the setup wizard, or the new source wizard to make things easier/more obvious for new users, but that's an STV issue (and could be done, OS or not), and I don't really see what building it into the core gets us.
The main reason, I see to put it IN the core, is because the core should be able to serve 90% of it's users basic needs out of the box. That means interfacing with current tuners, and providing proper EPG data. It should be able to be up and running for most users just from going through the initial setup wizard, which currently happens before any plugins are usually installed. Schedules Direct provides data for almost all potential sagetv users around the world. If it is going to be rewritten from scratch, then it makes sense to write it in the way that serves the most users, which an option in the core is the way to go.
__________________
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
Reply With Quote
  #596  
Old 06-30-2015, 06:17 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,541
Quote:
Originally Posted by Fuzzy View Post
The main reason, I see to put it IN the core, is because the core should be able to serve 90% of it's users basic needs out of the box. That means interfacing with current tuners, and providing proper EPG data. It should be able to be up and running for most users just from going through the initial setup wizard, which currently happens before any plugins are usually installed. Schedules Direct provides data for almost all potential sagetv users around the world. If it is going to be rewritten from scratch, then it makes sense to write it in the way that serves the most users, which an option in the core is the way to go.
I think we might be hung up on the notion of plugins vs packaging. I agree that the packaging should include what 90% of people might use, out of the box, but just because we want it to be out of the box, doesn't mean it can't also be a plugin. If you are familiar with Eclipse (development IDE) they offer several "packages" depending on your needs. Everything is still a plugin, but depending on the package, you'll get a different out of the box setup.

So, consider if will, an open source "package" for SageTV might include the core, jetty server, comskip, and fanart, where jetty, comskip and fanart are simply bundled plugins, but they are included with the package to simplify installation and user choices.

Another benefit of plugin vs embedded into core, is that anything that is a plugin can evolve and be updated independently of the core. Android, for example, has gradually moved from a monotlithic "core" to using separately installable apps to simplify the release of new feature and bug fixes without having to replace the core. ie, updating a "core" is generally a slow release cycle but updating a specific "plugin" can be a faster release cycle.

So, in short, I think there are many things that I'd like to see "out of the box", but out of the box doesn't necessarily mean it has to be in the "core" codebase, just in the main packaging.
Reply With Quote
  #597  
Old 06-30-2015, 06:26 AM
tmiranda's Avatar
tmiranda tmiranda is offline
SageTVaholic
 
Join Date: Jul 2005
Location: Central Florida, USA
Posts: 5,805
Quote:
Originally Posted by stuckless View Post
So, consider if will, an open source "package" for SageTV might include the core, jetty server, comskip, and fanart, where jetty, comskip and fanart are simply bundled plugins, but they are included with the package to simplify installation and user choices.
This is exactly what I was thinking. I really like the plugin architecture because it's so flexible. I like the idea of packaging Sage with hte most common plugins "installed" already.
__________________

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.
Reply With Quote
  #598  
Old 06-30-2015, 07:17 AM
stanger89's Avatar
stanger89 stanger89 is offline
SageTVaholic
 
Join Date: May 2003
Location: Marion, IA
Posts: 15,186
You wouldn't necessarily even need to bundle them, or package them, you could just update the install/setup wizard to automatically (or automatically ask) to install a given set of plugins.

Add a step, before you setup sources, asking if you want to install/configure Schedules Direct, for example.
Reply With Quote
  #599  
Old 07-01-2015, 02:09 PM
lobosrul's Avatar
lobosrul lobosrul is offline
Sage Expert
 
Join Date: Aug 2005
Location: Albuquerque, NM
Posts: 573
Quote:
Originally Posted by stanger89 View Post
True but the gains get smaller and smaller as you decrease file sizes. H.264 (which is supported by everything) can get a 1 hour (45 minute) show that's 1080p down to 1GB (Netflix uses 3Mbps for "standard" 1080p), I've seen some stuff even less.

H.265 would only get that down to (after a few more years of encoder development improving efficiency) about 500MB. Compare that to MPEG 2, OTA broadcasts are (up to) 19.2Mbps, or about 9GB/hr about 7GB or so for a 45 minute show. H.264 is capable of more like a 85%+ reduction in storage.

My point is, H.265 is exciting and a big deal for UHD, and maybe even mobile streaming, but for home use? I just don't see the point of transcoding to that instead of (or from) H.264.
As far as digital encoding schemes go, anything can be brought down to whatever file size the encoder wants. 1080p at 3Mbps h.264 looks like crap for anything other than animation.

I've seen head to head screen caps of itunes video comparing 1080p at 5Mbps to 720p at 4Mbps. Usually there is more detail in the 720p screencap.

With disk storage as cheap as it is, no there is no point in converting from h.264 to h.265, especially since no current h.264 encoder is better than x264 at the moment anyways.

Also, Netflix 1080p is3GB per hour or about 6 to 7Mbps.

https://help.netflix.com/en/node/87

Last edited by lobosrul; 07-01-2015 at 02:14 PM.
Reply With Quote
  #600  
Old 07-01-2015, 02:41 PM
stanger89's Avatar
stanger89 stanger89 is offline
SageTVaholic
 
Join Date: May 2003
Location: Marion, IA
Posts: 15,186
Quote:
Originally Posted by lobosrul View Post
Also, Netflix 1080p is3GB per hour or about 6 to 7Mbps.
Their "SuperHD" is, but "regular" 1080p is closer to 4Mbps (or at least was):
http://blog.streamingmedia.com/2013/...-everyone.html

Quote:
With disk storage as cheap as it is, no there is no point in converting from h.264 to h.265, especially since no current h.264 encoder is better than x264 at the moment anyways.
That was really my point though. You can get already 1080p ridiculously small if you want, with h.264. At some point h.265 will become common, but it will be for streaming and UHD. Neither of those are a foreseeable concern for a SageTV extender. So I'm not at all worried about it as far as my HD300's go.

Last edited by stanger89; 07-01-2015 at 02:46 PM.
Reply With Quote
Reply

Tags
open source


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
SageTV Setup "Video Source Capture" Problem Mandingo609 Hardware Support 6 01-04-2011 08:05 AM
"Backdrops" "SageTV" "Covers" folders - what's creating them mp328 Sage My Movies 4 09-20-2010 05:31 PM
Can I use "Send To..." to open a file with another player? horseflesh SageMC Custom Interface 0 12-23-2008 04:23 PM
Any plan adding a ""unsupported" Closed Caption on the HD-100 in future update? TechBill SageTV Media Extender 5 08-16-2008 08:58 AM
Open "Browse - Video Menu" First lambda379 SageTV Studio 2 09-02-2007 12:37 PM


All times are GMT -6. The time now is 10:18 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.