Open source HD400

[Taddeusz]

The biggest problem I have with Emby is that it seemed like to do anything good with it you have to pay.

[stuckless]

Originally Posted by Taddeusz

The biggest problem I have with Emby is that it seemed like to do anything good with it you have to pay.

That is true for Plex as well... but I think the 99 lifetime fee is probably well worth it... I have a plex lifetime and a play on lifetime and I rarely use either... but it's hard to do continued development on a product when it's entirely free.

I haven't bought an Emby lifetime, yet... but I likely will.

[panteragstk]

Originally Posted by bialio

Plex's issue I think is that it is a transcoding first engine - I've never had any luck getting it to stream native content - it only 'works' when I let it transcode. It does a fine job transcoding if that's what you need. For most DVR-like locations (i.e. TVs in a permanent room in your house) it just isn't necessary to transcode, not with today's hardware.

btl.

I don't use it for recorded TV unless the kids are watching stuff, but I've never had an issue playing back native content at full resolution. Granted, I just use Plex for movies, but it's still odd that so many of you have that issue.

[dgeezer]

I'm also an emby user but only as a backend library manager for Kodi using the Emby for Kodi addon. I have Emby running as a docker on my unraid server. This way all my playback is set up to use native paths in emby. This means that playback is directly from the share and there is never any transcoding. Emby keeps track of watched status and adds new content to all my Kodi boxes at once.

I have been experimenting with TVHeadend and by pointing Emby at the recording directory, new shows appear in the regular TV Shows library menu. Even comskip works in Kodi with direct playback. I tried using Emby to get SageTV recordings into the Emby database by simply adding the SageTV recording directory, since SageTV can now add the season and episode numbers to the file name, but this didn't work. I think that each show still has to be in a separate directory.

[Fuzzy]

Originally Posted by drvnbysound

Sadly, I think you're 100% right but I also think a lot of that is also the inherent problem. There are a lot of people who are 1) unsatisfied with provider based systems and 2) want a centralized media center platform. As you explained, there are a bunch of communities and projects that do it. The problem is that they are all "developmental hobbies." I think that's where the limitation is. It can't grow into the mainstream home (LARGE userbase) because it's not those things you touched on, and the mainstream user doesn't want to tweak it on a regular basis.

I had been following Sage for a few years, and when I decided to pull the trigger I jumped on and tried to purchase a few HD200s to find that the Google buy-out had happened. After some dust had settled, I found used HD200s. I ran the server installer, connected some HDHRs, and HD-PVRs... and I was off. I really didn't touch anything else. It was solid.

For me too, the hardware extender was something that NONE of the other "projects" had. At the time, they either required a HTPC at each TV, or maybe some 3rd party hardware with some rooted software. The extender was a plug-and-play device - with a pretty nice remote that allowed it to be comparable to any other AV gear out there... not a one-off.

There is a gap filler between the 'unsatisfied with provider DVR and wanting a central media server' people and the lack of a 'just works' solution, and frankly, you, as an integrator, are it. Sagetv, once up and running, is a very stable ecosystem - just look through these threads on here about how many people are still happily running v6 and haven't touched the server in years, some not even aware anything even happened with the open sourcing of sagetv. While 'SageTV, LLC' no longer exists to provide support, you as an integrator can choose to do so, if you feel selling the configuration and maintenance of the product will work out well for you on the business front.

I will say this, the use of the Android client, which you are not all that familiar with, may be just what many of your customers want, mainly because it integrates netflix, youtube, and others into the same box, using the same very simplified remote. Combine that with an unRAID box that you configure and provide acting as the server, and you end up with a low maintenance, high reliability system.

[Fuzzy]

Originally Posted by stuckless

