Program Guide Listings with two sources?

[timg11]

I'm temporarily running Spectrum with an HDPVR and Google Fiber TV with an HDPVR2.

The program guide is interleaving the channels from both sources.
In some cases, I see two instances of a given channel in the listing. For example 297 on one source listed right above 297 on the other.

In other cases, only one instance of the channel is in the guide. For example, channel 300 is only showing for Spectrum, and not Google. However in the channel setup for the Google source, channel 300 is showing as enabled. But it does not appear in the guide, and shows on that channel are not found by favorites or future airings searches.

I thought there were people who had multiple cable boxes and multiple sources and it worked OK? But perhaps the issue is having multiple sources with multiple providers and thus lineups that is causing issues?
Has anyone else succeeded with a multi-source setup.

This is a temporary situation - we will cancel Spectrum once Google is working reliably. But in the interim, I'd like to be able to access all the channels.

[KarylFStein]

Originally Posted by timg11

I'm temporarily running Spectrum with an HDPVR and Google Fiber TV with an HDPVR2.

The program guide is interleaving the channels from both sources.
In some cases, I see two instances of a given channel in the listing. For example 297 on one source listed right above 297 on the other.

In other cases, only one instance of the channel is in the guide. For example, channel 300 is only showing for Spectrum, and not Google. However in the channel setup for the Google source, channel 300 is showing as enabled. But it does not appear in the guide, and shows on that channel are not found by favorites or future airings searches.

I thought there were people who had multiple cable boxes and multiple sources and it worked OK? But perhaps the issue is having multiple sources with multiple providers and thus lineups that is causing issues?
Has anyone else succeeded with a multi-source setup.

This is a temporary situation - we will cancel Spectrum once Google is working reliably. But in the interim, I'd like to be able to access all the channels.

Note that if it's the same channel ID only one channel will show in the EPG, (the lineup you add first). So if ABC is channel 200 on Spectrum and 250 on Google you'll only see channel 200 (if you added the Spectrum lineup before the Google one), but both tuners can be used.

[pendragonsound]

Originally Posted by KarylFStein

Note that if it's the same channel ID only one channel will show in the EPG, (the lineup you add first). So if ABC is channel 200 on Spectrum and 250 on Google you'll only see channel 200 (if you added the Spectrum lineup before the Google one), but both tuners can be used.

This represents one of my long running headaches with Sage, because we have two satellite subscriptions (5 tuners) and a number of tuners for both Free-To-Air (FTA) and Over-The-Air (OTA). Thus same channel ID could appear in up to 4 lineups. That never happens, but 2 is very common. This is further compounded by the fact that FTA satellites may feed the same channel ID on different satellites, but all in the same lineup.

This wreaks havoc with recording conflicts, when we theoretically have enough tuners, but Sage won't schedule. It can also cause headaches when a lineup silently adds a new channel, that happens to correspond to one already existing in another lineup, and suddenly the recordings are switched to a different source. That also wreaks unnecessary havoc.

Is there any reason why the EPG can't simply display all the channels for each lineup, even if some of them have duplicate channel IDs?

[JustFred]

It might be helpful to post several screen-grabs from Setup -> Setup Video Sources -> (select your device) -> Channel Setup -> (scroll down to select a channel at issue) so that others can have a look at the station details (right-hand side of screen). Do this for one or two channels on each tuner/capture device that's causing you grief.

Either PlaceShifter or the Sage Client can be used to capture what needs to be inspected.

[pendragonsound]

Originally Posted by JustFred

It might be helpful to post several screen-grabs from Setup -> Setup Video Sources -> (select your device) -> Channel Setup -> (scroll down to select a channel at issue) so that others can have a look at the station details (right-hand side of screen). Do this for one or two channels on each tuner/capture device that's causing you grief.

Just what has been discussed (physical channel number, channel name, channel ID):

Dish Network Lineup: 200, CNNHD, 58646
Shaw Direct Advanced Lineup: 595, CNNHD, 58646 (remapped to logical channel 1595)

If I enable both of these, only one shows up in the guide, which in this case is the Dish Network channel. But if I setup a recording on the Dish Network channel, the recording will actually be done on a Shaw Direct tuner.

[Tiki]

