Make SD Plugin as good as possible :)

[Narflex]

Since I've now announced the end of SageTV EPG service as of 7/1/2017...I'll be using the SD plugin as of that point in time. Prior to that, I plan to start using it...and spend time assisting @enternoescape in any way I can to make it as solid as possible. :)

I've already noticed a few various issues with it when I was testing it out. @enternoescape do you want me to open individual issues for each of these things (and I'll gladly help fix them), or are you fine with just piling them in here? I'm not sure all of them can actually be fixed...but as I familiarize myself with their data format more, I'll have a better understanding of what exactly can be done and what can't.

Actually...how about we discuss what issues might be in here, and then ones we actually identify can have a new issue opened for them if it's not a simple fix?

[enternoescape]

I'm curious what you have discovered. Let's just use this issue to discuss things and you suggested, we can open new issues for bigger problems that do not have a simple fix.

[Narflex]

1. I'm seeing empty entries in the Series Information for cast members. There'll be extra blank lines at the end of the list. I see this on most of them, Goldbergs is an example.

2. Is there any way to get images for actors from SD? Or also for their 'cast in character' image which shows a picture of them in the role they play? (the UI will already display both, I have a special EPG source which does this and it's REALLY nice to have...and no, I can't share that EPG source with others, it uses SageTV's data + data from Fiber, but it's all Tribune based)

3. There's lots of cast members that are sometimes listed in this 'Other []' category. An example is Jurassic Park. We can add more Roles to the core if there's ones in the data feed that don't map properly.

4. Probably a UI fix...needs more investigation; but for Jurassic Park for example, the image it shows in the Guide is Jeff Goldblum, where on the Detailed Info page it's for Jurassic Park. I'd expect to see the Jurassic Park image in the Guide. This kind of thing can go at the end of the list to fix since we clearly have more data with SD in this case than we had with the SageTV EPG server. :)

5. Can we get more information about Series such as premiere date? I always liked seeing that. :)

6. Shark Tank as an example has no cast information in Series Info while SageTV does.

7. Series with different information with each season aren't showing up properly. I'm not sure if our EPG server was even doing this right...but the one I'm using does. Hell's Kitchen on FOX is a good example. In my UI, the SeriesInfo shows the contestants for the current season and the description is a half dozen sentences discussing them. The one from SD is just a one sentence generic description likely for the overarching series. This was a tricky problem to fix in SageTV when we first realized this at Google and it's why we have both a seriesID AND a showcardID field in the Show object. That way you can create a 'Series' Favorite based off the seriesID which will then record each season (even if they change the title...I'm looking at you Big Brother)...but still link the proper SeriesInfo object to each different season.

I do want to say that overall I was very impressed when I used the SD EPG source you integrated...it's only because I'm so picky after spending 15 years dealing with EPG data that I notice these kinds of things. :) Great work!

[enternoescape]

1. I did something silly. I see that I have added the crew which almost certainly will not have character names. Also the character name is optional, so I'll add a filter to not use the actor them when there isn't a character name.

2. There is a way to get actor images, but it's a little separate from everything else, so this should probably be turned into it's own issue. If you're curious what that means, check this out: https://github.com/SchedulesDirect/JSON-Service/wiki/API-20141201#retrieving-images-for-a-particular-celebrity

3. I'll add some logging to make it easier to see what the top unmapped roles are.

4. I have a few ideas on what might be happening here. Working with the images was not my best strength and sorting this out might take a little bit of effort.

5. I posted in the SD forums to see if we can get more information about series; it might not be possible because of how the data is licensed. I have not seen a positive response and I have been patient. I really don't have any hope of us getting more information and it makes me sad. The series details a very scant and I'm actually doing what could be considered a "hack" just to get as much detail as I am getting.

6. This is due to the "hack" to get series info. All you can get through their API is this. If I want more information, a show airing must exist. Because of these limitations, I can't always guarantee that we have enough to create a SeriesInfo entry.

7. I doubt you will get much traction on this one for the same reasons mentioned in 5 and 6.

[Narflex]

1. Sounds good...but I wouldn't filter out ones that are an Actor w/out a character name. It will be a little weird...for example in SageTV's data for Pawn Stars it says "Rick Harrison as Actor", but it does seem appropriate to include those in the Series Info page.

2. OK, once we close the other stuff out we can work on that part. Glad to see it's in there. :)

3. OK

4. Yeah, this part is a little tricky. If you give me some examples of what's going on here I can help figure it out. Or as I mentioned, you may already be doing it right and it's just a UI update needed.