Isn't that what the Android App does now... Although I don't see SageTV app being an aggregator for other online content (outside of the existing play-on support that sagetv does today using tmiranda's plugin.).

Android TV itself, is a very good aggregator. A simple voice search can search through various supported apps to find the media you are looking for, and present it to you. The shortcoming is that not every app supports the search functionality, and sage is one of them. Part of this is because, being a miniclient, the android app doesn't really KNOW what all is in your library/database back on the server. This is nothing that is technically difficult, but would take extra processes on the client to communicate with the server and deal with those requests that a miniclient doesn't typically do.

An android full client, on the other hand, WOULD have all of this information, as it attains a continually updated local copy of the database. All of the devices we are discussing have more than enough hardware to run a full version of the client, instead of just a miniclient - but no work has actually been done - to my knowledge - to make this happen. I do believe that much of the work Stuckless has done on the media and UI rendering side would be portable over to a full sage client, but I have never done any sort of android development, so I'm not sure the level of undertaking it would require.

[Taddeusz]

Originally Posted by Fuzzy

An android full client, on the other hand, WOULD have all of this information, as it attains a continually updated local copy of the database. All of the devices we are discussing have more than enough hardware to run a full version of the client, instead of just a miniclient - but no work has actually been done - to my knowledge - to make this happen. I do believe that much of the work Stuckless has done on the media and UI rendering side would be portable over to a full sage client, but I have never done any sort of android development, so I'm not sure the level of undertaking it would require.

I don't think you would need a full copy of the database to use the Android search feature. I seriously doubt that Netflix keeps a whole copy of their catalog on your device. That's what a good web service is for so you don't need a local copy to do a search.

[Fuzzy]

Originally Posted by Taddeusz

I don't think you would need a full copy of the database to use the Android search feature. I seriously doubt that Netflix keeps a whole copy of their catalog on your device. That's what a good web service is for so you don't need a local copy to do a search.

Of course it wouldn't need it, and I did mention that a new process could be run along with the miniclient on the android device to deal with those queries to the server - however, the miniclient protocol does not allow those type of queries, so they would either need to be added, or the miniclient would need to use an external protocol like sagex.

My major point, however, was that there is really no technical reason to use a miniclient when the client device has the capability to run the full client. That is an architectural choice that was made for the MediaMVP and Placeshifter - one due to lack of client capabilities, the other for minimal client-side footprint and maximized portability, and simply carried forth to the newer generations of extenders. I don't desire the shift to a full client simply BECAUSE of the ability to do local queries, but the shift to a full client WOULD allow the queries to be done directly, instead of translated through a separate networked api. The full client is simply more capable, higher performing, and would offer far more capabilities to be added going forward (some things it could enable would be locally cached database allowing disconnected use, with synced local content; tighter system integration like the aforementioned google search, customized platform specific UI tweaks installed as part of the package, etc.)

[stuckless]

Originally Posted by Fuzzy

Of course it wouldn't need it, and I did mention that a new process could be run along with the miniclient on the android device to deal with those queries to the server - however, the miniclient protocol does not allow those type of queries, so they would either need to be added, or the miniclient would need to use an external protocol like sagex.

My major point, however, was that there is really no technical reason to use a miniclient when the client device has the capability to run the full client. That is an architectural choice that was made for the MediaMVP and Placeshifter - one due to lack of client capabilities, the other for minimal client-side footprint and maximized portability, and simply carried forth to the newer generations of extenders. I don't desire the shift to a full client simply BECAUSE of the ability to do local queries, but the shift to a full client WOULD allow the queries to be done directly, instead of translated through a separate networked api. The full client is simply more capable, higher performing, and would offer far more capabilities to be added going forward (some things it could enable would be locally cached database allowing disconnected use, with synced local content; tighter system integration like the aforementioned google search, customized platform specific UI tweaks installed as part of the package, etc.)

I've done this both ways... ie full database locally and using sagex... and to be honest, the only advantage that I see for a local client is really for a disconnected scenario, and being able to search. But, if disconnected, you still wouldn't be able to play anything. The complexities of keeping a remote database in sync would tip me to using sagex, unless, there was some reason to actually need a disconnected database, that I'm unaware of.

Under the sagetv client model, it might actually run slower than the miniclient, on Android. Having to keep the Wiz.bin in memory would certainly be a challenge. Now, if you were looking to use sqlite db and do a full sync, and then use native android widgets, yeah, it would be much faster... but again, not sure you need the database fully synced... I doubt plex syncs the entire database locally, since, in most cases without access to the server, the database has very little value.

A couple years back... i started an Android TV project for sagetv that did have the synced database, recommendations, and integrated search. I gave up on it... mainly because sagetv was going away (hadn't be open sourced at that point), and, the player wasn't optimal for my liking.... but the parts for using recommendations and integrated search was all there an working.

https://github.com/stuckless/phoenix-app-ng

I think this type of app could be rolled into the miniclient, but, could also be a stand-alone app that provides recommendations and integrated search, and then either plays the content directly, or launches the miniclient with a command to connect and play a media file. This would require some tweaks the miniclient apis as well.

[jm9843]

Originally Posted by stuckless

I think this type of app could be rolled into the miniclient, but, could also be a stand-alone app that provides recommendations and integrated search, and then either plays the content directly, or launches the miniclient with a command to connect and play a media file. This would require some tweaks the miniclient apis as well.

A separate app ('SageTV Add-ons for Android TV') makes a lot of sense since the functionality is platform-specific to Android TV while the miniclient is sometimes used on Fire TV, generic Chinese boxes, etc. Any future attempts to support Android TV's TV Input Framework might also live there. I'd imagine playback would still be best left to the miniclient though.

[Taddeusz]

I personally don't understand the fixation with having a local copy of the database. The person developing an iOS app did the same thing. I don't see the point in showing all content when you're disconnected when you can't actually play it. It makes more sense to keep a database of and show only locally synced content when disconnected. It confuses users to display things they can't manipulate.

My personal opinion is that the database architecture used by SageTV is wasteful and not really very extensible. It may have not been that bad early on but I've recently seen a post from Jeff saying his wiz.bin is 250MB. That's always resident in memory. On a desktop system that might not be that bad but on other platforms is impossible. It's still ridiculous to be having that much data be resident all the time. If the worry is about latencies the UI has far more latency than having a non-resident OS cached database would introduce.

[Fuzzy]

I was not talking about new implementation to sync the database. I talking about compiling the existing client codebase for Android, with the Android specific rendering added in. The existing client code already has all the database sync and ui compositing code built in (it's all in sage.jar already), it simply deletes the local database on closing.

[wayner]

Originally Posted by Fuzzy

My major point, however, was that there is really no technical reason to use a miniclient when the client device has the capability to run the full client. That is an architectural choice that was made for the MediaMVP and Placeshifter - one due to lack of client capabilities, the other for minimal client-side footprint and maximized portability, and simply carried forth to the newer generations of extenders. I don't desire the shift to a full client simply BECAUSE of the ability to do local queries, but the shift to a full client WOULD allow the queries to be done directly, instead of translated through a separate networked api. The full client is simply more capable, higher performing, and would offer far more capabilities to be added going forward (some things it could enable would be locally cached database allowing disconnected use, with synced local content; tighter system integration like the aforementioned google search, customized platform specific UI tweaks installed as part of the package, etc.)

I really like having everything on the server side like you see with PS. It makes configuration much easier. I always get confused with clients for stuff like plugins as to what has to be installed on the client and what goes on the server. With PS it is a breeze - install it on a PC, run it, perhaps import settings and you are good to go. If any plugins are changed you don't have to worry about it. But on a client you also have to remember to install stuff on the client.

[stuckless]

Originally Posted by Fuzzy

I was not talking about new implementation to sync the database. I talking about compiling the existing client codebase for Android, with the Android specific rendering added in. The existing client code already has all the database sync and ui compositing code built in (it's all in sage.jar already), it simply deletes the local database on closing.

The challenge here is that SageTV relies pretty heavily on AWT (even the placeshifter java code that I started from relies heavily on it), and Android doesn have any AWT support. In the Android MiniClient (which was a pretty small codebase), I had to create alternate AWT classes for these and provide an implementation. Keep in mind AWT is not only used for rendering, but also classes like Color, Font, Dimension, Rectangle, etc, are all AWT classes and sagetv relies pretty heavily on these, even if it's not rendering to a UI. The native image loading would also have to be compiled and brought over as well.

The sagetv thick client could be ported to Android, but, it would take quite a bit of effort In fact, I'd say it's almost as much effort to bring over the client as it is to bring over the server, since they are very intertwined.

[EnterNoEscape]

Originally Posted by wayner

I really like having everything on the server side like you see with PS. It makes configuration much easier. I always get confused with clients for stuff like plugins as to what has to be installed on the client and what goes on the server. With PS it is a breeze - install it on a PC, run it, perhaps import settings and you are good to go. If any plugins are changed you don't have to worry about it. But on a client you also have to remember to install stuff on the client.

In my opinion this has always been a strength of SageTV and one of the things that bugs me most about solutions are mostly just a client (like Kodi). I can see how this can be argued in a few directions, but when I apply an update I don't want to visit every single client in my house or script it to update on every client. I try to keep my general maintenance efforts low and simple since I'm supposed to be enjoying my setup, not constantly maintaining it.

[Narflex]

Originally Posted by stuckless

The challenge here is that SageTV relies pretty heavily on AWT (even the placeshifter java code that I started from relies heavily on it), and Android doesn have any AWT support. In the Android MiniClient (which was a pretty small codebase), I had to create alternate AWT classes for these and provide an implementation. Keep in mind AWT is not only used for rendering, but also classes like Color, Font, Dimension, Rectangle, etc, are all AWT classes and sagetv relies pretty heavily on these, even if it's not rendering to a UI. The native image loading would also have to be compiled and brought over as well.

The sagetv thick client could be ported to Android, but, it would take quite a bit of effort In fact, I'd say it's almost as much effort to bring over the client as it is to bring over the server, since they are very intertwined.

Actually...SageTV doesn't really rely on AWT much at all. I put in LOTS of effort over the years to get that dependency out of there. There was no AWT in the JVM that we run on the HD300...but yes, it was built from a slightly different codebase. The majority of the AWT dependencies can actually just be stubbed out....the only ones that replacements are really needed for are Color (which are very simple uses) Dimension & Rectangle. You don't need any AWT image/font stuff because all of that is already replaced. The placeshifter client had dependencies because of the one you ported from...but the C miniclient we used on our extenders didn't have any AWT of course.

[stuckless]

Originally Posted by Narflex

Actually...SageTV doesn't really rely on AWT much at all. I put in LOTS of effort over the years to get that dependency out of there. There was no AWT in the JVM that we run on the HD300...but yes, it was built from a slightly different codebase. The majority of the AWT dependencies can actually just be stubbed out....the only ones that replacements are really needed for are Color (which are very simple uses) Dimension & Rectangle. You don't need any AWT image/font stuff because all of that is already replaced. The placeshifter client had dependencies because of the one you ported from...but the C miniclient we used on our extenders didn't have any AWT of course.

I've actually looked at this quite a bit... there are about 100 references to java.awt throughout the codebase, and changing all those is no small task (although I had to do it for the code I used in the MiniClient).

Part of the challenge is that sagetv is a monolithic source structure with several different projects (shared code, server only code, client only code, placeshifter only code), but all that is really intermingled. Even the sage startup is references Swing/Awt. It doesn't matter if it's not used, but, I can't compile it for Android since those classes don't exist.

I think a first step would be to actually restructure the code into multiple projects, shared, server, client, and placeshifter, having awt/swing code in the client/placeshifter is not a problem, but it would have to be removed from shared/server portions.

My point being, that even thought there isn't alot of awt/swing, the way it's intertwined in the code does make it hard to abstract it out. For things like Color, Rectangle, Dimension, we can create drop in replacements, pretty fairly easy... Even MouseEvent and InputEvent could be done (I had to do those as well in the MiniClient -- Sage server uses the constants in those classes). Other things like the SageTVWindow and various other things would need to come out entirely and be put into a separate project so we would build a SageCommon.jar that has no dependencies on thos things.

[Narflex]

Originally Posted by stuckless

I've actually looked at this quite a bit... there are about 100 references to java.awt throughout the codebase, and changing all those is no small task (although I had to do it for the code I used in the MiniClient).

Part of the challenge is that sagetv is a monolithic source structure with several different projects (shared code, server only code, client only code, placeshifter only code), but all that is really intermingled. Even the sage startup is references Swing/Awt. It doesn't matter if it's not used, but, I can't compile it for Android since those classes don't exist.

I think a first step would be to actually restructure the code into multiple projects, shared, server, client, and placeshifter, having awt/swing code in the client/placeshifter is not a problem, but it would have to be removed from shared/server portions.

My point being, that even thought there isn't alot of awt/swing, the way it's intertwined in the code does make it hard to abstract it out. For things like Color, Rectangle, Dimension, we can create drop in replacements, pretty fairly easy... Even MouseEvent and InputEvent could be done (I had to do those as well in the MiniClient -- Sage server uses the constants in those classes). Other things like the SageTVWindow and various other things would need to come out entirely and be put into a separate project so we would build a SageCommon.jar that has no dependencies on thos things.

So I actually did this already. I basically just created stub classes for all of these things so it would compile/load properly and then for the couple that mattered I actually implemented them. If you want, shoot me an email and I'll send you all of that code (I have not been keeping it up to date because we ended up getting a VM for Google Fiber that had all of this stuff in there, but I needed it when we were evaluating options, so I can't promise it will still meet all the requirements...but it'd at least be very close).

And this was only done for SageTV server/client and NOT for the placeshifter.

[Monedeath]

Originally Posted by DarkWolf77

Yeah, I still don't get why plex is so awful at media playback. I've yet to be able to fast forward past commercials on the thing without the app locking up eventually and even if it didn't, using the current fast forward scheme on it is a crap shoot at best. Why is it so hard to give us thumbnail previews, or a hard X-second skip the way Sage does it (and have it WORK)? Doing a dvd-like fast forward with nothing but a time line on the screen is just painful.

Forget about asking for comskip support on the forum there. They look at you like you just asked them to put a man on the moon with nothing but a fork and a bit of string.

A big part of the issue here, in particular with SageTV recordings and Plex, is that most everything Sage Records is mpeg2 encoded. Most "new" devices only support h264 and/or h265. "Native mpeg2" isn't an option(but exceptions exist, like the Nvidia Shield, which is why its a preferred Sage Client platform). So when you're viewing something through a device using Plex, odds are very high it is having to transcode the video stream to h264 in order for to even display on that device.

Which is where things like fast forward, rewind, and what not start to break horribly on Plex. The strength that SageTV enjoyed in all of this was that it was playing the video back natively, no transcode required. As such skipping around is a lot easier to do, as there is a LOT less overhead involved in doing so.

It should be noted that Plex works a LOT better when you're trying to FF/REW on a h264 encoded program stream encoded at a resolution/framerate supported by the device you're viewing on.

[wayner]

My recollection is that Plex struggled with playback of SageTV H.264 .ts files from my HD-PVR as well, not just MPEG-2 files.