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

[jsin]

Originally Posted by stanger89

No I don't like using a DVR for live TV for reasons completely unrelated to the pause, like:

The buffering (circular or otherwise) make channel changing slow.
It chews up HDD bandwidth/space
Ties up a tuner
Affects your recording/viewing history (throws off IR)
etc
etc

Even without the pause I'd rather go direct for live TV than through a DVR. At least until with get to the point that it works like the showy instant change IPTV demos I've seen.

Whatever floats your boat. Many of us like watching live TV through a DVR because you can pause it, go backwards, etc. I have enough CPU / Disk Space / Tuners to burn. IR is one of the worst features of SageTV (they should just remove it) in my opinion.

I don't like the "pause" - I want it gone.

[stanger89]

Originally Posted by jsin

IR is one of the worst features of SageTV (they should just remove it) in my opinion.

eh, I like it. I cancel (mark Don't Like) 99% of what it picks, but that 1% it does catch makes me glad it's there.

[jsin]

Originally Posted by stanger89

eh, I like it. I cancel (mark Don't Like) 99% of what it picks, but that 1% it does catch makes me glad it's there.

Perhaps a we should start a new poll: 99% of shows chosen by IR are wrong - Are we ever going to get rid of the "IR" (or at last make it more intelligent)?

[bastafidli]

BTW, not sure if you have noticed, but NARFLEX has voted "Yes! : Sage Please give us the option of eliminating the "pause". "

[reggie14]

Originally Posted by bastafidli

BTW, not sure if you have noticed, but NARFLEX has voted "Yes! : Sage Please give us the option of eliminating the "pause". "

I didn't catch that! That's very interesting. There isn't an obvious fix to this problem (I don't think the circular buffer is a very good fix). I wonder if he has any ideas on how to get rid of the pause in a way that will make most people happy. Probably adding a circular buffer option would make quite a few people happy, although I almost certainly wouldn't use it.

I hope they at least do the "don't tune channel on back-to-back recordings" feature. That seems like a good way to significantly reduce the pause for live TV when using STBs without significantly reducing reliability. I'd use that feature.

[stanger89]

Originally Posted by bastafidli

BTW, not sure if you have noticed, but NARFLEX has voted "Yes! : Sage Please give us the option of eliminating the "pause". "

Well hey, maybe that's you guy's answer.....

Originally Posted by reggie14

I didn't catch that! That's very interesting. There isn't an obvious fix to this problem (I don't think the circular buffer is a very good fix). I wonder if he has any ideas on how to get rid of the pause in a way that will make most people happy.

I still say the "obvious" solution is to improve/rework the their dshow capture code to be able to write two streams at once from the same tuner/graph. With that, they could start the next show before finishing the current one, and then seamlessly transition between them.

Of course they'd want to tweak their always tune logic so it can be disabled for back to back recordings but still retune if there's a delay to be safe.

Probably adding a circular buffer option would make quite a few people happy, although I almost certainly wouldn't use it.

I really think most people who think they want a circular buffer, only want it because it would resolve the pause. I'm guessing most would be completely satisfied with any solution that eliminates the pause.

[MeInMaui]

Originally Posted by stanger89

I still say the "obvious" solution is to improve/rework the their dshow capture code to be able to write two streams at once from the same tuner/graph. With that, they could start the next show before finishing the current one, and then seamlessly transition between them.

I really love this solution because in addition to eliminating the pause, it would allow padding to be simultaneously written to both back-to-back recordings using a single tuner. IMO this would be a much better solution that removing padding on back-to-back recordings. There have been several times we have watched a show and it cut off with 30s left, only to realize that we already watched and deleted the show that comes on after it.

Aloha,
Mike

[reggie14]

Originally Posted by stanger89

I still say the "obvious" solution is to improve/rework the their dshow capture code to be able to write two streams at once from the same tuner/graph. With that, they could start the next show before finishing the current one, and then seamlessly transition between them.

I remember the discussion about that earlier in the thread. I didn't think there was a resolution on whether that was technically possible. It seems like it would be possible and that it work, but I know next to nothing about dshow. You'd also have to do something with the playback code, wouldn't you? So a playback graph is built for the second file before the first file is finished playing back.

