<div dir="ltr">On Sat, May 18, 2013 at 9:21 PM, Bill Meek <span dir="ltr"><<a href="mailto:keemllib@gmail.com" target="_blank">keemllib@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/18/2013 12:53 PM, Matthias wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 18.05.2013 19:43, schrieb Stephen Tan:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi list<br>
<br>
I'm remotely administering a Mythtv system for some friends and we are getting some very frustrating behaviour from the system.<br>
<br>
Setup:<br>
We have 2 systems. One which is the Master mythbackend and Frontend, and a secondary backend box ( which also is a Frontend ). The main box<br>
has 2 x dvb-s cards which get Freesat and the backend box has 2 x dvb-t cards which get Freeview.<br>
The distribution being run is Debian 7.0 Wheezy.<br>
We are running 0.26-fixes compiled from source.<br>
<br>
Behaviour: Random crashes at any time of the day which kills the frontend as well. We were not getting much meaningful logging information on<br>
the problem, so I have re-compiled with --profile to get some debugging information and we are now running debugging in order to try and get<br>
some meaningful information about the cause of the crashes<br>
<br>
So far, we haven't had a crash, but the logs are full of the following types of errors:<br>
<br>
2013-05-18 16:46:53.704140 I [14630/14821] DVBRead mpeg/pespacket.cpp:161 (VerifyCRC) - PESPacket: Failed CRC check 0xe3967750 != 0xd67980d0<br>
for StreamID = 0x82<br>
2013-05-18 16:46:53.704150 E [14630/14821] DVBRead mpeg/mpegstreamdata.cpp:948 (HandleTSTables) - PSIP packet failed CRC check. pid(0xc0)<br>
type(0x82)<br>
<br>
Does anyone recognise these symptoms? It would help a great deal if you could share any fixes with us.<br>
<br>
One thing worth noting is that the system is now running at a high CPU load now with mythlogserver using a lot of CPU. Probably the Observer<br>
effect is in action here.<br>
<br>
thanks in advance<br>
<br>
Stephen<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/<u></u>listinfo/mythtv-users</a><br>
</blockquote>
Hi Stephen,<br>
<br>
sorry no help regarding the crashes. But regarding the high load from mythlogserver, you might want to check the number of mythlogserver<br>
processes - there should be only one, and there are reports from several people that in certain conditions, several mythlogserver processes are<br>
started, leading to 100% CPU load...<br>
<br>
I have had this behaviour myself, and I have seen the frontend (local and remote) getting unresponsive due to the backend load. So maybe this is<br>
what you are observing.<br>
<br>
Killall mythlogserver in my case did bring the system back, so I did not have crashes in that sense.<br>
<br>
I have not been able to fix the mythlogserver problem, but since moving from back/frontend to just a headless backend + several frontends on<br>
other machines, I did not have the problem again.<br>
<br>
A healthy mythlogserver process should never cause much load, I would think.<br>
<br>
HTH, good luck,<br>
<br>
Matthias<br>
</blockquote>
<br>
Hi;<br>
<br>
Good points ^^^. As long as you're building from source, take a look at this post:<br>
<br>
<a href="http://www.gossamer-threads.com/lists/mythtv/users/534986#534986" target="_blank">http://www.gossamer-threads.<u></u>com/lists/mythtv/users/534986#<u></u>534986</a><br>
<br>
Sounds very similar to antgel's experience on the -users channel this morning. The<br>
reason those two errors print is that -v siparser,record are set (respectively.) Or<br>
you're using -v all. My experience has been that errors that require action will<br>
print when using -v general (as opposed to debugging tools.)<br>
<br>
I'd suggest to you as well, that you define "Random crashes". If you see matching faults in<br>
/var/log/syslog especially with words like "segfault", then you can look for core files and use<br>
gdb (which sounds like the direction you're going with your rebuild.) The user on IRC<br>
reported not seeing any errors in syslog.<br>
<br>
Watching the commits mailing list *strongly* suggests that in 0.27 mythlogserver will<br>
be history.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Bill<br><br></font></span></blockquote><div><br></div><div style>Hi Bill and thanks for the input.</div><div style><br></div><div style>I'm just sticking my oar in here as:</div><div style>1) Stephen (the OP) is maintaining a system for me (actually my parents' system).</div>
<div style>2) I'm antgel on IRC who you referred to above.</div><div style><br></div><div style>Small world. :)</div><div style><br></div><div style>I can add that at present, we have set --loglevel debug, but no -v.</div>
<div style><br></div><div style>What has been happening is that the backend has been crashing "randomly". As Stephen said, we now have a debug build, which we hope will output a core dump - plus we are running --loglevel debug. The high CPU utilization of mythlogserver is (in my opinion) less of a concern than the crashes, although if you are telling us that -v general will very likely output as much error information as we will need to debug our crashes (stack trace notwithstanding), I guess we could add it if it will reduce the load on mythlogserver.</div>
<div style><br></div><div style>Grateful for further comments.</div><div style><br></div><div style>Antony</div></div><div><br></div>-- <br><a href="http://www.linkedin.com/in/antgel" target="_blank">http://www.linkedin.com/in/antgel</a><br>
<a href="http://twitter.com/antgel" target="_blank">http://twitter.com/antgel</a>
</div></div>