5/6/7. OK, well hopefully we can get somewhere with that...it's not that big of a problem though if we can't resolve it....but it definitely looks like it's not something in their current data feeds.

[enternoescape]

1. I agree with what you're saying. I'll just add to the JSON object that if a character name doesn't exist to return their role. This looks much better now.

2. I took a closer look at this from a code perspective. Maybe we can get it in with these changes, but it does involve adding to the Person object to support the URLs.

3. Undefined roles in order of occurance:

I think I will add everything that's over 100 and might generalize things like different kinds of writers.

4. I'm zeroing in on the real issue and I think it's more that I might have been pulling in more images than I should have.

[Narflex]

For the roles stuff, figured I'd tell you what the current EPG server does. It will take either "Writer (*" or "Screen Story Writer" and assign it to be "Writer". Then the only roles it considers are the following, anything else it just discards:

static final String[] ROLE_NAMES =
{
    "", "Actor", "Lead Actor", "Supporting Actor", "Actress",
        "Lead Actress", "Supporting Actress", "Guest", "Guest Star", "Director", "Producer",
        "Writer", "Choreographer", "Sports Figure", "Coach", "Host", "Executive Producer",
        "Artist", "Album Artist", "Composer", "Judge", "Narrator", "Contestant", "Correspondent",
                    "Team", "Guest Voice", "Anchor", "Voice", "Musical Guest"
};

There's a LOT of roles which most people would really care less about and no reason to clog up the database with tons of entries for them. I totally agree with the approach you are taking and I never bothered to do the frequency analysis like you did so we get the most common ones in there. :) Nice work.

[enternoescape]

I'm still working on the ShowInfo images, but I got a little side-tracked on adding Person objects and images. I have the actor images working and they do download now. I agree, it's a nice touch. As soon as I'm done fixing the ShowInfo images problem, I'll be pushing. :)

[enternoescape]

I should also mention that adding the Person object did add a measurable performance decrease in importing EPG data, so I'm also working on addressing that as much as possible. Part of it is because I can only look up one person as a time on Schedules Direct, but I also suspect there might be more too it. I did add some code to ensure that any person is only looked up once, but I suspect there are a lot of unique people.

[Narflex]

Have you stumbled onto the concept of Person aliases yet and understand what those are about?

Jeff Kardatzke Sent from my Android

On Jan 9, 2017 5:52 PM, "Joseph Shuttlesworth" notifications@github.com wrote:

I should also mention that adding the Person object did add a measurable performance decrease in importing EPG data, so I'm also working on addressing that as much as possible. Part of it is because I can only look up one person as a time on Schedules Direct, but I also suspect there might be more too it. I did add some code to ensure that any person is only looked up once, but I suspect there are a lot of unique people.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271464081, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDCl78PN6j9S5M8xWxdKHHGwwbtrXks5rQuRegaJpZM4LbIYs .

[enternoescape]

I look at how that works, is that a way to perform a delayed Person object resolution? In other words, you submit a Person with the ID negated, then add a more detailed Person object with the corresponding absolute ID later.

[Narflex]

I think that will work fine...it appears like logic is already in there to support doing that.

[enternoescape]

Is there something more that I'm missing? I think you're holding out on me. :)

[Narflex]

Oh yeah...apparently there is something else going on there because I thought it was setting addIfNoExist to true when calling from Wizard.addPerson...but it is not...nobody ever sets that...except maybe the custom EPG source I use. I'll have to check that once I deal with my hard disk failing on my workstation at the office since that's where I have a copy of that code (it's all backed up regularly of course, so I'm not worried about losing anything).

I'm assuming you are at least seeing different names with the same TMS ID values in the data feed from SD, right? And does it give you any way to know which one is the 'main' person vs. an alias?

On Tue, Jan 10, 2017 at 11:35 AM, Joseph Shuttlesworth < notifications@github.com> wrote:

Is there something more that I'm missing? I think you're holding out on me. :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271674873, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDPXeNWYUPBT_aAChyajNU5MLCRrAks5rQ92AgaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[enternoescape]

Here's all I've got to work with: https://github.com/SchedulesDirect/JSON-Service/wiki/API-20140530-Program-Response

cast - array of cast members. Optional. Each cast member element consists of the following fields:

personID: string for this person. Used to retrieve images. Optional. nameID: string for this person. Used to differentiate people that have various names, such as due to marriage, divorce, etc. Optional. Actors in adult movies will typically not have a personID or nameID. name: string indicating the person's name. Mandatory. role: string indicating what role this person had. Mandatory. characterName: string indicating the name of the character this person played. Optional. billingOrder: string indicating billing order. Mandatory. crew - array of crew members. Optional. Follows the same pattern as "cast".

