The future of Sagetv?

[sic0048]

Originally Posted by sportera

I still have occasional problems with jerky video watching live TV and aggrivating 3-5 seconds of video freeze with audio studder on the hour and half hour when EPG goes to next scheduled show time slot EVERY HOUR OF EVERY DAY.

I hope you understand the reason behind the delay at a program change. Simply put, MCE and SageTV buffer their "Live" TV differently. MCE buffers a set period of time (a rolling 30 minutes for example) while SageTV buffers an entire show regardless of the length and that buffer resets when a new show comes on. That is why you see the pause.

One can argue the pros and cons of each I guess, but that is the reason for the pause.

[JetreL]

Originally Posted by Fuzzy

Sounds more like you should just use a fraction of that cost to buy an HD-200 or two...

You mention that and it's a really sound point. I came into using SageTV just as the HD-PVRs were released. Initially, I was using a HVR-1600 decoding all the clear QAM channels from my cable company and everything was fine. Comskip was super fast and I just had a server connected to the TV and placeshifter clients.

Then I decided to switch to HD through DirecTV with HD-PVRs boy did that put a monkey wrench into everything... Playback was terrible and sketchy unless I used a super-fast video card. Comskip was non-existent and sometimes playback was hit or miss.

So I finally broke down and bought a HD-100. What a great purchase. It increased the WAF factor by 100% and most my issues went away. With the HD-200 it is even better.

I still have the occasional blip but in Sage's defense my server is modded a good deal than the standard package.My point is basically I kept putting $$$ into making the server run right when the simply HD100/HD200 purchase resolved most of my issues.

[nick_l]

Originally Posted by sportera

aggrivating 3-5 seconds of video freeze with audio studder on the hour and half hour when EPG goes to next scheduled show time slot EVERY HOUR OF EVERY DAY.

I just don't understand this. Do you only use Sage to watch tv as it is being broadcast, in real time? If the answer is yes, perhaps the DirecTV DVRs might be the way to go.

If the answer is no, then you are doing something wrong (or to phrase it more democratically, there is something wrong with the setup of your system). "The Pause" happens as Sage is stopping one recording and starting another. If you are not watching "live" tv, there is no reason you should ever see the pause. It is not recorded into the program as it is, by its very existance, happening when sage is not recording.

[sportera]

Originally Posted by nick_l

I just don't understand this. Do you only use Sage to watch tv as it is being broadcast, in real time? If the answer is yes, perhaps the DirecTV DVRs might be the way to go.

If the answer is no, then you are doing something wrong (or to phrase it more democratically, there is something wrong with the setup of your system). "The Pause" happens as Sage is stopping one recording and starting another. If you are not watching "live" tv, there is no reason you should ever see the pause. It is not recorded into the program as it is, by its very existance, happening when sage is not recording.

Now I'm confused with what you mean by "live TV". I have 2-H20 DTV receivers connected to 2-HD-PVR's connected to my WHS. I watch TV through a SageTV client on my HTPC in my den which is connected to a Denon receiver and 60" LG plasma LCD.

That being said, I use the Sage EPG to select what I want to watch at any given time, hence what I call "live TV". I schedule shows I never want to miss for "recording" and either watch them "live", or later if I'm out or if I'm watching something on another channel.

Now with the above explanation given, SageTV "records" everything I tune to, so as I understand it, everything is "recorded TV" and not actually "live", so what am I doing wrong, or better said, what do I have setup wrong??? I cannot imagine most people use to Sage to "pre-record" everything and watch it later, such as the nightly news, etc.

And as for replacing my HTPC client with a HD-200, I considered that before upgrading my client hardware recently but the main consideration that stopped me was the HD-200 does not have a Blu-ray DVD drive. My WHS has a DVD drive but is located my utility room. Seems inconvienent to go to my utility room to load a DVD when I want to watch one. And I used my client occaisionally to rip DVD's to hard disk and hope one day to do the same with Blu-ray DVD's now that I've upgraded my client DVD to a Blu-ray drive. So this all said, I think I need to have a hefty client HTPC running Sage in my den vs a HD-200. Make sense?

And one of the reply posts mentioned needing a "super fast video card". I'm using a "GeForce 9500 GT 512MB 128-bit DDR2 PCI Express 2.0" for video in my client because it has an HDMI output needed to connect to my Denon receiver for switching between my PS3 (which I use to watch blu-ray and my son uses for gaming purposes) and my HTPC. Is the 9500GT video card not fast enough for my usage purposes? If not, what do you guys use?

Thanks for the replys. I'm committed to getting my issues resolved if possible before dumping it all and going to DTV DVR's. I hope my aggrivation with Sage currently isn't offending those who read and try to help through this forum. If anything I consider a big plus for Sage is this forum and the time that many take to help newbies and others, like myself, in trouble.

[cncb]

Originally Posted by sportera

I cannot imagine most people use to Sage to "pre-record" everything and watch it later, such as the nightly news, etc.

That's kind of the point of having Sage - otherwise I would just use TVs with built-in tuners. The only thing I watch "Live" anymore is some sporting events and even then it is painful to watch commercials (and you will run into the recording "pause" that is being discussed).

