I have noticed MythBackend spits out these messages and at same time I get playback stuttering or even freezes for 3 or 4 seconds when a lot of them come through at once. I left TV running overnight and in morning it was over 2 minutes behind, though happily still playing. It is most noticeable when viewing the horizontal scrolling news ticker on a news channel as it will go jerky every now and then.



I did some digging and was informed that maybe I needed newer EIT code. I am currently sticking to 0.18 (R5A30.2) as I have read of probs with 0.19 (especially with Nova-T's) so will wait a while. I presume I would need to upgrade to 0.19 to get newer EIT code?

It seems that the EIT code accesses the database a lot causing these probs so I figured maybe I could alter priorities to avoid this issue. I have tried the following:-



another alternative suggested was to stop using the over air EPG and use xmltv. I will experiment with a 0.19 sometime soon on a new drive, but don't know if it still suffers from this problem? I wonder if anyone has been down this path and has any further suggestions? I will leave it running overnight and see how far behind it is in the morning.

Well I left it running again overnight, checked it 8 hours later and Live TV was 6.5 minutes behind!!! Interestingly there didn't seem to be any new 'reschedule' messages but after 7 hours there were the following 3 messages



Though I don't see how that would account for 6.5 minutes. It seems to indicate it is continually slipping behind (no timestretch isn't on). I am at my wits end. I have spent over 2 months, 10+ hours a day trying to configure a perfect myth system (as a linux learning exercise) but ultimately I have been unsuccessful. For it to slip by 6.5 minutes over an 8 hour period would indicate there must have been many occasions when the TV picture froze for a bit or stuttered, making it unwatchable. Anyone have any clues?

Hi,

Some personal answers to your questions.

1) Does over air EPG cause my system to stutter, YES, ref this thread...

http://mysettopbox.tv/phpBB2/viewtopic. ... highlight=

2) Your livetv losing time seems similar to my problem here...

http://mysettopbox.tv/phpBB2/viewtopic. ... highlight=

My solution so far is to disable over air EPG and use XMLTV as you have stated and just put up with the time slip problem. I have spent approx 12 months trying to solve my issues including these two and was eagerly awaiting 0.19 in the hope that all would be peachy, alas, not so. In desperation I also tried SVN as I gathered that DVB tuning has been improved, again, worse.

Hope this helps

Jim.

So you are you telling me that using xmltv instead of on air EPG fixes the stuttering. OK I can workaround that.

On your other post though you say
So you are you saying that the A/V is actually in sync with the live broadcast But it is just the pause that displays an incorrect value? If that is the case that is less of a worry. I do my test using News24 as watching the smooth scrolling news ticker is the easiest way to spot problems. A quick pause tells me that it is 2.5 mins behind Live-TV However the time is correct and comparing to a freeview box I see as expected it is only actually about 3 seconds (as expected due to buffering) behind. But then I did Jump forward on myth and the clock on News24 DID go ahead 2 minutes, I went 'Back to the future' ??? Hmm I think I need to do this test again, myth has become a time machine!!! I am guessing as the only explanation that my first jump forward of 10 secs must have actually jumped to the REAL point 2 mins behind but I didn't notice, either that or Einstein was wrong! I'll report back in 8 hours

My concern was that it must be juddering a lot to fall 6 minutes behind over 8 hours. I guess I need to actually sit down and use the thing rather than running tests to see if TV watching is possible or if it hangs and judders too much for me to enjoy TV.

So are you using the very latest EIT code then. I was informed on mythtv-users IRC chan yesterday by a knowledgeable dude that there were fixes for this. He seemed to indicate the problem lay with the EIT code needing to do a lot of database ops. I would however have thought that by nice'ing mythfrontend to -15 AND enabling realtime priority in MythTV this would have raised TV Playback's priority over database access and negated that issue.

Well it certainly helped my system, although livetv is still not perfect.



Yep, that's the conclusion I came to. As you can see from my previous post nobody else seemed to be reporting this problem!

Jim.

Not wanting to sound likeI'm pointing out the obvious, but this sin't the NForce Chipset time issue again is it? For some reason under Linux and KnoppMyth the BIOS time seems to creepforward.
In the early days of my Mythenbox the clock was going screwy. It gained about 12 minutes over 24 hours, which meant lots of problems with recordings.
It turned out that there is a problem that makes the clock run fast... I never understood why or what was causing this issue but it wasaknown issue. By getting dvbdate to run every hour reduced time slip to negligable seconds.

Any modern version _should_ come with ntpd running out of the box to keep your clock in sync.

The Nvidia chipset "fast clock" problem has to do with it generating extra interupts for the rtc counter when the APIC is enabled. I've never bothered to look into it past that point.

My system has the same problem. But it that's on watching recording, and it is a lot more then just a few minutes over a couple of hours.

I don't know the exact delay, but it something like a minute or 2 over 15 minutes... Pretty annoing...

_________________
KnoppMyth R5A30.1 upgraded to MythTV 0.19
P3-900 MHz
Asus CUV board (VIA Apollo 133A)
40 Gig HD
PVR-350
Optrex Display 160*128 T6963c

VMWare 4.5.1
KnoppMyth R5A30.2 upgraded to MythTV 0.19
IDE "virtual drive"

Have you tried the old boot options "noapic" solution for this? Search for more details...

I tried the noapic solution but it made no difference

Those messages mean that the backend is checking the listings in your database (potentially searching thousands of entries) and building a set of upcoming recordings.

Depending on how fast your PC is, some stuttering will happen. Mine is plenty fast for playing back a recording while recording two others, but it I run mythfilldatabase at the same time, it will stutter a little bit.

Spending more money on a faster PC (faster disk, RAID array, more memory) will help a little bit, but you will always be able to make it stutter if you are trying to do enough stuff at the same time (e.g. preparing and burning a DVD in the background).



The problem of being a few minutes behind per day, and of not having 100% smooth tickertape scrolling, is just a small AV sync bug. You may be able to minimise this by playing with the TV playback settings (using different types of synchronisation), but basically it is the cost of being able to pause and rewind live TV.


My advice? Don't sweat it. Set your machine to record the stuff you want to watch, and go outside to enjoy yourself!

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

No a 2800mhz cpu is plenty fast enough to play/record 5 or more video streams in real time. The problems are quite simply bad coding. Having upgraded to 0.19 I am finding it uses around 60% cpu merely for TV playback! (about 10x the cpu of 0.18) Unless the project management get a serious grip mythtv will end up as a dodo. I will reinstall 0.18 as soon as I get the time. 0.19 is truly awful in many areas. Hoping someone maintains a 0.18 branch