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

[stanger89]

Seems like we need a posting refresher:
https://www.youtube.com/watch?v=gx4EfoLzu_I

[hb4]

I'm a long time user of Sage and lurker on the Forum, and happy that this community has helped me to tweak and massage my setup of an HDPVR, HDHR, HDHR Prime enough to enjoy nearly trouble-free recording for 2-3 years now. I've been dreading the day when some part of the server PC fails and I have to start over.

With this announcement, it seems that I'll no longer need to log on every few weeks or so to find out what people find as an acceptable replacement once things go bonkers, but rather to find out what happens with the prospect of an open source solution. What a great outcome!

From my perspective, if in a year from now there is an open source version available that can easily be adopted by my not quite as willing to tinker family and friends, I will be a happy advocate and hope to convince a few to try it; if the cost is just hardware, that's great but not a deal breaker.

If a new version is created that fixes a few issues and add some new features, that's OK too. But a plug and play version will be the bees knees.

[Narflex]

Originally Posted by graywolf

Will SageTV going OS have an impact on the PlugIn Repository?

Would it still be hosted at http://download.sagetv.com/ (for many?)

How would the PlugIn Repository work and Who would take ownership?

just thoughts that popped into my head

There's no current plans to take the plugin repository down. If we were to do that; we'd give plenty of advanced notice.

Originally Posted by jchiso

I'm sure you mean it cannot play maximum-bitrate Blu-Ray video. Can an HD-300? Where does the HD-300 max out? I'm not being flippant, I don't have any Blu-Ray rips. My sources for hi-res test material are sites like this ...

I don't remember exactly....but I'm pretty sure we got it to play stuff in the 80-90 Mbps range just to feel really cool about ourselves.

[roymcd]

Great to hear that our patience has paid off. Well those who've stuck with Sage anyway. Thanks Jeff. Can't wait to see where this heads.

[zzmystique]

Had just about given up hope and was looking at alternatives - but there aren't any really... this news made my day, week and month

Thanks Jeff

[Fuzzy]

Originally Posted by Narflex

I still use SageTV at home...version 8.something. It's basically the same as the last v7 we put out; but with an updated STV and Sage.jar file that have new features that I wanted.

I'll have to drive over and check that version out.. :-)

[Fuzzy]

If we are able to get miniclient ported over to some light weight hardware (RPi, for instance), I'd love to see the capability for local storage worked in, with syncing to that storage based on a per favorite settings (like Plex's Sync feature). Would be perfect for my RV, and if it works well, the back seat of my truck! I miss having placeshifter running in my truck for the kids - but when I got a new vehicle, the old system didn't get ported in due to waning SageTV commitment.

[Fuzzy]

I'm not sure the move to 64-bit is entirely required - that may actually break a lot of direct hardware interaction done in the server instance (like many natively supported tuners). Breaking the process into it's tasks might actually make more sense, and be much more scalable.
1 - A separate process for the scheduler, that handles metadata, recording assets, conversion, and the media store.
2 - Each tuner could be managed by its own process (an expansion of the existing network encoder system). If each network encoder could handle it's own channel list and capabilities, and report that to the server in an autodiscovery system, this would be ideal - and would make future sources much more capable, and even allow a separate process that is entirely not-java to be used for this part. Could be made to work for non-linear sources as well. (This would ultimately be a rebirth/evolution of the old SageTVRecorder software)
3 - Each 'UI' is run as it's own process. Obviously, this is already the case for server's built-in client instance, and for pc clients - but currently all miniclient UI's are handled in the same process as the server, which is the real source of heap shortages. If when a miniclient requests connection from the server, it launches it's own UI handler process, this would eliminate that load on the heap.

overall, this might lead to an overall increase in memory footprint, as resources couldn't be shared between extenders, for instance - but the experience may be greatly improved by separating the processes out - and memory is cheap.

[BobPhoenix]

Originally Posted by Fuzzy

I'm not sure the move to 64-bit is entirely required - that may actually break a lot of direct hardware interaction done in the server instance (like many natively supported tuners). Breaking the process into it's tasks might actually make more sense, and be much more scalable.
1 - A separate process for the scheduler, that handles metadata, recording assets, conversion, and the media store.
2 - Each tuner could be managed by its own process (an expansion of the existing network encoder system). If each network encoder could handle it's own channel list and capabilities, and report that to the server in an autodiscovery system, this would be ideal - and would make future sources much more capable, and even allow a separate process that is entirely not-java to be used for this part. Could be made to work for non-linear sources as well. (This would ultimately be a rebirth/evolution of the old SageTVRecorder software)
3 - Each 'UI' is run as it's own process. Obviously, this is already the case for server's built-in client instance, and for pc clients - but currently all miniclient UI's are handled in the same process as the server, which is the real source of heap shortages. If when a miniclient requests connection from the server, it launches it's own UI handler process, this would eliminate that load on the heap.

