Development of Sagetv v9

[Oddity]

I'm unfortunately not a programmer but, one area that needs to be addressed is the implementation of the support for tuner cards / devices. I know that this has been discussed many times but, the number of supported devices is dwindling fast and some that do work have issues with receiving some channels / tuning correctly, where they will work perfectly with other software.
If we are to promote the use of Sagetv to a wider audience then we need a wider hardware platform, some advances have been made on the client side but ,without the support for live tv new users are not going to risk buying hardware only to find it does not work.
I'm on the windows platform and I believe that generally most are bda compliant, so not trying to oversimplify it but it appears to need a better interface with this to correctly identify the tuner and its parameters. I may be completely wrong but just wanted to raise this issue again.

[SomeWhatLost]

just curious really, but what tuners are people using that dont work?

[nyplayer]

Originally Posted by SomeWhatLost

just curious really, but what tuners are people using that dont work?

WinTV-dualHD TV Tuner only shows up as 1 tuner.
WinTV-quadHD


PS I would also like to see keep padding on back to back recordings same channel and use 1 Tuner. In order to do this currently you need to use 2 tuners.... not efficient use of tuners.

[EnterNoEscape]

Originally Posted by nyplayer

PS I would also like to see keep padding on back to back recordings same channel and use 1 Tuner. In order to do this currently you need to use 2 tuners.... not efficient use of tuners.

Beyond TV has this and it pads recordings by default 2 minutes in both directions. I do miss that feature, but I have enough capture devices to make up for it. To make this work the way things are set up right now would be a bit of a challenge, but not impossible and I too would really like to see this as a feature. What I think should ideally happen is the capture devices (including network encoders) should really just stream data and another part of SageTV would decide where that data goes including splitting it as many times as needed to get the padding right on every recording. Then the scheduler would need to be made aware that they can overlap. Since it already has a setting to remove padding when recordings are back to back, I don't think it would be a stretch to have it preserve the padding, but use the same capture device by splitting the stream at the right time.

Other thoughts: The way it is right now, every capture device needs to fend for itself when it comes to very universal things like SWITCH. I think adding this feature would also help pull everything together so we don't have the exact same code being constantly copied everywhere. I'm currently working on exposing the remuxer that all of the native capture devices in SageTV use to the JVM so network encoders can use it. Once I'm done with that I think I'll start to take a look at how we could make this a reality.

[KeithAbbott]

Originally Posted by Oddity

I'm unfortunately not a programmer but, one area that needs to be addressed is the implementation of the support for tuner cards / devices. I know that this has been discussed many times but, the number of supported devices is dwindling fast and some that do work have issues with receiving some channels / tuning correctly, where they will work perfectly with other software.
If we are to promote the use of Sagetv to a wider audience then we need a wider hardware platform, some advances have been made on the client side but ,without the support for live tv new users are not going to risk buying hardware only to find it does not work.
I'm on the windows platform and I believe that generally most are bda compliant, so not trying to oversimplify it but it appears to need a better interface with this to correctly identify the tuner and its parameters. I may be completely wrong but just wanted to raise this issue again.

The reality of the situation is that unsupported tuners will probably only become supported when a developer with the right skills has a need for that type of tuner to become supported. Tuners are not free, and neither is developer time. I think the likelihood of a developer focusing on getting Sage to work with the latest hardware is slim unless they have a need for that hardware.

Of course, I would love to be proved wrong in this regard...

[Fuzzy]

Originally Posted by KeithAbbott

The reality of the situation is that unsupported tuners will probably only become supported when a developer with the right skills has a need for that type of tuner to become supported. Tuners are not free, and neither is developer time. I think the likelihood of a developer focusing on getting Sage to work with the latest hardware is slim unless they have a need for that hardware.

Of course, I would love to be proved wrong in this regard...

And honestly, I don't think there are any tuners out there that do anything that the supported tuners do NOT do, so really - just use a supported tuner...

[BobPhoenix]

Originally Posted by EnterNoEscape

Beyond TV has this and it pads recordings by default 2 minutes in both directions. I do miss that feature, but I have enough capture devices to make up for it. To make this work the way things are set up right now would be a bit of a challenge, but not impossible and I too would really like to see this as a feature. What I think should ideally happen is the capture devices (including network encoders) should really just stream data and another part of SageTV would decide where that data goes including splitting it as many times as needed to get the padding right on every recording. Then the scheduler would need to be made aware that they can overlap. Since it already has a setting to remove padding when recordings are back to back, I don't think it would be a stretch to have it preserve the padding, but use the same capture device by splitting the stream at the right time.

Other thoughts: The way it is right now, every capture device needs to fend for itself when it comes to very universal things like SWITCH. I think adding this feature would also help pull everything together so we don't have the exact same code being constantly copied everywhere. I'm currently working on exposing the remuxer that all of the native capture devices in SageTV use to the JVM so network encoders can use it. Once I'm done with that I think I'll start to take a look at how we could make this a reality.

