Philosophy for core vs plugins

[HelenWeathers]

narflex, stanger89, wayner etc have it right IMO.

Core should contain:

TV recording functionality
Video, live TV and music playback with photo viewing
EPG support

I also use the "TV Show Editorials" feature weekly (moreso in September) to see if there's anything new coming down the pike. The name could change to "Upcoming TV" or something a little more descriptive to what it provides for the average user. (I've renamed mine in the menu already)

I don't use "Intelligent Recording" myself but know other users who do.

I just want to see the core remain the best there is and as bug free as possible.

There could be better descriptions of what plugins do, but I personally would like to keep the vast majority of plugins as just that - PlugIns

[Tiki]

Originally Posted by HelenWeathers

narflex, stanger89, wayner etc have it right IMO.

Core should contain:

TV recording functionality
Video, live TV and music playback with photo viewing
EPG support

I also use the "TV Show Editorials" feature weekly (moreso in September) to see if there's anything new coming down the pike. The name could change to "Upcoming TV" or something a little more descriptive to what it provides for the average user. (I've renamed mine in the menu already)

I don't use "Intelligent Recording" myself but know other users who do.

I just want to see the core remain the best there is and as bug free as possible.

There could be better descriptions of what plugins do, but I personally would like to keep the vast majority of plugins as just that - PlugIns

+1

[stanger89]

The thing to remember though, is there's two issues here, and they are not the same:

1) The SageTV architecture, what components/features should be "plugins" and what parts should be built in.
2) The "SageTV" package, what should be included and automatically installed/configured when you run the installer.

What most of the requests I'm reading are looking for is for features to be included as part of 2. Ie, when you run the SageTV installer you get (the option?) to install the web interface, comskip playback, etc.

However just because something is 2, included in the installer, doesn't mean it can't be a "plugin".

Originally Posted by reggie14

There is some notion of core functionality, but despite the popularity of commercial skipping and the web interface I'm not convinced those really belong as core. I don't even think I'd want those plugins installed by default.

The biggest issue with adding functionality to the core (ie not added via the plugin system) is that any update to those features requires a rebuild and re-release of the core to get it out to the public.

Out of curiosity, where does Schedules Direct support fall? EPG data is very much a core feature of a DVR, so on that basis it makes sense as part of the core. At the same time, it might be best to think of any EPG source as a plugin. If something changes with one of those sources you don't want to have to put out a whole new release.

I do like the idea of EPG sources being plugins, but I think it would be good to bundle Schedules Direct to it's installed by default.

[Fuzzy]

Originally Posted by HelenWeathers

narflex, stanger89, wayner etc have it right IMO.

Core should contain:

TV recording functionality
Video, live TV and music playback with photo viewing
EPG support

I also use the "TV Show Editorials" feature weekly (moreso in September) to see if there's anything new coming down the pike. The name could change to "Upcoming TV" or something a little more descriptive to what it provides for the average user. (I've renamed mine in the menu already)

I don't use "Intelligent Recording" myself but know other users who do.

I just want to see the core remain the best there is and as bug free as possible.

There could be better descriptions of what plugins do, but I personally would like to keep the vast majority of plugins as just that - PlugIns

Also realize that a LARGE part of the core has nothing to do with recording OR playing back media. I'd say a bulk of the code is system management and UI.

Originally Posted by stanger89

I do like the idea of EPG sources being plugins, but I think it would be good to bundle Schedules Direct to it's installed by default.

by that token, it would also make sense to work towards moving some things (like the Google/Sage EPG Source) out of the core and INTO a plugin.

[stanger89]

Originally Posted by Fuzzy

by that token, it would also make sense to work towards moving some things (like the Google/Sage EPG Source) out of the core and INTO a plugin.

True, though that's likely a big waste of development resources.

[rkulagow]

If there is going to be effort made to include Schedules Direct as a native option, then it may be fruitful to look at what sort of data we have available. I believe that slugger's grabber tried to take advantage of as much as was possible, but I don't know if everything that we have available had someplace that fit within the existing EPG schema in Sage, so there was a lot of "translating" that needed to be done.

[Narflex]

Couple of comments relating to all this

1. Comskip isn't something that should be included by default because it's not fully cross platform....running it on Linux requires using Wine which isn't an option for all setups (such as mine...I'm the only person who's actually running the 'sagetv on a stick' setup that we talked about many years ago). If this has changed...and there's a native Linux commercial skipping setup...PLEASE correct me on that.

2. I think the SD EPG plugin should be another option in the SageTV core. EPG data is so critical to proper functioning. My suggestion would be to essentially use the WarlockRipper (legacy EPG client code) if there is a SageTV license key present...and use SD if there is not. I'm assuming other SD config is needed (such as a license key); so that should be prompted for in the UI or something like that to facilitate easy setup of the EPG system for a new user.

[dinki]

Originally Posted by Narflex

...I'm the only person who's actually running the 'sagetv on a stick' setup that we talked about many years ago

Not to derail, but can you tell us more about the 'sagetv on a stick'? Is it a true bootable SageTV appliance (OS with SageTV installed) or is it something entirely different?

[Fuzzy]

Originally Posted by stanger89

True, though that's likely a big waste of development resources.

I'm not sure it would take all that much. The data source is already in it's own class, it's just that class is currently rolled into the sage.jar file. It could be moved into it's own package, and the specific calls to it abstracted out so it is treated like any other future data source plugin. It will make maintainability so much better if all data sources are treated the same in the code, especially since the number of sage epg users will only ever decrease.

[Narflex]

Originally Posted by dinki

Not to derail, but can you tell us more about the 'sagetv on a stick'? Is it a true bootable SageTV appliance (OS with SageTV installed) or is it something entirely different?