I've been using nameID as extID so I can be more sure the names are correct and not being overwritten like I assumed they would be using personID. It's worth noting that the celebrity images JSON can be accessed without authenticating, so if we stored the personID, it could be looked up on demand, but I think that might make the UI feel sluggish.

[Narflex]

Something else while I noticed it...can you add the quality rating into the Bonus field? I've always put the one from TMS (I think that's the name of the ratings body, if you can't figure it out easily let me know and I'll look at the source....which isn't accessible to me right now). I always liked having that rating information in there. :)

And for people, that looks perfect. If personID == nameID, then just use that. And if they are different, than just use the personID but negate it (at least that's how I'm reading it, is that the nameID will vary for the same physical person for each of their different names). And then if you're using a negative person ID, you don't need to put any imagery in there because it'll pull it from the main one. I do realize that's different than what you are doing now; but the SageTV DB will be fine with that and automatically clean out the old ones over time. Doing it this way will then do proper aliasing and consolidate image data storage for all aliases of a person.

One other caveat though...if you're going to add a person with a negative ID and the one with a positive ID is not already in the database, then you'll want to include the imagery for the negative person ID object....unless you have another way to lookup what the actual name is for the celebrity in order to add both of them properly. Then just add the imagery with the positive ID one and no imagery for the negative ID one. The DB maintenance logic ensures that the original person will not be removed from the DB if an alias still refers to it.

And for image lookups, we definitely want to store everything in the DB needed in order to construct the URL...don't want to have to do a JSON lookup to get the image data and then another lookup to retrieve it.

On Tue, Jan 10, 2017 at 4:12 PM, Joseph Shuttlesworth < notifications@github.com> wrote:

Here's all I've got to work with: https://github.com/SchedulesDirect/JSON-Service/wiki/API-20140530-Program- Response

cast - array of cast members. Optional. Each cast member element consists of the following fields:

personID: string for this person. Used to retrieve images. Optional. nameID: string for this person. Used to differentiate people that have various names, such as due to marriage, divorce, etc. Optional. Actors in adult movies will typically not have a personID or nameID. name: string indicating the person's name. Mandatory. role: string indicating what role this person had. Mandatory. characterName: string indicating the name of the character this person played. Optional. billingOrder: string indicating billing order. Mandatory. crew - array of crew members. Optional. Follows the same pattern as "cast".

I've been using nameID as extID so I can be more sure the names are correct and not being overwritten like I assumed they would be using personID. It's worth noting that the celebrity images JSON can be accessed without authenticating, so if we stored the personID, it could be looked up on demand, but I think that might make the UI feel sluggish.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271739038, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDDYmfpaMwQRbg1xRpk-EgChx9P-Sks5rRB6GgaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[enternoescape]

Sounds good. Adding all of these images for the Person object is unavoidably adding significant time due to the lookups. I can't really get it optimized any better if the lookups are not being deferred, so I think I will prioritize getting all of the data correct with the right names and extID's, but I will add all of the images after everything else imported.

[enternoescape]

I will also add an option to turn getting the URL's for these kinds of images off for people who might be on a bandwidth budget.

[Narflex]

And don't worry about how long it takes to do the EPG update...nobody ever cares how long it takes except for the first one. :) But it's not a bad idea to first put all the critical information in there...and then update after that, so they get a populated guide sooner rather than later (which it sounds like you are going to do). And i wouldn't worry about bandwidth usage for fetching the URL data...that'll likely amount to nil compared to streaming a single video.

On Tue, Jan 10, 2017 at 5:59 PM, Joseph Shuttlesworth < notifications@github.com> wrote:

I will also add an option to turn getting the URL's for these kinds of images off for people who might be on a bandwidth budget.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271756519, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDD339Vla-00bFhEj8zIOXcQIs5p7ks5rRDd5gaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[enternoescape]

I just want to avoid forum postings like: I have been waiting for over 30 minutes and I still don't have any guide data. I would also just prefer in general that people not need to wait excessive amounts of time in a testing/troubleshooting related situation.

[enternoescape]

I have the movie thing worked out. Somehow I missed the fact that getAnyImageUrl(int,boolean) is only called for movies. Knowing this, I reversed the way it cycled through the artwork so that box art comes first, then poster art, then photos (which is what you were seeing). This can be fine tuned more to just not include photos if available when it's a movie.