My though (at least for me) is to be able to assign a tuner to a channel and have all channels and sub-channels dumped to a circular buffer. Then you just copy the data from the file buffer from x minutes/seconds before and after the scheduled times. Probably wouldn't work for everybody but that would work for me.

[EnterNoEscape]

Originally Posted by BobPhoenix

My though (at least for me) is to be able to assign a tuner to a channel and have all channels and sub-channels dumped to a circular buffer. Then you just copy the data from the file buffer from x minutes/seconds before and after the scheduled times. Probably wouldn't work for everybody but that would work for me.

I wanted to do this too a while ago, but it greatly complicates the scheduler. It might be possible that we can get to your plan eventually, but I think we should do this one thing as a time.

[Fuzzy]

And honestly, the transfer end of this would not be incredible hard, and would work more as an extension of some changes EnterNoEscape was already doing in the sagetv core - regarding network encoders. The issue, however, comes with the changes to the scheduler to deal with this. Sage's scheduler is incredibly complicated, and telling it whether a given tuner can record more than one stream at a time is throwing a LOT more cases that it needs to know about. Combine that with the fact that many users aren't using a system that could predictably determine if more than one channel was being broadcast in the same stream or not is even harder. CableCard could run different sets of stations on different streams on every tune - so this isn't really something a scheduler could realistically deal with.

The back to back overlapped padding might be possible, as scheduling wise, back-to-back padding is already detected (and removed if the option is so configured). That detection could be used to override the scheduler's default behavior to allow the padding to remain, if the tuner is running through the sage remux, and the sage remux is able to do the dual file writing.

[EnterNoEscape]

Originally Posted by Fuzzy

The back to back overlapped padding might be possible, as scheduling wise, back-to-back padding is already detected (and removed if the option is so configured). That detection could be used to override the scheduler's default behavior to allow the padding to remain, if the tuner is running through the sage remux, and the sage remux is able to do the dual file writing.

That's essentially what I would exploit, but I'm not limiting myself to just splitting out into two recordings. I was thinking it could be split into as many are necessary. I can see some situations were you might end up with 3+ files being "duplicated." For example, due to sports, some of my shows get really pushed back, so I have the recordings extended a little excessively to compensate for the times that happens.

[BobPhoenix]

Note what I was proposing was to eliminate a lot of the complexity of the scheduler. I would only have to know that channel 81 QAM has half of my local channels and that my HVR-2250 tuner 1 was set and always buffering that channel so it would just grab the channel and sub channel from it. If I wanted the other half of my local channels it would use HVR-2250 tuner 2 which was tuned to QAM channel 80. Or if it was coming from ATSC it would take 5 or 6 tuners. No conflicts would ever be present because the tuners would not be changing channels.

As I said this would likely just work for me.

[Fuzzy]

Originally Posted by BobPhoenix

Note what I was proposing was to eliminate a lot of the complexity of the scheduler. I would only have to know that channel 81 QAM has half of my local channels and that my HVR-2250 tuner 1 was set and always buffering that channel so it would just grab the channel and sub channel from it. If I wanted the other half of my local channels it would use HVR-2250 tuner 2 which was tuned to QAM channel 80. Or if it was coming from ATSC it would take 5 or 6 tuners. No conflicts would ever be present because the tuners would not be changing channels.

As I said this would likely just work for me.

But even that is a HUGE change to the scheduler logic, because currently, it assumes a single program per source. Having more than one be available per source - sometimes - is a lot more to deal with. Yes, it is certainly possible - but there are a few forces against it ever being implemented.

1. It really only works for QAM and ATSC recordings, because CableCard - as I mentioned earlier - can move stations around - especially if SDV is in use, which is the bulk of markets these days.
2. Seeing as it is only for QAM and ATSC, the best options is still going to be just adding an additional tuner, which results in just a one time cost for those services, and much more future capability.
3. The SageTV Scheduler code is scary.

[Monedeath]

Originally Posted by KeithAbbott

The reality of the situation is that unsupported tuners will probably only become supported when a developer with the right skills has a need for that type of tuner to become supported. Tuners are not free, and neither is developer time. I think the likelihood of a developer focusing on getting Sage to work with the latest hardware is slim unless they have a need for that hardware.

Of course, I would love to be proved wrong in this regard...

Some other certain communities I'm aware of, not software side, but I haven't really dug into that side of things. Have a "bounty" system of sorts for certain things being done. But that means people being willing and able to front the cash, and finding a 3rd party to hold it.

[stanger89]

Originally Posted by Fuzzy

But even that is a HUGE change to the scheduler logic, because currently, it assumes a single program per source. Having more than one be available per source - sometimes - is a lot more to deal with. Yes, it is certainly possible - but there are a few forces against it ever being implemented.