[tmiranda]

Originally Posted by sportera

I cannot imagine most people use to Sage to "pre-record" everything and watch it later, such as the nightly news, etc.

This is exactly what most Sage users are doing. I can't remember the last time I watched live TV. The closest I ever come to watching live TV is to start watching a sporting event an hour or so after it starts so that I can skip the commercials and am "caught up" by the time the event is ending.

[Brent]

Even with realityTV and such we watch it at least time-delayed so we can skip commercials. Most sports though we do watch live so the "pause" is noticeable during those times.

[Fuzzy]

Originally Posted by Brent

Even with realityTV and such we watch it at least time-delayed so we can skip commercials. Most sports though we do watch live so the "pause" is noticeable during those times.

This is where SRE comes in. I also only watch sports live, but the pause is never seen, because it won't occur until SRE says the game is over.

[sportera]

Originally Posted by Brent

Even with realityTV and such we watch it at least time-delayed so we can skip commercials. Most sports though we do watch live so the "pause" is noticeable during those times.

OK, but the "pause" (3-5 seconds of freezed video and audio studder) still sucks and is aggrivating to me and the, I would guess, +90% of SageTV users who upgraded to HD tuners and do not pre-record every TV show they want to watch, which gets back to reason this thread was started. It needs to be fixed. Sage sells the HD-PVR which, in my opinion, states they must have tested it and support it. I did not have the problem before going to HD-PVR's. Bottom line is people watch TV at the end of the day to relax. They expect the experience to be simple and pleasurable. I and I assume more and more SageTV users are going to look for other options soon if Sage cannot solve these issues.

I would recommend in the short term that if there is a recommended hardware and software setup minimum requirement to establish clean, video/audio playback without jerkey video and video freeze/audio studder at the beginning of each new program that Sage provide it. If there is no fix at this time, bone up to it, and give a timeline to fix it. Then at least the public can stop throwing money and time at a current problem that cannot not be fixed until a later revision comes out.

[Brent]

Originally Posted by sportera

OK, but the "pause" (3-5 seconds of freezed video and audio studder) still sucks and is aggregating to me

Agreed. It would be pure awesomeness if the powers that be fix that in a future release of SageTV...

And if you do watch sports on SageTV - do download & install SRE - it's one of the most amazing HTPC plugins ever imo here's a writeup on GeekTonic that explains what SRE does

[nick_l]

Originally Posted by sportera

the "pause" (3-5 seconds of freezed video and audio studder) still sucks and is aggrivating to me and the, I would guess, +90% of SageTV users who upgraded to HD tuners and do not pre-record every TV show they want to watch, which gets back to reason this thread was started. It needs to be fixed.

No, it doesn't. You WANT it to be fixed. There is a world of difference.

Sage was designed from the ground up to be a multi-client system. Part of the choice they made was to not use a circular buffer, as most other DVR/PVRs do. There are pluses and minuses to this choice, as you are well aware.

Sage does have a major new release coming out at some point. It is certainly possible that they have implimented some kind of change to address this issue. The makers of sage like to play their cards close to the vest, as it were, and so we have no idea what it will contain. However, as the recording of individual shows vs. the buffer has been a core of Sage since the first version, and since the more technical members of this board have theorized that it would not be a trivial matter to change the architecture of Sage to use a buffer, I would not really expect any changes on this front.

All software has quirks. I think it is doubtful that Sage is going to change to please you, so I guess you must decide if Sage has enough value in other areas to modify the way you use it to come up with an acceptable compromise.


Personally, I think Sage is a "best of Class" product. There are certainly things about it that annoy me, but there is nothing else out there that I feel comes close to the functionality and customizability that it offers.

Good luck.

P.s. Just re-read your last post. I just want to make perfectly sure we are indeed talking about the same thing. I am talking about the "pause" that happens when a scheduled show ends and a new one begins, i.e. every hour or half hour). If you are experiencing pauses in the middle of your shows (excluding things like sporting events that run over scheduled times) then something else is wrong with your system.

[toricred]

I would also question your guesses at how many Sage users don't pre-record shows. I would hazard to guess that your numbers are probably close to the opposite of the users at least on the forums. I would guess that probably 75%+ here pre-record everything and only watch sports and news live.

[brainbone]

Originally Posted by nick_l

Sage was designed from the ground up to be a multi-client system. Part of the choice they made was to not use a circular buffer, as most other DVR/PVRs do. There are pluses and minuses to this choice, as you are well aware

There are other issues related to SageTV's current buffering choices other than just the gap between contiguous recordings. The 64k cluster "requirement" for HD material is masking one such issue.

SageTV "should" be buffering to ram first, then pushing off to disk in larger chunks than it currently does. While certainly not a simple change to make, doing so would resolve the block allocation issues requiring 64k clusters to work-around the heavy fragmentation caused by the way SageTV currently flushes data to disk in far too small of chunks. And, with a fair bit of extra work (unless someone has already written a filter for doing so), should resolve be able to resolve the current requirement of rebuilding graph between contiguous recordings, causing the recording gap.

