Question About Tuner Usage

[cubdukat]

Recently I have had to dig out my old HDHomerun Dual tuner and SageTV because Comcast has become increasingly glitchy since they switched over to MPEG-4, and I would still like to get NBC and ABC in MPEG-2.

The setup is working quite well, except for one problem. I have set my recordings up so that they have about five minutes padding before and after the show. For some reason, SageTV seems to ignore that. A real-life example: Last week's double episode of "The Blacklist" should have had both episodes with five minutes padding at either end, but the padding at the end of the first one was ignored, and the padding at the beginning of the second one was ignored. So in order to get two complete episodes, I had to splice them together in VideoReDo and cut them apart again correctly.

When I set up the tuners, I only actually did the full setup with the first tuner and then copied the program guide info to the second one. Should I have done the complete setup with the second one as well? I didn't think it was necessary, since both tuners are basically the same.

[KarylFStein]

I bet you just need to set this to No:

Settings > Detailed Settings > Customize > Remove padding on back to back favorites on the same channel

[wnjj]

Look for the “remove padding on back to back favorites”. Set it to “no”. This will cause each show to use a different tuner since the current setup cannot overlap on a single tuner.

[cubdukat]

Thanx. I found it. That was sneaky of them to hide that...

I thought for a second it was something with the tuner. I haven't used it in almost ten years.

[wnjj]

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner. The native code is fairly straightforward (write the same data into 2 files). The tough part is handling all of the show switchover code since it was all built around a one show at a time per tuner concept.

[trk2]

Originally Posted by wnjj

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner.

[nyplayer]

Originally Posted by wnjj

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner. The native code is fairly straightforward (write the same data into 2 files). The tough part is handling all of the show switchover code since it was all built around a one show at a time per tuner concept.

That would be fantastic that is the only thing SageTV is missing.

[BobPhoenix]

Originally Posted by wnjj

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner.

[jt4242]

Originally Posted by wnjj

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner.

That would be amazing!!

[Zogg]

Originally Posted by nyplayer

That would be fantastic that is the only thing SageTV is missing.

Easy there...

I'd like to be able to:

1. Disable a tuner without having to just delete it to keep it from being used
2. Set a recording favorite to always use a particular tuner

I can probably think of a few more later.

[JustFred]

Originally Posted by Zogg

Easy there...

I'd like to be able to:

1. Disable a tuner without having to just delete it to keep it from being used

To temporarily disable a tuner, I simply configure it to use no EPG. Bingo, done. Later, to make it functional again, just re-assign it to back to the previous EPG lineup. No need to re-download the EPG nor tell the tuner to re-scan for channels (assuming some other tuner is still config'd for that EPG lineup).

[Zogg]

Originally Posted by JustFred

To temporarily disable a tuner, I simply configure it to use no EPG. Bingo, done. Later, to make it functional again, just re-assign it to back to the previous EPG lineup. No need to re-download the EPG nor tell the tuner to re-scan for channels (assuming some other tuner is still config'd for that EPG lineup).

I never thought of that, thanks. I used BeyondTV for years and it had a simple enable/disable setting that was sure handy at times, but at least this method will work.

[EnterNoEscape]

Originally Posted by wnjj

Someday I plan to try to fix the code so it will split into 2 files so overlapping favorites & padding will still happen on a single tuner. The native code is fairly straightforward (write the same data into 2 files). The tough part is handling all of the show switchover code since it was all built around a one show at a time per tuner concept.

I wrote code that fully implements this already, but didn't commit it because a massive refactoring was done that eliminated branches. Since I did all my testing on the old code and I haven't had the time to iron out all of the changes and verify it still works correctly. It's actually really complicated for many reasons. You'll notice hooks in the code from when I committed my Carny changes. The scheduler needs to be overhauled. The race conditioned code for live tuning also needs to be worked out. I also added support for tuners that will allow multiple programs on one frequency to be recorded. Then after all of that, you need to figure out a strategy for how to work with network encoders that don't use the media server which I did the work on too. The other half is that I don't know if I have the time to commit to maintaining more code in SageTV.

Edit: In case anyone is wondering why I don't just use unit testing to verify everything is ok, I did, but some parts of the code can't be tested correctly because of how SageTV is assembled. Honestly, it would be easier to just write a new PVR than to try to decouple all of SageTV so proper unit testing is possible.

[wnjj]

Thanks for the comments and explanation. I’ve run with removing padding for so long that I’m kind of used to it. It does suck when you have to watch shows in the order they recorded so you catch the end of your show on the start of the next one.

I don’t know all that the scheduler and seeker do (far from it) but my simpleton approach was going to be to let the system think it is still removing padding so everything appears to work as it does today with regard to scheduling and conflicts. Then instead of simply calling switchencoding when the show changes, I would add two more calls...one to start the (additional) new show when its padding says to and another to drop off the old show when its padding ends. I was hoping to sneak these calls in with minimal changes to the existing stuff. The only native capture code I’m familiar with is the mpeg2dump and hadn’t considered any other sources yet but used it for an example. Selfishly, it’s all i need to have working anyway.

If your solution is already coded and was working it would sure be nice to see it. If it involves too major of a rewrite it’s tougher to get pulled in without risk.

[EnterNoEscape]

Originally Posted by wnjj

Thanks for the comments and explanation. I’ve run with removing padding for so long that I’m kind of used to it. It does suck when you have to watch shows in the order they recorded so you catch the end of your show on the start of the next one.

I don’t know all that the scheduler and seeker do (far from it) but my simpleton approach was going to be to let the system think it is still removing padding so everything appears to work as it does today with regard to scheduling and conflicts. Then instead of simply calling switchencoding when the show changes, I would add two more calls...one to start the (additional) new show when its padding says to and another to drop off the old show when its padding ends. I was hoping to sneak these calls in with minimal changes to the existing stuff. The only native capture code I’m familiar with is the mpeg2dump and hadn’t considered any other sources yet but used it for an example. Selfishly, it’s all i need to have working anyway.

If your solution is already coded and was working it would sure be nice to see it. If it involves too major of a rewrite it’s tougher to get pulled in without risk.

Yeah, I did what you described first and quickly realized it wasn't that simple. I got strange behavior that eventually led me down the rabbit hole that I didn't anticipate. I learned a crazy lot about SageTV's recording engine innards and it was enough for me to make my implementation something you could optionally enable (like a beta feature) instead of replacing the current code. I can share my code with you if you're interested.

My solution was to make everything route through the media server and into a splitter in Java code to break the stream into multiple files. You can read about most of what I dove into here: https://github.com/google/sagetv/issues/259

Edit: I think where I started going wrong and nearly gave up was that I was trying to improve the testability of the feature and I got really caught up in my own head unable to work around how SageTV works to allow for good unit testing.