overall, this might lead to an overall increase in memory footprint, as resources couldn't be shared between extenders, for instance - but the experience may be greatly improved by separating the processes out - and memory is cheap.

I like all of this. My thought however was that 64 bit might be easier to do than a rewrite like this. But this would be better in the long run.

[Fuzzy]

Originally Posted by BobPhoenix

I like all of this. My thought however was that 64 bit might be easier to do than a rewrite like this. But this would be better in the long run.

That's only if the move to 64 bit wouldn't break the interface with the drivers. You would most likely lose the capability of using directshow (64 bit apps can only access 64 bit directshow graphs, where there is far less codec support), so this would only really work for the service mode anyway, so now you're looking at compiling two ways, one for the service executable, and staying 32-bit for the local UI.

[valnar]

I still use nVidia DualTV tuners in PCI slots and have no idea if those require 32-bit or will work in 64-bit. I use a 32-bit version of Windows 7 so I didn't have to worry about it. It's not like my Sage Server needs more than 4GB RAM.

[Fuzzy]

The greatest thing, is that if we get enough momentum behind this, the 'network encoder' interface, which is really incredible simple, could be actually moved into the tuners themselves. SiliconDust could very easily add the interface system directly into an HDHomeRun for instance, so it would basically just auto-discover for the server. If we write up a proper network API document for it, then it could actually be something they (the hardware manufacturers) just write for, and we no longer have to even deal with it.

[bcjenkins]

64-bit would do well on Linux...

[Narflex]

Looks like it's respond to Fuzzy's post day.

Originally Posted by Fuzzy

If we are able to get miniclient ported over to some light weight hardware (RPi, for instance), I'd love to see the capability for local storage worked in, with syncing to that storage based on a per favorite settings (like Plex's Sync feature). Would be perfect for my RV, and if it works well, the back seat of my truck! I miss having placeshifter running in my truck for the kids - but when I got a new vehicle, the old system didn't get ported in due to waning SageTV commitment.

One thing many people may not be aware of is that the miniclient & the placeshifter use the same protocol to talk to the server. There's LOTS of variable features in that protocol; so they each utilize different features of it...but the fundamental are the same (this is evidenced by when you use the HD300 remotely as a placeshifter). The biggest difference is that the desktop placeshifter is written in Java and uses MPlayer for media playback; while the miniclient is written in C and uses native hardware decoders (i.e. SigmaDesigns) for playback.

Originally Posted by Fuzzy

I'm not sure the move to 64-bit is entirely required - that may actually break a lot of direct hardware interaction done in the server instance (like many natively supported tuners). Breaking the process into it's tasks might actually make more sense, and be much more scalable.
1 - A separate process for the scheduler, that handles metadata, recording assets, conversion, and the media store.
2 - Each tuner could be managed by its own process (an expansion of the existing network encoder system). If each network encoder could handle it's own channel list and capabilities, and report that to the server in an autodiscovery system, this would be ideal - and would make future sources much more capable, and even allow a separate process that is entirely not-java to be used for this part. Could be made to work for non-linear sources as well. (This would ultimately be a rebirth/evolution of the old SageTVRecorder software)
3 - Each 'UI' is run as it's own process. Obviously, this is already the case for server's built-in client instance, and for pc clients - but currently all miniclient UI's are handled in the same process as the server, which is the real source of heap shortages. If when a miniclient requests connection from the server, it launches it's own UI handler process, this would eliminate that load on the heap.

overall, this might lead to an overall increase in memory footprint, as resources couldn't be shared between extenders, for instance - but the experience may be greatly improved by separating the processes out - and memory is cheap.

There's certain thing you can't really separate out that well because of them sharing the same in memory database...but as we have a network sync architecture for that already; you could work around it. Network encoders are of course trivial, it's been done. The scheduler I wouldn't bother with...I'd just consider that to be part of the master process. Interestingly enough; the architecture we use on Google Fiber is a hybrid that we never used before. We do use the network encoder protocol on the server device and run SageTV in server mode there. Then on each of the client devices; we run Java in SageTVClient mode AND that instance of SageTVClient interacts with the miniclient running on the same device. So rather than having the miniclient talk to the SageTV Server directly. The miniclient talks to SageTVClient and that talks to SageTV Server. So this is essentially process separation at the UI level.

Originally Posted by Fuzzy