Could that sort of thing work on extenders too?

[49studebaker]

Originally Posted by stanger89

No I don't like using a DVR for live TV for reasons completely unrelated to the pause, like:

The buffering (circular or otherwise) make channel changing slow.
It chews up HDD bandwidth/space
Ties up a tuner
Affects your recording/viewing history (throws off IR)
etc
etc

Even without the pause I'd rather go direct for live TV than through a DVR. At least until with get to the point that it works like the showy instant change IPTV demos I've seen.

1) A circular ram buffer would make channel changes faster since files are not open/closed.
2) Since the buffer is in ram it does not use up HDD space and ram is faster than a HDD.
3) True, if a person only has one tuner he/she can not watch/record at the same time.
4) Well a person would have to remember all tv shows watched live while not using SageTV and then manually set them "watched" in SageTV.

I like watching live tv in Sage since the program guide shows me whats on different channels. The program guide on my hdtv only show program guide data for the current channel. Also, the ability to have all channel(OTA and satellite) in one place is nice. If I used my hdtv to watch stuff live I would have to switch back and forth between inputs.

Any solution that eliminates the pause whether it is a circular buffer or not would be great.

[Fuzzy]

Originally Posted by 3dOptics

1) A circular ram buffer would make channel changes faster since files are not open/closed.
2) Since the buffer is in ram it does not use up HDD space and ram is faster than a HDD.
3) True, if a person only has one tuner he/she can not watch/record at the same time.
4) Well a person would have to remember all tv shows watched live while not using SageTV and then manually set them "watched" in SageTV.

I like watching live tv in Sage since the program guide shows me whats on different channels. The program guide on my hdtv only show program guide data for the current channel. Also, the ability to have all channel(OTA and satellite) in one place is nice. If I used my hdtv to watch stuff live I would have to switch back and forth between inputs.

Any solution that eliminates the pause whether it is a circular buffer or not would be great.

A RAM circular buffer is just a borken idea from the start. Your talking about bitrates in the 10's of megabits/second or greater... even at the low end, that's chewing up a GB of RAM every 13 minutes. Certainly not enough to keep me satisfied on a timeshifting front. Now, a RAM buffer that is just used to cover the required overlap when switching recordings would make sense. It, like all things, is just a matter of getting the software programmed to do it.. when dealing with this much data at this rate, especially when you look at the extreme numbers of simultaneous recordings users have, it gets REALLY complicated, and VERY glitch prone.

[Ja'Man]

Originally Posted by MeInMaui

I really love this solution because in addition to eliminating the pause, it would allow padding to be simultaneously written to both back-to-back recordings using a single tuner. IMO this would be a much better solution that removing padding on back-to-back recordings. There have been several times we have watched a show and it cut off with 30s left, only to realize that we already watched and deleted the show that comes on after it.

Aloha,
Mike

YES! YES! YES!! my biggest annoyance with Sage. Not sure how Directv DVR's do it, but they have this feature now. And if it gets rid of the pauses at the same time....

BTW, I dont post here much but have been using sage for many years and your sageMC is the best thing IMO that has ever happened to it. I would like to give you a very huge thank you!!!

[Graygeek]

Originally Posted by Ja'Man

YES! YES! YES!! my biggest annoyance with Sage. Not sure how Directv DVR's do it, but they have this feature now. And if it gets rid of the pauses at the same time....

BTW, I dont post here much but have been using sage for many years and your sageMC is the best thing IMO that has ever happened to it. I would like to give you a very huge thank you!!!

ditto!

[stanger89]

Originally Posted by reggie14

You'd also have to do something with the playback code, wouldn't you?

I'm not so sure, right now Sage can "seamlessly" play a recording broken into multiple pieces.

Could that sort of thing work on extenders too?

I don't see why not.

Originally Posted by 3dOptics

1) A circular ram buffer would make channel changes faster since files are not open/closed.

Maybe a little, but I think most of the delay is from the tuner tuning and the rebuffering to decode the new stream, It take a few frames of data before you've got something displayable. Well you'd definitely need more than the 2Gig a 32bit app can use in Windows.