[Narflex]

We could also add more stuff to the UI to give better progress on the EPG updating if you want. ☺️ Maybe a % counter or other text based update in the footer of the Guide screen, and then also in System Information.

Jeff Kardatzke Sent from my Android

On Jan 11, 2017 5:49 AM, "Joseph Shuttlesworth" notifications@github.com wrote:

I have the movie thing worked out. Somehow I missed the fact that getAnyImageUrl(int,boolean) is only called for movies. Knowing this, I reversed the way it cycled through the artwork so that box art comes first, then poster art, then photos (which is what you were seeing). This can be fine tuned more to just not include photos if available when it's a movie.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271872877, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDImzRlNSr5jy8vLBPfC4v71ELM_Bks5rRN3_gaJpZM4LbIYs .

[CraziFuzzy]

Also, what order and amount of data is requested at a time? It seems it might be great if just the first 5 hours or so would be grabbed for all channels, and that info posted to the database, before anything else is. This would ensure that someone viewing the guide after configuration would almost immediately see populated data. Aside from that, I think a small status icon at the top might be all that's really required (similar to the library scan icon, but one that includes some sort of progress indicator).

[enternoescape]

The EPG grabbing is for the first run prioritized by date. You may notice the dates are out of order sometimes after the first run. That's because of the order new data is discovered. It's not worth it from a performance or usability perspective to reorder the requests.

The first day with about ~700 channels takes about 3 minutes for me. I have a very solid internet connection, so I might not be typical. Grabbing everything short of looking up images for Person objects takes about 20 minutes. Grabbing everything including the Person object images takes about 1 hour 20 minutes. You can see how I find that to be an alarming addition.

[Narflex]

Oh wow...that does add a huge amount of time. Is that just because of the serial nature of the requests? (i.e. all the back and forth network requests) What if you made them execute in parallel which should speed that up a bunch?

Or is it the actual insertion of them into the database that's slowing it down?

And I took a look at the custom EPG client I'm using. Apparently the way it works is that it first goes through and adds all the Person objects for the 'main' person entries. And then for each Show or SeriesInfo object it adds, it is then calling Wizard.getPersonForNameAndExtID(String, int, true) so that it will then automatically add all the aliases in then through that call. It's never calling Wizard.addPerson to add an alias itself (although there's nothing wrong with doing it that way if you want to).

On Wed, Jan 11, 2017 at 12:16 PM, Joseph Shuttlesworth < notifications@github.com> wrote:

The EPG grabbing is for the first run prioritized by date. You may notice the dates are out of order sometimes after the first run. That's because of the order new data is discovered. It's not worth it from a performance or usability perspective to reorder the requests.

The first day with about ~700 channels takes about 3 minutes for me. I have a very solid internet connection, so I might not be typical. Grabbing everything short of looking up images for Person objects takes about 20 minutes. Grabbing everything including the Person object images takes about 1 hour 20 minutes. You can see how I find that to be an alarming addition.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-271981580, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDCR80i7ulZDEUkIcSKtjRFMNWB6Yks5rRTiwgaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[enternoescape]

It's the serial nature of the requests. I suppose I could use multiple threads. I have not exhausted my ideas. I'm sure the SD servers are really enjoying my performance testing. :) You actually gave me another idea on how to optimize this process that I will try out.

You'll also be happy to know that I did get your movie ratings in on the first index of the bonus. I remember what those looked like, so I think I've got it right.

[enternoescape]

I was able to get the Person image grabbing down significantly by using multiple threads. It turns out there's a fairly predictable delay between when the request is made and when a reply is received. I had to re-write the raw JSON logging to accommodate non-sequential data retrieval, but so far it's working well. I'm just trying to find the most optimal number of threads now.

[Narflex]

Sounds good!

Jeff Kardatzke Sent from my Android

On Jan 13, 2017 6:06 PM, "Joseph Shuttlesworth" notifications@github.com wrote:

I was able to get the Person image grabbing down significantly by using multiple threads. It turns out there's a fairly predictable delay between when the request is made and when a reply is received. I had to re-write the raw JSON logging to accommodate non-sequential data retrieval, but so far it's working well. I'm just trying to find the most optimal number of threads now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-272593431, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDNaRMdpUvbcAzxrgVJwaz8HGO9Y0ks5rSC3AgaJpZM4LbIYs .

[enternoescape]

