Are we ever going to get rid of the "pause"? YES WE DID!

[Taddeusz]

Originally Posted by stanger89

I don't know, maybe it's possible to write your own custom dump filter that can dynamically write to arbitrary (even multiple) files on the HDD, but that would still need logic to know how to chop the video on an I-frame.

I suppose the custom filter could be signaled to begin tracking I-frames 10sec before the tv program change and to begin dumping to the new file at the I-frame closest to but not after the designated time.

[stanger89]

The real question is if it's possible to do such a thing within the confines of Directshow or not. I don't know the answer to that (though probably).

My gut tells me it's actually probably easier on the Linux side since there's no Dshow to worry about.

[49studebaker]

Originally Posted by stanger89

Not exactly, you touch upon what I think is the entire issue. The way Sage is written (if not the way it has to be) is at the very least, the entire capture graph needs to be torn down and reconstructed to change from one file to the next. This, AFAIK, is the cause of the "pause". I don't believe Directshow lets you dynamically change filter connections while the graph is running. You have to stop the graph, pull off one dump filter and add a new one.

I don't know, maybe it's possible to write your own custom dump filter that can dynamically write to arbitrary (even multiple) files on the HDD, but that would still need logic to know how to chop the video on an I-frame.

I do not think Sage would need to tear down the capture graph if a 10 second buffer is used.

This is my understanding of Sage:
1) End of tv show occurs, Sage stops receiving data from capture card
2) Playback stops since entire capture graph torn down
3) File closed
4) New file opened
5) Entire capture graph reconstructed
6) Sage resumes receiving data from capture card and plays back video from new file

With a 10 second buffer it would work this:
1) End of tv show occurs, Sage continues to receive data from capture card(video is held in 10 second ram buffer), playback never stops since video is played back from ram instead of a file
2) File closed
3) New file opened
4) Sage resumes writing data from 10 second buffer to new file

If Sage had a 10 second buffer the playback graph would not need to be torn down except for a channel change since there is never a break in video data.

I think it would be easier to just have a constant 10 second buffer to file implementation than just buffer to file at the end of a tv show.

[stanger89]

Originally Posted by 3dOptics

I do not think Sage would need to tear down the capture graph if a 10 second buffer is used.

This is my understanding of Sage:
1) End of tv show occurs, Sage stops receiving data from capture card
2) Playback stops since entire capture graph torn down
3) File closed
4) New file opened
5) Entire capture graph reconstructed
6) Sage resumes receiving data from capture card and plays back video from new file

With a 10 second buffer it would work this:
1) End of tv show occurs, Sage continues to receive data from capture card(video is held in 10 second ram buffer), playback never stops since video is played back from ram instead of a file
2) File closed
3) New file opened
4) Sage resumes writing data from 10 second buffer to new file

The problem is there's no mechanism to have Dshow render to a ram buffer. This is the issue. Traditionally you have basically a Source/Tuner Filter -> Encoder Filter -> Mux Filter -> Dump filter.

Every dump filter I've ever seen requires a file target. This is where Sage is "stuck" today, in order to change files, the graph has to be torn down. Dump filters don't write to a buffer, nor do they allow changing of file targets while active.

If Sage had a 10 second buffer the playback graph would not need to be torn down except for a channel change since there is never a break in video data.

The graph isn't torn down because of a channel change, in fact, with tuners, you can easily change channels while the graph is running. The limitation is in the dump/file writing filter that can't dynamically change it's target.

It should be possible, but it would require something totally new. Either a Sage custom dump filter that doesn't necessarily write to a file, or a complete departure from Directshow to a different capture architecture.

[robogeek]

Stanger is right. DirectShow appears to be the limiting factor here. For those that are curious...here's some light reading so you know what the SageTV devs have to deal with regarding video capture with DirectShow: http://msdn.microsoft.com/en-us/libr...31(VS.85).aspx

I think the quickest (and probably easiest) way to please the most people would be for SageTV to add an option to use a circular buffer for live TV playback with the side effect that you can't hit record in the middle of a show to record the whole show from the beginning and instead only being able to record from that point on. At the risk of thrashing the recording hard drives and potentially doubling the amount of data being moved through the server and network, if there are available tuners, there could be an additional option to allow SageTV to have an idle tuner tune to and record the same channel as the live TV tuner. This additional tuner would setup a capture graph and send the stream to a file in the recordings directory, the same way it's done now. So one tuner would be piping video to a circular buffer for playback while the other one is piping to a new file at every channel change and every timeslot change for potential recording. I can only imaging how complex the scheduling routines in SageTV are right now, without these options. Adding these two options should be doable, but would certainly not be a trivial task. SageTV would need alot of new scheduling rules to know, for example, what to do if you have 4 tuners and 3 extenders that are watching 3 different live TV channels and then throw in some favorites and manual recordings on top of that. Does it reschedule favorites to allow live TV with recording ability or does it give priority to the favorite and arbitrarily decide which live TV viewer gets their recording ability taken away temporarily?

