[mythtv-users] writeData: Error, zerocnt timeout , writeStringList: Error, No data written on writeBlock ?

[Per Jessen]

Michael T. Dean wrote:

> On 11/29/2012 04:00 AM, Per Jessen wrote:
>> Last night my mythtvfrontend began to stutter, occasionally
>> freezing for 5-10 seconds. It got increasingly worse, which would
>> hold up the client to the point where I had to kill it.  After
>> restarting the backend 2-3 times, things were back to normal.
>>
>> In the backend log I found a bunch of these :
>>
>> ProcessRequest mythsocket.cpp:504 (writeData) -
>> MythSocket(25d9740:65): writeData: Error, zerocnt timeout
>>
>> http://files.jessen.ch/mythtv-writeData-Error-zerocnt-timeout
>>
>> I also got a bunch of these:
>>
>> ProcessRequest mythsocket.cpp:389 (writeStringList) -
>> MythSocket(22bcf20:-1): writeStringList: Error, No data written on
>> writeBlock (1 errors)
>>
>>
http://files.jessen.ch/mythtv-writestring-No-data-written-on-writeBlock
>>
>>
>> My setup is a couple of weeks old, frontend+backend on openSUSE
>> 12.2, hauppauge DVB-S cards, mythtv 0.25, kernel 3.4.11.  The
>> frontend is connected via wifi.
>>
>> All hints or pointers much appreciated!
>>
> 
> Best hint is that an excerpt showing only one line from the log file
> (or, a grep for the multiple repeats of that line) is pretty much
> useless for debugging what's actually happening.
> I don't know why people don't--but they should--always post a
> default-verbosity log showing startup of a program through failure.

Everything else looked unrelated, but point taken.  

> But, if you want guesses of which of the hundreds (thousands) of
> possible problems that could cause this particular symptom is to blame
> in your case, I guess I could start with a guess that your hard drive
> is dying. 

It's about a year old, but never used until deployed in this backend. 
I'm running the SMART short selftest once a day, the long selftest
every week. 

> If I didn't hit the jackpot on the first guess, you'll need to 
> get others to guess the other couple hundred problems--I don't have
> time to play this game a lot.  ;)
> 
> Seriously, though, first stop in debugging any issue should be a
> default-verbosity log showing application startup through failure. 
> For you, that means mythfrontend and, most likely, mythbackend.  Shut
> them both down, then restart mythbackend, then mythfrontend, then play
> back a recording until you see the issue, then grab copies of the logs
> since startup and post them or a link to them.
>
> Note that you're not the only person who's failing to include logs and
> is making the list play the guessing game.  It's actually a rampant
> problem, right now.  You were just the unlucky person to whom I
> responded with a plea for people to provide logs--and not excerpts of
> logs (as the person who can't figure out what's wrong is the worst
> possible person to decide what information in the log is actually
> relevant).

Here's the backend logs from startup to problem:

http://files.jessen.ch/mythbackend.20121128230632.12964.log.gz
http://files.jessen.ch/mythbackend.20121128060007.8528.log.gz

I don't see any frontend log anywhere, I guess I would need to enable
that explicitly.

I have not seen the problem again, let me know if you need any other
diagnostics.


/Per

-- 
Per Jessen, Zürich (0.3°C)
http://www.dns24.ch/ - free DNS hosting, made in Switzerland.