1. It really only works for QAM and ATSC recordings, because CableCard - as I mentioned earlier - can move stations around - especially if SDV is in use, which is the bulk of markets these days.
2. Seeing as it is only for QAM and ATSC, the best options is still going to be just adding an additional tuner, which results in just a one time cost for those services, and much more future capability.
3. The SageTV Scheduler code is scary.

I don't know about programmatically, but from what I've seen, CableCard eliminates the whole concept of subchannels, if you have a CableCard in your HDHR for example, you just get a list of channels, and you tune by channel number (eg 800), not frequency/subchannel (800-1).

[Fuzzy]

That is correct, that is what is exposed by the HDHR Prime - but the channels are still broadcast together in (encrypted) QAM streams from the head-end. The CableCard just has a channel map loaded into it to do all the translations for you, so it knows what frequency to tune to and what streams to extract from that TS. Even with SDV, there are still more than once station in the stream, but it can be reconfigured on the fly at each neighborhood head end to serve up just what is being requested by the neighborhood. When SDV is in use, the HDHR Prime uses the channel-map from the Tuning Adapter, instead of what is loaded in the CableCard. I don't know if there is a way to make the HDHR send the full stream or not, but it likely would be of little use anyways, because of it's unpredictability.

[EnterNoEscape]

Originally Posted by stanger89

I don't know about programmatically, but from what I've seen, CableCard eliminates the whole concept of subchannels, if you have a CableCard in your HDHR for example, you just get a list of channels, and you tune by channel number (eg 800), not frequency/subchannel (800-1).

While you do only see virtual channels in the web interface, they directly correlate to a frequency and program. That's how OpenDCT is able to use a tuner with a CableCARD and use the virtual channel mapping to a frequency and program to tune a ClearQAM tuner. There are multiple programs on almost every frequency, but as Fuzzy hinted at, the programs for many people change a lot and some even on demand (SDV). So while this feature would be nice, it's unlikely to be reliable for many very many configurations.

[Narflex]

Trying to get it to record multiple subchannels at once will induce a HUGE additional complexity into the Schedule; I would strongly advise against trying to do that. I know other packages can do it; but I'm quite sure they don't have as much other extensive capabilities in this area that SageTV has.

Dealing with overlapping padding on the same channel isn't all that horrible though. I actually started a project on this at Google; but abandoned it because they were going to switch platforms so there was no need for implementing it. The way I'd recommend doing it is to basically remove overlapping padding for scheduling purposes (like that one option already does); that requires no changes to the Scheduler logic at all. Then in the Seeker (which controls the tuners, and receives the actual schedule from the Scheduler); whenever you are starting a recording, check to see if it is part of back to back favorites w/ overlapping padding. Then copy the padding from the prior file to the start of the new file; and then also set a flag to copy the beginning of the new file (after the padding) to the end of the prior file. This may involve multiple files if the padding is very long (as in theory, it could overlap with may things if they all have hours of padding on them). You could also do it where you don't even append/prepend the files, you just make them another segment like normally in MediaFile objects.

There are a couple other corner cases that fall out of this; but nothing too bad to deal with. If anybody is going to take this on; let me know and I can point out how I would have done it and provide insight on solving the other corner cases related to it.

[EnterNoEscape]

Originally Posted by Narflex

Dealing with overlapping padding on the same channel isn't all that horrible though. I actually started a project on this at Google; but abandoned it because they were going to switch platforms so there was no need for implementing it. The way I'd recommend doing it is to basically remove overlapping padding for scheduling purposes (like that one option already does); that requires no changes to the Scheduler logic at all. Then in the Seeker (which controls the tuners, and receives the actual schedule from the Scheduler); whenever you are starting a recording, check to see if it is part of back to back favorites w/ overlapping padding. Then copy the padding from the prior file to the start of the new file; and then also set a flag to copy the beginning of the new file (after the padding) to the end of the prior file. This may involve multiple files if the padding is very long (as in theory, it could overlap with may things if they all have hours of padding on them). You could also do it where you don't even append/prepend the files, you just make them another segment like normally in MediaFile objects.

This is a slightly different approach to what I was thinking of, although much more compatible with how things work right now. The only problem I see outside of SageTV is that prepending to files will throw Comskip off if it's running live or if it starts before the data is prepended.

Edit: Nevermind, you're copying the parts needed from the last file into the new file before continuing to append. I got a little mixed up at the end there as you were proposing an alternative.

[Fuzzy]

even if run as a new segment, comskip is supposed to deal with segmented files just fine.

[Oddity]

Just to bring this back on track but, I've reverted back to dvbe4sage, as it works with my replacement tuner (tbs5990). I've not had a tuner that does not work with it, so what is it doing different with interfacing with the Tuner?