[Fuzzy]

There is nothing inherent in DirectShow that prevents using the RAM buffer with changing file source/targets. However, the standard source and sink filters do not currently support this. It would be possible to create a specialized source and sink filter set that WOULD work with this, though I'm not sure the gains would be worth that MAJOR undertaking. MOST of us have evolved past the viewing of LiveTV anyways.. ;-)

[routerunner]

I think nothing will stop Sage to use a 10 second circular buffer implemented as ram disk....just a thought

[Jackal]

I never use SageTV or WMC to watch TV unless I'm setting something up, I only use it for recording or playback. But I'm sure that it would get annoying to have this happen over and over.

[stanger89]

Originally Posted by Fuzzy

There is nothing inherent in DirectShow that prevents using the RAM buffer with changing file source/targets. However, the standard source and sink filters do not currently support this. It would be possible to create a specialized source and sink filter set that WOULD work with this, though I'm not sure the gains would be worth that MAJOR undertaking. MOST of us have evolved past the viewing of LiveTV anyways.. ;-)

Yeah, that's my thought. Anything is possible, it's just a matter of how much time/effort/money it takes.

Originally Posted by routerunner

I think nothing will stop Sage to use a 10 second circular buffer implemented as ram disk....just a thought

Except Sage records to whatever drive has the most free space. You can't dedicate a certain location to live TV, and even if you could it would fill up very quickly and Sage would move on to another location.

[bunch92]

In the UK, there is a system called Sky+ that does not have a pause when watching live TV , and you can press the red button anytime to record the whole show ( well, the part you have watched ). So it is technically possible , but no idea how they achieve it. And you can pause, rewind ,etc ...

[robogeek]

Originally Posted by routerunner

I think nothing will stop Sage to use a 10 second circular buffer implemented as ram disk....just a thought

Except for the fact that a 10 second circular buffer would be almost as useless as a football bat.

I'm just waiting for somebody, anybody, to give any really good details about exactly how this 10 second buffer would work to provide pauseless playback. Some kind of step-by-step of what the SageTV program would need to do behind the scenes to provide pauseless playback done within the confines of DirectShow. I think too many people are assuming you can just throw a buffer into any place in the recording or playback chain and magically solve this problem. With a 10 second buffer, will SageTV keep creating video files as it currently does while maintaining this buffer on the side? If so, how will SageTV make that happen within the confines of DirectShow? Will this 10 second buffer be in the capture side or the playback side of the chain? If it's in the playback side, won't the accumulative effect of the missing gap of time, due to destroying one graph and creating another, run you out of buffer space and then you get a long 10 second pause while it rebuffers? Are we talking about using multiple tuners and coordinating the stopping of one show on tuner 1 and starting the next show on tuner 2 a split second early to avoid a gap? If so, exactly how does SageTV do that within the confines of DirectShow and how does SageTV make that work for everybody with all of the various tuner hardware combinations with each tuner having different response times? Will this added buffer step in the recording or playback chain have a negative impact on extenders or PC clients that might result in additional stuttering problems if there are any weak links in the chain? One more link in the chain means one more possible source of playback problems. Given this would be a major core enhancement for SageTV, if there is not a solution that the developers can make work well for the majority of users, then I highly doubt we'll ever get it.

The one thing I think most, if not all, of us can agree on is that a circular buffer is what we need to have pauseless playback through timeslot transitions. So how do we make it fit into the SageTV client/server architecture? To fit into the current SageTV architecture without rewriting the whole thing from scratch... Each tuner could have its own circlular buffer file. The amount of video, specified as an amount of time, would be configurable globally with per tuner overrides. The amount of disk space a buffer would take would depend on the amount of time assigned to the buffer and the live TV recording quality assigned to the tuner. And if there is more than one recording drive, SageTV would split up the buffer files equally so 4 tuners won't result in 4 circular buffers all running off of the same recording drive...so 2 recording drives=2 buffers per recording drive.

[stanger89]

Originally Posted by robogeek

Except for the fact that a 10 second circular buffer would be almost as useless as a football bat.

I'm just waiting for somebody, anybody, to give any really good details about exactly how this 10 second buffer would work to provide pauseless playback

Theoretically:

You'd make a new Directshow sink/dump filter. This filter would have some sort of intermediate buffer, the buffer would be used to, well buffer, the capture stream so that another part of the filter would be able to start/stop/change the file. Basically it could "untie" the filter from the file.

[wayner]

Why couldn't there be a circular buffer for each tuner that is a user selectable length but I would recommend a default of 2 hours as that would work for 90%+ of shows. Then if you wanted to record 90 minutes into a two hour show Sage could start a recording file at that point and concatenate the last 90 minutes of the buffer with the recording file. Is that not feasible? Thirty minutes is a ridiclously short buffer - don't forget that is from the original TiVo which shipped with a 15GB hard drive. We are in a totally different world now where you can buy a 1 TB hard drive for $90 or less - who cares if you are using 20-30GB for buffers and that would be rare as it would require several people watching live TV simultaneously.

