[mythtv-users] writeData: Error, zerocnt timeout , writeStringList: Error, No data written on writeBlock ?
Per Jessen
per at computer.org
Sun Dec 2 16:47:53 UTC 2012
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.
More information about the mythtv-users
mailing list