@Narflex While I'm working on this code, is there an easy way to tell if a station is entirely No Data? I'm asking because sometimes when someone unselects a station, the EPG grabber doesn't know that the database already removed all of the airings for that station. The place this shows up most is when someone creates a copy of a lineup, then enables some channels that they disabled first in the original lineup.

[Narflex]

There's a method for the whole DB which is Wizard.getLatestTvAiringTime

But nothing that is lineup.....Although you could probably write a new version of that method which you passed a list of channels to analyze for.

Jeff Kardatzke Sent from my Android

On Jan 13, 2017 6:36 PM, "Joseph Shuttlesworth" notifications@github.com wrote:

@Narflex https://github.com/Narflex While I'm working on this code, is there an easy way to tell if a station is entirely No Data? I'm asking because sometimes when someone unselects a station, the EPG grabber doesn't know that the database already removed all of the airings for that station. The place this shows up most is when someone creates a copy of a lineup, then enables some channels that they disabled first in the original lineup.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-272595382, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDJElCN7P5Rr6rI2ZUbthTFgF9bCZks5rSDSvgaJpZM4LbIYs .

[enternoescape]

I did just that, thanks for the tip. It's working well. This is shaping up to be a very good improvement. After I get this in, I really want to help out our SRE plugin users since Schedules Direct actually provides a service that does the same thing: https://github.com/SchedulesDirect/JSON-Service/wiki/API-20141201#downloading-in-progress-for-sporting-events

[WaynerSage]

Adding SRE functionality would be great, however it looks like SD does not support college basketball or football and I am pretty sure that SRE does. That doesn't matter to me as I only watch pro sports but it is something to keep in mind.

[enternoescape]

I understand it has some limitations. I believe we could add an additional bonus property for sports to indicate if extending is supported for that show. The API makes it easy to determine if a show is supported or not. If they need something better, then yes, SRE would still be required, but it's nice to have options and it might be one less thing that project needs to keep up with.

[skiingwiz]

SRE can certainly be updated to look to a second source for sports data. :)

[wayner9]

This seems like it could be fairly easily integrated into the core system so that SRE would be just something to turn on for various Show Titles, presumably with fewer dependencies as well.

[enternoescape]

Since adding this to the API wouldn't cover all sports, it's probably best to just expose it through the API and SRE can use it as another source of data.

[Narflex]

One other thing I forgot about....IIRC, the original airing dates are off by a day. This is likely because they have no time zone and then are being done as GMT which then goes back a day for this country. I think I fixed it by just adding 12 hours to them in our EPG server. :)

[enternoescape]

I can completely see how that would happen. It never occurred to me that the time zone would break that, but it makes sense because when it's being converted, it becomes a date and time which then gets adjusted by timezone and all of us in North America are minus from GMT. This isn't a critical piece, so your suggestion will make it accurate enough for our purposes.

[CraziFuzzy]

Will adding 12 hours to them affect other time zones on the other end? keeping in mind that New Zealand is getting Schedules Direct data now.

[enternoescape]

Yes, it would push the date for that region forward to the next day. SageTV could really use some proprietary way to store dates that don't have an associated time. I think I spotted something like that in the Person object.

[CraziFuzzy]

Sage is aware of the time zone offset, isn't it? I mean, that's how it's adjusting the epg data now. Original Air Dates should be able to be adjusted to make them noon on the appropriate day, that way it's still using proper date objects, but not worrying about a few hour offset one way or the other altering things.

[enternoescape]

I this particular case, I think that SageTV should be handling this adjustment, not the EPG grabber. My reasoning is that if I move from PA to CA, all of my times would be wrong if they are not all stored as GMT. Therefore when SageTV knows that the stored date and time is really just a date, it should be making the adjustment internally and not to the actual stored value.

[enternoescape]

I can also see that the original airing date is factored into a lot of decisions within the code, some of which I could see fiddling with it per timezone causing problems that might require special workarounds.

[Narflex]

What was being done before was on the server it was being parsed as the GMT time zone and then set to 0 hour/minute/second/millisecond with the date according to what was in the data. Then on the client side, it would add 24 hours to the time to correct the problem....and the comment even says for North America. What I think may be the best approach is to parse it that same way, and then add the GMT offset of the local time zone to that (so that it's then at midnight local time as well) and then add 12 hours to that. Then it'll have a +/- 12 hour window for still being on the right day in case somebody moves, which should be good enough for likely everybody. :)

And while it is used in a bunch of calculations, none of them should have an issue with this.

On Tue, Jan 17, 2017 at 8:57 AM, Joseph Shuttlesworth < notifications@github.com> wrote:

I can also see that the original airing date is factored into a lot of decisions within the code, some of which I could see fiddling with it per timezone causing problems that might require special workarounds.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-273229089, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDOhaoHARTUfrNeXkVvyGSS-eLHD_ks5rTPMNgaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[CraziFuzzy]

I think that's what I meant by adjusting it to noon.

[enternoescape]

I know the parser is already setting the hour, minutes, seconds and milliseconds to midnight with the correct date in GMT. What I think would be easiest is to take the 12 hours already being added to the date and then subtract the current timezone offset. That way when the timezone offset is applied to the GMT offset, it ends up being 12pm outside of DST. This is essentially the same effect as described above done in a slightly different order.

[enternoescape]

I noticed there are some fields in the JSON service being carried over from the older service that are not yet considered standard. Based on how they work, I see no harm is using them as they are when they exist. I recall a forum member a while back was asking about being able to single out children's programs. It turns out that one these properties is "audience" and the only expected value at this time is Children. The purpose of this field as you might guess is to indicate the target audience of a program. I was thinking about adding it as a category when it exists as "Children target audience" so that recordings could be scheduled around this.

There's also another property called "holiday" that I'm less sure what to do with if anything. It could be interesting to set up a Christmas favorite and see what ends up recording, but other than that I'm not sure there's much interest in having it used.

[Narflex]

I had forgot to mention that you need to update the Version.java and Sage.java files (for the client compatible version) whenever you change the DB format. I just did another commit that handles that. :)

On Tue, Jan 17, 2017 at 6:08 PM, Joseph Shuttlesworth < notifications@github.com> wrote:

I noticed there are some fields in the JSON service being carried over from the older service that are not yet considered standard. Based on how they work, I see no harm is using them as they are when they exist. I recall a forum member a while back was asking about being able to single out children's programs. It turns out that one these properties is "audience" and the only expected value at this time is Children. The purpose of this field as you might guess is to indicate the target audience of a program. I was thinking about adding it as a category when it exists as "Children target audience" so that recordings could be scheduled around this.

There's also another property called "holiday" that I'm less sure what to do with if anything. It could be interesting to set up a Christmas favorite and see what ends up recording, but other than that I'm not sure there's much interest in having it used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-273362054, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDCwkAqySPMmOFzb5WH6_b78H76x5ks5rTXQjgaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.

[enternoescape]

Thanks. That makes sense.

[enternoescape]

Since I don't think we will be seeing anything quite like best bets from Schedules Direct that we could use for editorials. Do we have any suggestions on what might be a good replacement? Should we just forget about it?

I was thinking we could use the shows from the airings that SageTV would have scheduled if intelligent recording was enabled to look up programs on Schedules Direct and then use the recommendations field that's downloaded with every program to create editorial entries. We would then also limit it to 50 entries and keep track of things a little so you don't see the exact same shows all the time.

[Narflex]

I'd say just forget about it regarding the best bets feature...but the other ideas you have are interesting. You can even get the Intelligent Recording information even if it's disabled...it still calculates it and then there's an API call to get it called GetSuggestedIntelligentRecordings().

However, if you're going to do something based off the recommendations in the SD guide data; I'd suggest looking at the recommendations which are linked to Favorites the user has setup rather than IR....actually...that'd be a modification that would make Intelligent Recording even better. If we knew what the recommendations were based off things related to Favorites...we could use that signal to influence the Intelligent Recordings calculations. But I know a lot of people don't actually use the intelligent recording feature; so as you were saying, just putting some info about that in the Editorials menu might be cool (or calling it something completely different than that and making a new menu...then removing the Editorials menu once SageTV's guide data source expires).

On Thu, Jan 19, 2017 at 12:22 PM, Joseph Shuttlesworth < notifications@github.com> wrote:

Since I don't think we will be seeing anything quite like best bets from Schedules Direct that we could use for editorials. Do we have any suggestions on what might be a good replacement? Should we just forget about it?

I was thinking we could use the shows from the airings that SageTV would have scheduled if intelligent recording was enabled to look up programs on Schedules Direct and then use the recommendations field that's downloaded with every program to create editorial entries. We would then also limit it to 50 entries and keep track of things a little so you don't see the exact same shows all the time.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/sagetv/issues/239#issuecomment-273887905, or mute the thread https://github.com/notifications/unsubscribe-auth/ANEIDP4SICUeA1rFo79gNvTwRmW3lNycks5rT8YggaJpZM4LbIYs .

-- Jeffrey Kardatzke jkardatzke@google.com Google, Inc.