SageTV vs. MythTV

[drewg]

Originally Posted by valnar

I can't speak for MythTV, but let the record show I've never had a problem recording since Sage version 3.

Having reliable hardware helps (Intel based, 7200rpm quality drives, formatted correctly, reliable tuners, etc.)

My server even has ECC memory, but none of that has anything to do with my issues. Of the issues I've had only one would have been helped by infinitely fast hardware, the rest were purely software bugs. The problem is that the actual digital tuning system on SageTV appears to be rather fragile as compared to MythTV. I've experienced at least 4 bugs (now fixed) that caused missed recordings or jittery recordings on SageTV that I never had on MythTV. Gory details:

1) We have a PBS station that used to switch its subchannels around. They would show 1 1080i + 1 480i from 8pm-11pm, and 4 480i channels at all other times. SageTV would fail to tune the proper channel, as it would cache tuning data from when it was started. Eg, if sagetv was started at noon, then it would never be able to record something on the 1080i channel during primetime. If sagetv was started at 9pm, then it would fail to record things from one of the 4 480i channels after 11pm. This was fixed in the 6.4 timeframe. I believe the fix was to re-parse the transport stream to find the correct program stream each time a channel is tuned, rather than caching.

2) Unlike all other linux DVB software, SageTV doesn't close the DVB device between recordings. Because of this, data from the previous channel might linger in the kernel DVB ringbuffer and cause improper parsing of the newly tuned transport stream. This would result in either recordings from the wrong subchannel, or recordings with either audio- or video-only. This would happen to me every few months in V6, and about twice a week in V7. Qian explained the bug to me, and I read the DVB core source & found a fix for him -- resize the DVB ringbuffer after tuning the new channel. Resizing the buffer has the side effect of discarding any unread data, so that SageTV can be certain it is parsing the correct transport stream. This was fixed in the final RC (eg, V7 release).

3) There was yet another tuning bug where if a broadcaster would adjust their clock, the time jump in the stream would confuse the parser, and it would fail to tune the channel. This was fixed sometime around V7's release.

4) SageTV on linux uses a DVB ringbuffer size that is far, far, far too small for HD recordings. It just takes the default size of 1.8MB, which is less than a second of buffering for an HDTV source and about 1/10th of what MythTV uses. This caused stuttery recordings for me for *YEARS*. Whenever my HD100 would put up the spinning wheel (like after exiting a recording, browsing to a new menu for the first time, etc) I'd get a glitch in whatever was currently recording. I spent years fooling around with using different JVMs, using different thread priority & garbage collection options, etc. I went so far as to setup a parallel MythTV installation, and record shows with MythTV to prove the bug was SageTV. The MythTV recordings were always glitch free. I worked around this for quite a while by building the linux DVB drivers from source and increasing the default ringbuffer size. This made my recordings perfect.

Qian finally added a feature in V7 that allows the user to override the default value. I think it is still undocumented, so I'll explain here -- just create a file in the SageTV server directory adapter0.cfg with the line dmx_buffer_size=12451840. Repeat for all tuners. After doing that & reverting to the standard DVB driver core, my recordings were perfect.

All of these have been fixed in V7, and so far V7 has been as reliable as MythTV for me. I'm just hoping I don't find any new bugs, as I seem to be really "lucky"..

Drew