It's a read-only USB stick with a headless Ubuntu OS on it and SageTV software (plus many other bits like Samba). Then I have a RAID 5 setup that mounts into it and provides all of the writable medium. You may notice stuff in the sage.FSManager java class about monitoring RAID arrays...so I get system messages in SageTV if there's issues with my RAID setup.

[Fuzzy]

Originally Posted by Narflex

Comskip isn't something that should be included by default because it's not fully cross platform....running it on Linux requires using Wine which isn't an option for all setups (such as mine...I'm the only person who's actually running the 'sagetv on a stick' setup that we talked about many years ago). If this has changed...and there's a native Linux commercial skipping setup...PLEASE correct me on that.

I would agree that comskip processing shouldn't necessarily be built into the core, but .EDL reading probably should be brought in to the main STV. In addition to this, I think it would be wise if .EDL files would be parsed and put into a metadata field, so the .EDL file doesn't have to be equally accessible to all clients, and would instead simply be a part of the mediafile object itself.

[BobPhoenix]

Originally Posted by Fuzzy

I would agree that comskip processing shouldn't necessarily be built into the core, but .EDL reading probably should be brought in to the main STV. In addition to this, I think it would be wise if .EDL files would be parsed and put into a metadata field, so the .EDL file doesn't have to be equally accessible to all clients, and would instead simply be a part of the mediafile object itself.

I like this idea.

[rkulagow]

Originally Posted by rkulagow

... but I don't know if everything that we have available had someplace that fit within the existing EPG schema in Sage, so there was a lot of "translating" that needed to be done.

One example of this that I've run into the is the concept of channel numbers as integers vs. strings. Some providers will put alternate content on a "minor" channel; DirecTV did this a lot with "channel 219" being "ESPN", but "219-1" was ESPN-alternate 1, "219-2" ESPN-alternate 2, etc. I believe that this was an issue with Sage, and with the stationIDs as well. (That things were integers and not strings internally?) slugger could expand on it if he's not on vacation, or people could look at the sourcecode, but non-integer channel numbers and stationIDs are something which you may want to accommodate, especially if Sage plans on being made available outside the U.S. and Canada.

[Narflex]

Originally Posted by rkulagow

One example of this that I've run into the is the concept of channel numbers as integers vs. strings. Some providers will put alternate content on a "minor" channel; DirecTV did this a lot with "channel 219" being "ESPN", but "219-1" was ESPN-alternate 1, "219-2" ESPN-alternate 2, etc. I believe that this was an issue with Sage, and with the stationIDs as well. (That things were integers and not strings internally?) slugger could expand on it if he's not on vacation, or people could look at the sourcecode, but non-integer channel numbers and stationIDs are something which you may want to accommodate, especially if Sage plans on being made available outside the U.S. and Canada.

The change was made a long time ago to make channel numbers strings and not integers. StationIDs are integers because they are unique keys for channels.

[ThePaladinTech]

Originally Posted by HelenWeathers

narflex, stanger89, wayner etc have it right IMO.

Core should contain:

TV recording functionality
Video, live TV and music playback with photo viewing
EPG support

I also use the "TV Show Editorials" feature weekly (moreso in September) to see if there's anything new coming down the pike. The name could change to "Upcoming TV" or something a little more descriptive to what it provides for the average user. (I've renamed mine in the menu already)

I don't use "Intelligent Recording" myself but know other users who do.

I just want to see the core remain the best there is and as bug free as possible.

There could be better descriptions of what plugins do, but I personally would like to keep the vast majority of plugins as just that - PlugIns

I Agree as well

[GKusnick]

Put me in the camp of keeping plugins as plugins rather then migrating them into the core.

In addition to what Stanger said about release schedules, a plugin doesn't have to please everyone. There's room for an ecosystem of narrowly targeted plugins that cater to different needs. But as soon as you put something in the core, you're committed to one-size-fits-all, and the result is feature bloat, and a configuration screen with a thousand options that most people will never use.

That said, it seems to me that much of what's being wished for here can be done with plugins even in V7.

EDL files as metadata? Get/SetMediaFileMetadata.

One-click installation of the five most popular plugins? Make a dummy plugin representing the bundle, and add the plugins you want to bundle as dependencies.

Duplicate your existing plugin configuration? Same idea: write a plugin to walk the graph of installed plugins, identify the top-level plugins on which everything else depends, and make a bundle out of them.

[Rob]

I like the plug ins as plug ins. The way they are installed is very simple to manage.

What I wish was in the core is support for the HD Prime (sageDCT works, but is not really a plug in) and support for subtitles in the sage client.

[Fuzzy]

Originally Posted by Rob

What I wish was in the core is support for the HD Prime (sageDCT works, but is not really a plug in) and support for subtitles in the sage client.

I think going forward, all tuner support will be via network encoders. A lot of the configuration issues with the current encoders could be fixed by utilizing some undocumented auto-detection and configuration features in the network encoder protocol that we now have a view of in the source. And, to make things 'cleaner', PrimeNetEncoder, and others, probably should be available to be installed via the plugin system.

[tmiranda]

Originally Posted by GKusnick

Put me in the camp of keeping plugins as plugins rather then migrating them into the core.

Welcome back Greg

[Damstas]

Could these features be added to the core:

In addition to Schedules Direct, TheTVDB and TMDB search. The engine would need to be programmed to bypass the Nordic EPG age restriction, which are at the end of the show name: (7), (12), (16), (18), (R), (S) and (T). This feature is already in NextPVR.
Movies have "Elokuva:" in front of them, atleast in Finland.

Card server and Phoenix card reader support or card support in general (!!!!)

Comskip support

JSON for Schedules Direct