Originally Posted by pendragonsound

Just what has been discussed (physical channel number, channel name, channel ID):

Dish Network Lineup: 200, CNNHD, 58646
Shaw Direct Advanced Lineup: 595, CNNHD, 58646 (remapped to logical channel 1595)

If I enable both of these, only one shows up in the guide, which in this case is the Dish Network channel. But if I setup a recording on the Dish Network channel, the recording will actually be done on a Shaw Direct tuner.

Right, if the same station appears in multiple lineups on different channel #s, Sage will merge them and only display one number in the guide. But it will still record from all of them.

So no matter what you do, CNNHD will only show up once in the EPG. By remapping, you can choose what channel number it will be. So for example, you could go to each lineup and remap it to channel 400, and then it would definitely show up in the guide as 400. But you can't really force Sage to use a specific tuner, so when you tune to 400 in this example you won't know if Sage will pick channel 200 from tuner 1 or channel 595 from tuner 2.

[wayner]

It isn't necessarily bad to have it show up twice as two different channels as it can give you more control over which source you record from. The main other way to control that is with tuner merit which you can now change in the UI but the changes may not take effect until you restart.

[Tiki]

Originally Posted by wayner

It isn't necessarily bad to have it show up twice as two different channels as it can give you more control over which source you record from. The main other way to control that is with tuner merit which you can now change in the UI but the changes may not take effect until you restart.

Actually, it would cause other problems with scheduling if you did this.

