Come Back to SageTV - Open Source in "Near" Future

[Fuzzy]

Originally Posted by nyplayer

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.

[Fuzzy]

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.

[stanger89]

Originally Posted by nyplayer

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.

Originally Posted by Monedeath

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.

[tmiranda]

Originally Posted by Slugger

... 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

[SHS]

Originally Posted by Wayneb

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.

[trk2]

Originally Posted by Slugger

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.

[Monedeath]

Originally Posted by stanger89

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.

[stanger89]

Originally Posted by Monedeath

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.

[hb4]

Originally Posted by Fuzzy

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.

[wayner]

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.

[aaronb]

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.

[Slugger]

Originally Posted by tmiranda

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.

[stanger89]

Originally Posted by Wayneb

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.

Originally Posted by Slugger

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.

[Slugger]

Originally Posted by stanger89

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.

[Fuzzy]

Originally Posted by stanger89

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.

[stuckless]

Originally Posted by Fuzzy

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.

[tmiranda]

Originally Posted by stuckless

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.

[stanger89]

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.

[lobosrul]

Originally Posted by stanger89

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

[stanger89]

Originally Posted by lobosrul

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

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.