2) Since the buffer is in ram it does not use up HDD space and ram is faster than a HDD.

You don't need to play faster, and as noted above, you'd need 10's of Gigs of RAM to make that practical.

[babgvant]

Originally Posted by stanger89

Well hey, maybe that's you guy's answer.....

I still say the "obvious" solution is to improve/rework the their dshow capture code to be able to write two streams at once from the same tuner/graph. With that, they could start the next show before finishing the current one, and then seamlessly transition between them.

Switching graphs causes a pause; the only way to truly eliminate the pause is to not stop playback.

There are ways in DirectShow to keep the same graph in use w/ different files. The most publicly accepted (GMFBridge) was developed by one of the architects of DirectShow. It uses multiple graphs behind the scenes to feed uncompressed samples into the playback graph which continuously renders them to the screen. The approach is not perfect though, I've seen many threads in various newsgroups and forums seeking assistance.

I think that Sage uses a different method currently to deal with recordings that span multiple files. My guess is that they approach the issue with their custom source filter, feeding it a "playlist" of the different segments and it concatenates the bits from multiple files into a "virtual file" before feeding it to the demultiplexor similar to how a DVD navigator "merges" vob files for seamless playback.

If my guess is correct, this is a technical barrier to eliminating pauses in live tv not only because of the differences in codecs (h.264/aac/ac-3/mpeg2/mpa) and containers (mpeg-ps, mpeg-ts) supported by the different types of tuners Sage uses, but also because different channels of the same type (i.e. ATSC) can present the data streams differently. All of the components, many of which are not Sage controlled, would need support these kinds of changes to work in this scenario. Keep in mind you can't swap decoders and keep the same graph running.

I don't think that either mepg-ps or mpeg-ts support dynamic codec changes in the same file (they do support simple changes to resolution and audio channels) so if a circular buffer was used, Sage would (like MS who scrapped their ASF base DVR-MS container for the entirely new WTV) have to design a container that could handle these changes, and (like MS) ship A/V decoders that could handle dynamic codec changes. Both of which are probably unlikely given the associated cost.

[rosemary]

Excellent technical analysis. Only thing I have to add is this:

Originally Posted by babgvant

Both of which are probably unlikely given the associated cost.

This is quite possibly true, but you have to factor in that it's costing them money not to fix it. The amount is a matter of debate, of course. But it's definitely non-zero.

[babgvant]

Originally Posted by rosemary

This is quite possibly true, but you have to factor in that it's costing them money not to fix it. The amount is a matter of debate, of course. But it's definitely non-zero.

Forced to speculate, I'd say that the cost of a home grown circular buffer is probably prohibitive. The most likely candidate, because it deals with uncompressed samples so the it's not necessary to deal with decoder/splitting issues (and the source and binaries are free to use) is GMFBridge.

Which, unless they are already using it (or a similar approach), would require significant effort to incorporate into the playback framework.

[cjalphonso]

New guy here, i've been watching this post as I too would like the pause to go away. I've looked at all the theories on how to do it and it made me think of something. I bet this is exactly why Tivo only allows for a 1/2 hr. buffer. I know they dedicate a certain portion of the hard drive for that buffer as well. They must have run into the same problem and I bet the dedicated buffer is part of the answer.

[stanger89]

Or they started with a Time shifting design ("Pause live TV" was always their catch phrase) and all you need is a buffer for that. But regardless, in a single user environment like a Tivo, a buffer works pretty well. It's when you get into a client/server architecture like Sage that the limitations of such a design become very apparent.

[cjalphonso]

On the Series 1 tivo's, the live tv buffer was completely separate from the recordings it did. If you were watching live tv and hit record, it could only record from that point on. It wasn't until a later upgrade that you could retain the buffer in your recording. Yes, I bought the very first Tivo when it came out and that how they did it. I still think it has something to do with how they resolved the pause issue.

[rosemary]

You could hack your TiVo and set a variable that would allow you to set the buffer space to as large as you wanted (up to the amount of free space). 30 minutes was just the supported size. As TiVo was a consumer-ready device, they took a one-size-fits-all approach.

(Also still has an original Series 1 TV in a box, waiting for the Smithsonian to come calling)