Example: Assume CNN is channel 200 on tuner 1 and 300 on tuner2. Now, tuner 1 is already recording a favorite on some channel. You go to the guide and want to watch CNN on channel 200. The way Sage currently works, it knows that channel 300 on tuner 2 is the same thing, so it use tuner2. But if they were separate the way you suggest, Sage would have to throw a conflict (can't tune channel 200 on tuner 1 unless we cancel the favorite that tuner1 is already recording).

There are probably other ways this could be handled, but it would be complicated and probably a major overhaul of the Sage scheduling engine.

[wayner]

Yeah, you are probably right. SageTV treats this differently than MCE did and it took me a while to get used to it. MCE mapped the same channels on different tuners to different channels in the guide - if I remember it correctly it added 1000 to the channel numbers for OTA.

I don't do a ton of recording so conflicts are rarely an issue for me. But I have had instances where some channels can be flakey on some OTA tuners so I may want to force them to use the cable version of that channel instead, whereas I generally want to record from OTA channels first and leave the cable boxes for OTA only.

[stanger89]

Originally Posted by KarylFStein

Note that if it's the same channel ID only one channel will show in the EPG, (the lineup you add first). So if ABC is channel 200 on Spectrum and 250 on Google you'll only see channel 200 (if you added the Spectrum lineup before the Google one), but both tuners can be used.

Just to expand, the whole Sage EPG display is based on station ID, it shows each enabled Station ID once in the Guide. And as far as Sage is concerned, stations with different IDs are different.

If you want to eliminate the duplicates in the guide, you can go in and remap the station to a different station ID

Originally Posted by pendragonsound

This represents one of my long running headaches with Sage, because we have two satellite subscriptions (5 tuners) and a number of tuners for both Free-To-Air (FTA) and Over-The-Air (OTA). Thus same channel ID could appear in up to 4 lineups. That never happens, but 2 is very common. This is further compounded by the fact that FTA satellites may feed the same channel ID on different satellites, but all in the same lineup.

This wreaks havoc with recording conflicts, when we theoretically have enough tuners, but Sage won't schedule. It can also cause headaches when a lineup silently adds a new channel, that happens to correspond to one already existing in another lineup, and suddenly the recordings are switched to a different source. That also wreaks unnecessary havoc.

Is there any reason why the EPG can't simply display all the channels for each lineup, even if some of them have duplicate channel IDs?

Without examples, I can only guess, but I think you actually want to go the other way. What you want to do is go through your different lineups/tuners and make sure that (assuming it's really the same station) all the "CNN"s channels are linked to the same station ID.

If you've got CNN on all 5 tuners, and it's 3 different station ID's that will cause a lot of problems for the scheduler, you want them all to have the same station ID so that Sage knows it's the same station on all 5 tuners.

Originally Posted by wayner

Yeah, you are probably right. SageTV treats this differently than MCE did and it took me a while to get used to it. MCE mapped the same channels on different tuners to different channels in the guide - if I remember it correctly it added 1000 to the channel numbers for OTA.

I don't do a ton of recording so conflicts are rarely an issue for me. But I have had instances where some channels can be flakey on some OTA tuners so I may want to force them to use the cable version of that channel instead, whereas I generally want to record from OTA channels first and leave the cable boxes for OTA only.

The other problem you'll run into is if the different stations use different Episode/show IDs (not sure if that's common or not), it would cause Sage to record the show multiple times.

[BobPhoenix]

Originally Posted by wayner

But I have had instances where some channels can be flakey on some OTA tuners so I may want to force them to use the cable version of that channel instead, whereas I generally want to record from OTA channels first and leave the cable boxes for OTA only.

I disable the flaky channels on OTA and enable them on QAM for this. Then set merrit on the OTA tuners higher. Then I get OTA wherever possible and only use the QAM channels for overflow or those channels that don't come in well on OTA.

[pendragonsound]

Originally Posted by stanger89

Without examples, I can only guess, but I think you actually want to go the other way. What you want to do is go through your different lineups/tuners and make sure that (assuming it's really the same station) all the "CNN"s channels are linked to the same station ID.

My setup is an edge case, but with four different distribution sources (Dish Network, Shaw Direct, OTA, FTA) we have a number of duplicated channels. The Schedules Direct lineups typically provide the same station ID for all channels following the identical schedule. CNN from Dish Network has the same station ID as from Shaw Direct. But this is not always the case. TCM appears to follow the identical schedule for Dish and Shaw (at least I've not noticed an exception), but Schedules Direct provides separate station IDs for the two providers. The Shaw lineup provides different station IDs for the same HD and SD channels, while Dish's lineup provides the same (although their hardware doesn't let one choose). I never alter these IDs in the lineups, just enable/disable channels as needed.

I appreciate why some believe Sage's scheduling strategy makes sense (only one instance of a station ID is shown in the guide, but all will be used for scheduling). But there is a lot about scheduling Sage does not understand. Today I might choose the FTA version of a channel because the quality is far better than from any other source, while tomorrow I may choose to record a lower bit rate version of the same channel to save disk space. It might be raining cats and dogs, rendering Ku-band services (Dish and Shaw) useless, but I can watch the network feed fine on C-band or OTA. But tomorrow football will be encrypted on C-band. I could go on, but I'd prefer to make these decisions rather than fighting Sage each time. Having to change Sage's configuration each time is not a sane solution.

My whole family is diehard Sage and can't imagine living with another solution. But the scheduling code is weak and buggy, or at least with the number of distributors (lineups) and tuners we have.

For example, tuner 1 on lineup A is scheduled to record channel 100 from 5:00-6:00 pm. Nothing else is scheduled for the whole day on any lineup. I want to record a show on lineup A, channel 200 from 5:00-5:30 pm and there are two free tuners. Sage declares a conflict. So I delete the channel 100 recording, schedule the channel 200 recording, and then schedule the channel 100 recording. Works fine.

Or another classic howler we often see: tuner 1 on lineup A is scheduled to record channel 100 from 5:00-6:00 pm. Nothing else is scheduled for the whole day on any lineup. I try to record a show on lineup B, channel 1000 from 7:00-8:00 pm. No time overlap, no lineup overlap. Four tuners available for lineup B. Sage declares a conflict. Same basic solution as above. Works fine.

This is just a sample of what we live with. There is nothing magic or holy about the Sage scheduling algorithm that I wouldn't throw away in a heartbeat if I had the time to rewrite it. I'm happy for those for whom it just works.

[EnterNoEscape]

I created an updated copy of the scheduler myself for a new feature I haven't submitted yet and I can say while a re-write might be welcome, writing a good scheduler when all of the tuners cover some of the same and a few different stations is not trivial. Then if you add in any form of prioritization, it only gets worse when you have a very busy schedule.

Some of the things I see being mentioned here are actually not a function of the Scheduler at all. For example, if you have only one tuner scheduled to record a show and you know that show is available on other tuners that are definitely available, but on a different station and you try to watch a different show live on the tuner that was scheduled, it's going to show a conflict. The reason is because Seeker doesn't actually schedule recordings. It looks at the available tuners for the live channel you want, sees that the station is only available on one tuner and that tuner has a show already scheduled, so it checks if it's ok to override the schedule. There could be some additional mechanisms added to see if the schedule can be re-arranged and those are used when you schedule a manual recording.

Scheduler handles everything between near now and the future. Seeker handles everything that needs to happen right now. If I were to re-write how it all works, I would reduce Seeker to only handle executing the schedule. Live tuning requests would be routed through Scheduler in a "what if" mode to see if they can be accommodated in a more thorough manner. This would be slower, but today's computers are so fast, the performance difference would likely be negligible.

[pendragonsound]

I agree resource scheduling with constraints and priorities is never a trivial problem, and in the general case, efficient and optimal algorithms do not exist. However the algorithm spectrum runs from marginal to decent, and Sage's rates on the mediocre side.

My biggest complaint is it often chokes with conflicts only in its imagination. Most of my family's recording scheduling is for shows weeks into the future, so this is almost never a Scheduler vs. Seeker issue. I'm speculating when Sage looks at adding a recording in the distant future, bugs or strategy errors may accumulate in probability along the way and generate a nonsensical result. Even when Sage succeeds, I'm also confused how it can miss the most trivial, yet optimal solution.

While I was never more than peripherally involved in the designs, I have worked on projects where scheduling was done against resource pools that were much larger and where the constraints could be bizarre. The number of choices was often unbounded, but good minds arrived at techniques with results very close to optimal. Sage's situation should be simpler, because its choices are always finite in number and never grow more than geometrically.

[EnterNoEscape]

Originally Posted by pendragonsound

While I was never more than peripherally involved in the designs, I have worked on projects where scheduling was done against resource pools that were much larger and where the constraints could be bizarre. The number of choices was often unbounded, but good minds arrived at techniques with results very close to optimal. Sage's situation should be simpler, because its choices are always finite in number and never grow more than geometrically.

I think some of the reason why we don't always get the most optimal solution stems from the fact that we don't let SageTV try absolutely everything because it could cause incredibly long times trying to schedule things on very busy schedules. SageTV doesn't try everything; it stops pretty much when it has resolved all of the conflicts.

This kind of thing is certainly not my specialty, but I can see some value in re-writing it. My biggest reason for re-writing it is so that we can add more seams for testing. That would allow us to be more intrepid with improvements because we can have higher confidence that we didn't create new issues.

You've got me thinking about re-writing the scheduler and relationship with Seeker. I've been writing an alternate Seeker and Scheduler, so I might have the last opportunity to get things right for SageTV.

[stanger89]

Originally Posted by pendragonsound

TCM appears to follow the identical schedule for Dish and Shaw (at least I've not noticed an exception), but Schedules Direct provides separate station IDs for the two providers. The Shaw lineup provides different station IDs for the same HD and SD channels, while Dish's lineup provides the same (although their hardware doesn't let one choose). I never alter these IDs in the lineups, just enable/disable channels as needed.

In that case, you should remap that station to the same station ID as the other lineups. And/or report that issue to Schedules Direct as it sounds like it's an error. Those of use with lots of OTA/QAM channels are used to this because we have to manually (unfortunately) map channels to stations normally.

I appreciate why some believe Sage's scheduling strategy makes sense (only one instance of a station ID is shown in the guide, but all will be used for scheduling). But there is a lot about scheduling Sage does not understand. Today I might choose the FTA version of a channel because the quality is far better than from any other source, while tomorrow I may choose to record a lower bit rate version of the same channel to save disk space. It might be raining cats and dogs, rendering Ku-band services (Dish and Shaw) useless, but I can watch the network feed fine on C-band or OTA. But tomorrow football will be encrypted on C-band. I could go on, but I'd prefer to make these decisions rather than fighting Sage each time. Having to change Sage's configuration each time is not a sane solution.

Unfortunately, as you say you have an edge case, most Sage users don't have that problem, and I suspect would greatly increase both the complexity of Sage's scheduler, as well as the use of the system for the vast majority of users.

My whole family is diehard Sage and can't imagine living with another solution. But the scheduling code is weak and buggy, or at least with the number of distributors (lineups) and tuners we have.

For example, tuner 1 on lineup A is scheduled to record channel 100 from 5:00-6:00 pm. Nothing else is scheduled for the whole day on any lineup. I want to record a show on lineup A, channel 200 from 5:00-5:30 pm and there are two free tuners. Sage declares a conflict. So I delete the channel 100 recording, schedule the channel 200 recording, and then schedule the channel 100 recording. Works fine.

If you let it go for a while, does the conflict get resolved? It takes some time for Sage to process the schedule. It might be the case that that new show can't be recorded until Sage has a chance to redo the schedule.

Beyond that we'd need to know more details about that situation. You say there are two free tuners, is 200 enabled on those tuners? 100?

Or another classic howler we often see: tuner 1 on lineup A is scheduled to record channel 100 from 5:00-6:00 pm. Nothing else is scheduled for the whole day on any lineup. I try to record a show on lineup B, channel 1000 from 7:00-8:00 pm. No time overlap, no lineup overlap. Four tuners available for lineup B. Sage declares a conflict. Same basic solution as above. Works fine.

This is just a sample of what we live with. There is nothing magic or holy about the Sage scheduling algorithm that I wouldn't throw away in a heartbeat if I had the time to rewrite it. I'm happy for those for whom it just works.

Neither of your examples seem to have anything to do with the original question of Sage combining lineups in the guide, they sound like bugs or, my knee-jerk reaction, impatience on your part. I'd be interested to know if those conflicts resolve themselves if you give Sage time to figure out the schedule on it's own.

Your second issue should never happen (assuming you have no padding added), but I have a vague recollection of seeing brief conflicts immediately after scheduling a new manual recording until Sage reshuffles the schedule.

Back to my knee-jerk reaction, you have a complicated tuning setup, lots of tuners, lots of lineups, and I wonder if what you're seeing is just a case of it taking longer than you're expecting for Sage to reshuffle the recording schedule to account for the new recording request.

[stanger89]

Originally Posted by pendragonsound

My biggest complaint is it often chokes with conflicts only in its imagination. Most of my family's recording scheduling is for shows weeks into the future, so this is almost never a Scheduler vs. Seeker issue. I'm speculating when Sage looks at adding a recording in the distant future, bugs or strategy errors may accumulate in probability along the way and generate a nonsensical result. Even when Sage succeeds, I'm also confused how it can miss the most trivial, yet optimal solution.

What I've seen is it's a guide data problem. Guide data 2 or especially 3 weeks out is often incomplete. I've noticed a couple times recently that I'll have conflicts denoted for two weeks out in the future. When I go look it's because it's trying to record every episode of some show that's scheduled continuously for an entire day or something.

I have yet to see one of these conflicts come to fruition though. It appears (though I haven't thoroughly investigated) that at least a few networks just stick placeholders out in the future for shows, probably with show IDs in the guide. Since these are not unique, Sage tries to schedule them all, and ends up driving conflicts.

However when those airings get closer, the networks seem to update their info, I assume adding specific episode info and switching them over to Episode IDs, at which time Sage knows which ones it needs to record, and the conflicts magically disappear.

I know us technical types have a predilection for trying to make sure everything works now and fix everything as soon as possible, but especially with the distant EPG data available and the amount of flux with it, in a way I think expanding Sage's scheduling out to 3 weeks is almost a bad thing. It causes it to try and schedule a bunch of garbage which will end up resolving itself as the guide data is fleshed out as airings get closer.

I don't know if this is for everybody, but for me, I check my conflicts to see if they're soon, and if not, I just ignore them and have yet to see one not disappear.

[pendragonsound]

Originally Posted by stanger89

In that case, you should remap that station to the same station ID as the other lineups. And/or report that issue to Schedules Direct as it sounds like it's an error. Those of use with lots of OTA/QAM channels are used to this because we have to manually (unfortunately) map channels to stations normally.

Having two station IDs from different providers is pure serendipity for me. It gives me the control to choose which one I want to record. I've even considered writing a man-in-the-middle filter for Schedules Direct to fool Sage when I have two or more providers that have channels with the same station ID.

My historical practice for dealing with station IDs appearing in more than one lineup has been to disable the duplicating channels so only one can be recorded. For the last few days I have been experimenting with enabling the duplicated station IDs and setting tuner merits to handle our general recording preference. I really dislike the idea of having to change Sage's configuration to force it to choose the channel from the lineup I want, but I'll see whether this is better or worse than what we've been doing for the past decade.

Unfortunately, as you say you have an edge case, most Sage users don't have that problem, and I suspect would greatly increase both the complexity of Sage's scheduler, as well as the use of the system for the vast majority of users.

I would never advocate trying to make Sage's scheduler cognizant of the criteria I mentioned. What would be close to perfect would be a record option where I could override Sage's tuner choice with my own. Most of the time Sage does fine and there would be no need to do this.

"For example, tuner 1 on lineup A is scheduled to record channel 100 from 5:00-6:00 pm. Nothing else is scheduled for the whole day on any lineup. I want to record a show on lineup A, channel 200 from 5:00-5:30 pm and there are two free tuners. Sage declares a conflict. So I delete the channel 100 recording, schedule the channel 200 recording, and then schedule the channel 100 recording. Works fine."

If you let it go for a while, does the conflict get resolved? It takes some time for Sage to process the schedule. It might be the case that that new show can't be recorded until Sage has a chance to redo the schedule.

One can wait until the cows come home and nothing ever changes. Scheduling happens very quickly on my system, and I occasionally check the logs just to make sure. But see my discussion below about "bugs".

While I have a lot of lineups and tuners, my configuration is actually pretty simple from a scheduling point of view. We deliberately avoid any favorites and all shows are manually recorded. The lineups are mutually exclusive. Thus each lineup has a unique set of station IDs, of which none is found in any of the other lineups, and each lineup has an exclusive pool of tuners. All tuners in each pool share exactly the same lineup (no copies or derivatives), and all tuners in each pool can tune all of the channels in the associated lineup. Thus a recording in lineup A should never cause a conflict in any other lineup. But it happens.

Beyond that we'd need to know more details about that situation. You say there are two free tuners, is 200 enabled on those tuners? 100?

In the above example, lineup A has 3 dedicated tuners. Each of those tuners can tune all of the channels in lineup A. If only one tuner is in use for a given time period (my example), I should always be able to add one or two more recordings that are contained within the same time bounds. That sometimes fails.

Neither of your examples seem to have anything to do with the original question of Sage combining lineups in the guide, they sound like bugs or, my knee-jerk reaction, impatience on your part. I'd be interested to know if those conflicts resolve themselves if you give Sage time to figure out the schedule on it's own.

Your second issue should never happen (assuming you have no padding added), but I have a vague recollection of seeing brief conflicts immediately after scheduling a new manual recording until Sage reshuffles the schedule.

Back to my knee-jerk reaction, you have a complicated tuning setup, lots of tuners, lots of lineups, and I wonder if what you're seeing is just a case of it taking longer than you're expecting for Sage to reshuffle the recording schedule to account for the new recording request.

My assumption is they are bugs, but maybe I'm missing something completely obvious. The only reason our Sage will make a recording is because someone manually scheduled it, from an extender, client, or web interface. At the time we setup a manual recording and if Sage finds a conflict, I don't recall it ever giving a choice to keep the conflict. Sage provides a list of existing recordings that cause the conflict, and one has to choose deleting one of these to allow the new recording, or simply not scheduling the new recording. The buggy part is the list of "conflicts" is often nonsensical, including recordings from other lineups that have nothing to do with the recording I am trying to schedule.

What is obvious with my configuration is that each lineup can be scheduled independently from the others. That is not how Sage approaches scheduling, but the result should be the same. What is also obvious is that any time interval of the recording schedule separated before and after by non-recording gaps (even if of zero duration), can be scheduled independently from any other time intervals. The apparent Sage "bugs" fall for both of these traps sufficiently often that these do not appear to be flukes. This makes me doubt whether Sage even tries to partition its scheduling into independent pieces that would prevent the examples I offered from ever happening, and obviate the need to completely reschedule everything when a non-interfering recording is added.