I am shocked that so many Sage power users (anyone on this forum with more than 100 posts would be a power user I would think) watch live TV. I am a HUGE sports fan and 90%+ of the TV that I watch is sports but I never watch live. I very often watch in "near realtime" where I start watching an hour or two into a game - with two young kids there is no way I can start watching a hockey game at 7 or 7:30 - I might get to it at 9 or so after the kids are in bed. The only time that I remember catching up to a recording is the Open Championship on Sunday but that is only because it went into OT and SRE doesn't work for this, which brings up...

If you do watch sports then whey the heck aren't you using SRE? If you were then you would never get the "pause issue".

[Brent]

Originally Posted by wayner

If you do watch sports then whey the heck aren't you using SRE? If you were then you would never get the "pause issue".

Good question. I guess it's time for me to try SRE out. It's pure genious anyway so I guess I'll add it to my list of things to try.

By the way. Asked my wife about the "pause". She said "it's annoying."
So I sat there and watched the pause happen twice. Both times it lasted one second - two at most. And she still said it's annoying.

that's what we're dealing with here. I personally don't find it a big deal but others....

Now off to try out SRE.

[reggie14]

You know, I've been using Sage for almost 6 years now, and every time I see that pause my first thought is "oh no, something broke!". I only think that for an instant, but I can't shake that initial thought for some reason. And, as you'd expect, anytime that pause occurs when people are over they always think something broke too.

Still, if I had a choice between a circular buffer like MCE or Sage's current system, I'd stick with the current system.

[robogeek]

Originally Posted by stanger89

Theoretically:

You'd make a new Directshow sink/dump filter. This filter would have some sort of intermediate buffer, the buffer would be used to, well buffer, the capture stream so that another part of the filter would be able to start/stop/change the file. Basically it could "untie" the filter from the file.

That's very much like the way the preview pin works, with the exception of the ability to change files without rebuilding the graph. The only problem I see with the 10 second buffer in this configuration is that you can't timeshift back more than 10 seconds without switching the playback from the buffer to file. My thinking is that if you want to rewind 10 minutes, the 10 second intermediate buffer is no longer capable of handling the request and it must switch playback to the file. For that to work and remain pauseless, the input pin of the buffer would have to be made switchable on-the-fly to take its input from both the output of the capture device or take input from an earlier part of the video file on the disk as a sort of loopback to provide timeshifting (see attached diagram).

<edit>
Attached diagram. Is that even possible with DirectShow?
</edit>

[Fuzzy]

The Playback and Recording graphs are separate, not connection between them whatsoever (other than using the same file). There doesn't need to be a complicated circular buffer system for this to work, it just has to be able to switch the source and sink filters between files smoothly. This would take constant analysis of the stream to make sure file splits are on I-frame boundaries. Also, it would require some sort of pre-loading of the 'next file', along with a precise timestamp to make the switch, that way the playback and recording graphs are both on the same page.

Of course, this is all doable, but it is a matter of whether it is WORTH doing. It is a lot of work, and a WHOLE lot of bug potential, for something that only a smaller portion of sage users feel is that big of a problem.

[robogeek]

http://www.medialooks.com/products/d...w_filters.html

So indeed, it is possible. So it comes down to, do the custom DShow filters in-house, license them from somebody else, or it's not worth the trouble so the sooner you get use to the timeslot transition pause the happier you'll be.

I still think the circular buffer would be easier to implement and not require the effort needed to custom program all new DShow filters. It's not the most elegant solution, but it fits in with the currently used DShow filters.

[stanger89]

Originally Posted by Fuzzy

The Playback and Recording graphs are separate, not connection between them whatsoever (other than using the same file). There doesn't need to be a complicated circular buffer system for this to work, it just has to be able to switch the source and sink filters between files smoothly. This would take constant analysis of the stream to make sure file splits are on I-frame boundaries. Also, it would require some sort of pre-loading of the 'next file', along with a precise timestamp to make the switch, that way the playback and recording graphs are both on the same page.

Of course, this is all doable, but it is a matter of whether it is WORTH doing. It is a lot of work, and a WHOLE lot of bug potential, for something that only a smaller portion of sage users feel is that big of a problem.

I just thought of the same thing. That's yet another complication that would have to be tackled.

[brainbone]

Originally Posted by stanger89

Yeah, that's my thought. Anything is possible, it's just a matter of how much time/effort/money it takes.

This issue bothers myself, my wife, my daughter, and anyone else that has watched LiveTV on SageTV in my house.

IMHO, this is something that should have been tackled long ago. Many of the other shortcomings of SageTV can at least be overcome with 3rd party addons. This is one that can't.