The greatest thing, is that if we get enough momentum behind this, the 'network encoder' interface, which is really incredible simple, could be actually moved into the tuners themselves. SiliconDust could very easily add the interface system directly into an HDHomeRun for instance, so it would basically just auto-discover for the server. If we write up a proper network API document for it, then it could actually be something they (the hardware manufacturers) just write for, and we no longer have to even deal with it.

I really like this idea. This would be far too cool if it actually happened.

[pjpjpjpj]

In my first post in this thread, I said my favorite thing was seeing all of the "old faces" coming back. My NEW favorite thing is all of Jeff's posts revealing "behind the scenes" info about stuff we've all wondered about for years. Heck, I don't even know anything about half of what he's talking about, but I still find it fascinating.

[BobPhoenix]

Originally Posted by valnar

I still use nVidia DualTV tuners in PCI slots and have no idea if those require 32-bit or will work in 64-bit. I use a 32-bit version of Windows 7 so I didn't have to worry about it. It's not like my Sage Server needs more than 4GB RAM.

According to nVidia they have 64 bit drivers for DualTV here: http://www.nvidia.com/object/dualtv_..._x64_2.02.html

[jreichen]

Originally Posted by pjpjpjpj

In my first post in this thread, I said my favorite thing was seeing all of the "old faces" coming back. My NEW favorite thing is all of Jeff's posts revealing "behind the scenes" info about stuff we've all wondered about for years. Heck, I don't even know anything about half of what he's talking about, but I still find it fascinating.

+1

[Fuzzy]

Originally Posted by Narflex

One thing many people may not be aware of is that the miniclient & the placeshifter use the same protocol to talk to the server. There's LOTS of variable features in that protocol; so they each utilize different features of it...but the fundamental are the same (this is evidenced by when you use the HD300 remotely as a placeshifter). The biggest difference is that the desktop placeshifter is written in Java and uses MPlayer for media playback; while the miniclient is written in C and uses native hardware decoders (i.e. SigmaDesigns) for playback.

I realize it's the same protocol - I actually would prefer most newer hardware ran more a version of SageTVClient than miniclient, as that would allow working with local media storage and still operate a much more complete UI without the server connection, and without all the UI composition needing to be done on the server. Most the hardware out there have FAR better processors and more RAM than the old MediaMVP, and should be able to handle more themselves.

Originally Posted by Narflex

There's certain thing you can't really separate out that well because of them sharing the same in memory database...but as we have a network sync architecture for that already; you could work around it. Network encoders are of course trivial, it's been done. The scheduler I wouldn't bother with...I'd just consider that to be part of the master process. Interestingly enough; the architecture we use on Google Fiber is a hybrid that we never used before. We do use the network encoder protocol on the server device and run SageTV in server mode there. Then on each of the client devices; we run Java in SageTVClient mode AND that instance of SageTVClient interacts with the miniclient running on the same device. So rather than having the miniclient talk to the SageTV Server directly. The miniclient talks to SageTVClient and that talks to SageTV Server. So this is essentially process separation at the UI level.

That SageTVClient instance on the server driving the miniclient UI is pretty much exactly what I was hoping for a long time ago to fix the heap limitations.

Originally Posted by Narflex

I really like this idea. This would be far too cool if it actually happened.

Before working with them, the network encoder protocol will likely need to pick up a version or two, to support more discovery - capabilities, channel list, instructions to instigate scans, etc should all be a part of the protocol, so that sage will no longer need to care about the actual hardware it's getting feeds from. Also, a new transport mechanism will likely be required, as currently, I believe the only way the current protocol works is by telling the encoder to record xxx channel to a specific URI - that may be harder for an HDHR or other device to do based mostly on more modern and more complicated network share permissions in current OSs, and instead it might be needed that the protocol can also direct the encoder to create an rtsp or similar stream that sage could then grab and write to it's storage (or even better, pass through a live transcoder if desired before writing to disk).

[waynedunham]

Originally Posted by pjpjpjpj

In my first post in this thread, I said my favorite thing was seeing all of the "old faces" coming back. My NEW favorite thing is all of Jeff's posts revealing "behind the scenes" info about stuff we've all wondered about for years. Heck, I don't even know anything about half of what he's talking about, but I still find it fascinating.

Absolutely agree 100%! It is great seeing old faces pop back up but especially nice to see Narflex's posting again!!

[wayner]

I am really interested in never having to worry about Java heap issues again - this is a big g problem for me as I have 9 extenders in my house HD200s and 300s plus a handful of 200s as spares). If this can be done without requiring 64 bit that would be all the better since I can keep using my existing server and can continue to use FireWire to change channels, assuming that you can still get a FireWire card for a modern PCS.