My point being, solving this issue correctly (IE: not resorting a circular disk buffer for "liveTV" -- yuk) should benefit all.

Who knows if this will show up in v7, but I can hope...

[stevech]

Live TV here means not using Sage at all - just the TV's tuner. Time-delaying just one hour (sports), doable, isn't done by us very often.

Sage records 5 or so shows per day, on average, for viewing hours/days/weeks later. It's extender-centric.

I assume this is typical usage.

[Fuzzy]

An increased buffer size isn't really going to affect the fragmentation percentage at all. Writing more than one, long, contiguous streams to the same disk WILL result in fragmentation. Single stream's work just fine on 32kB clusters. It's multiples where 64kB helps. If you have write caching enabled, you're already getting quite a bit of buffering going on. Moving this buffering into the directshow filter chain won't change much in this regard, other than chew up more RAM.

The other problem with buffering in the filter chain, is that data would not be able to be used for playback on extenders or clients. So, say we've got a 256MB RAM buffer. That buffer constitutes 105 seconds of a 19.5Mbps ATSC stream. This would mean that the playback would HAVE to be at least 105 seconds BEHIND live. How well do you think that would work for channel changing? I'd say this style of buffering would seriously DEGRADE the livetv experience. Local in-graph buffering would be fine for a single system, non extender/client centric system (like MCE for instance). However, this is not how Sage operates, and it is for good reason.

[brainbone]

Originally Posted by Fuzzy

An increased buffer size isn't really going to affect the fragmentation percentage at all. Writing more than one, long, contiguous streams to the same disk WILL result in fragmentation. Single stream's work just fine on 32kB clusters. It's multiples where 64kB helps. If you have write caching enabled, you're already getting quite a bit of buffering going on. Moving this buffering into the directshow filter chain won't change much in this regard, other than chew up more RAM.

Of course we're talking about multiple streams. Single streams work fine on even 4k clusters -- provided you don't have any other writes going on.

Windows write caching doesn't help as much as you think when it comes to block allocation, especially with multiple small commits, having relatively large gaps between each commit to the same file system from different sources. You need to commit data in larger amounts for the FS driver to allocate correctly. This is a well known issue with NTFS, and others.

Originally Posted by Fuzzy

The other problem with buffering in the filter chain, is that data would not be able to be used for playback on extenders or clients. So, say we've got a 256MB RAM buffer. That buffer constitutes 105 seconds of a 19.5Mbps ATSC stream. This would mean that the playback would HAVE to be at least 105 seconds BEHIND live. How well do you think that would work for channel changing? I'd say this style of buffering would seriously DEGRADE the livetv experience. Local in-graph buffering would be fine for a single system, non extender/client centric system (like MCE for instance). However, this is not how Sage operates, and it is for good reason.

You wouldn't need to buffer nearly as much as you think. Forcing commits to be even as small as 64KB (though you could go much higher) when writing to a 4KB cluster FS would probably help, since it would likely closely mimic the behavior seen by 64k clusters.

Edit:
This may in help understanding this issue a bit more:
http://msftmvp.com/Documents/NTFSFrag.pdf

And to clarify, I'm not suggesting the following:
- Pre-allocate the entire file before committing (you would need to buffer the entire file for this to happen).
- Buffer and commit more than is necessary (how much is necessary would take experimentation, but I'm guessing it would be relatively small).

[korben_dallas]

Originally Posted by toricred

I would also question your guesses at how many Sage users don't pre-record shows. I would hazard to guess that your numbers are probably close to the opposite of the users at least on the forums. I would guess that probably 75%+ here pre-record everything and only watch sports and news live.

Every time this issue comes up, I can't help but wonder if some people are implementing a huge complex SageTV system for the sake of just implementing something, while not focusing on their watching habits and media needs. A dual-tuner HD dvr from the cable / satellite co + a networked blu-ray media streamer would likely be a signficantly better fit and substantially less complicated.

[Fuzzy]

I think I'm not understanding why you think 64kB clusters are something to be avoided. On a drive that is primarily filled up with 1-4GB files, it would seem the larger the cluster size, the more efficient the storage system would be. In all actuality, the only reason windows doesn't default to a larger cluster size when formating NTFS volumes, is simply because the NTFS Compression doesn't work for clusters over 4K. exFAT defaults to 128kB clusters, i believe.

[brainbone]

That the write strategy of SageTV (or the filter its using) fragments should be fixed rather than masked with 64k clusters. This would simplify installation problems for new users, and, if the buffer is large enough, reduce fragmentation penalty even more than 64k clusters do, even when writing to a drive with 64k clusters.

It also opens the door to fixing other issues, like the contiguous recording gap.

[Fuzzy]

the recording gap issue has been discussed at length. the lack of a memory buffer is not the problem. There are just FAR too many architectural changes to undertake that would break nearly every other part of Sage's core. I'm sure you've read through the discussions on this already. A major part that was probably never even included in those previous discussion was the impact on network encoders (namely, that it would still not work at all with them, since their only interaction with sage is receiving a channel number, and a destination filename).