Mailing List Archive

once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms.
So, after a brief hiatus, this problem:

2011-05-04 21:05:11.556 MythSocket(8abec58:11): readStringList: Error,
timed out after 7000 ms.
2011-05-04 21:05:11.557 Protocol version check failure.
The response to MYTH_PROTO_VERSION was empty.
This happens when the backend is too busy to
respond,
or has deadlocked in due to bugs or hardware
failure.
2011-05-04 21:05:11.558 MythCoreContext: Connecting to backend server:
10.75.22.2:6543 (try 1 of 5)

and missed recordings is back again.

None of the suggestions so far have panned out, but that's not
surprising since I deeply suspect this is a problem in the code itself.

Is there nothing at all I can do to gather enough information for a
developer familiar with this code to figure out what's going wrong? Do
I just have to live with an unreliable MythTV missing recordings on a
seemingly random basis?

All in all tonight, 4 recordings were simply just not recorded.

b.
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
>
>
> None of the suggestions so far have panned out, but that's not
> surprising since I deeply suspect this is a problem in the code itself.
>
> What makes you so sure it's code related? I never get this error and my
system is running 24/7.


> Is there nothing at all I can do to gather enough information for a
> developer familiar with this code to figure out what's going wrong? Do
> I just have to live with an unreliable MythTV missing recordings on a
> seemingly random basis?
>
> All in all tonight, 4 recordings were simply just not recorded.
>
>
Have you ran it under gdb to be able to get a backtrace of what is causing
the problem.

Am not a developer by the way, but there is things to do and the one above
is it, and then create a ticket with the trace of what's happened.

Regards,
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On Thu, May 5, 2011 at 9:22 AM, Simon Jones <sijones2010@gmail.com> wrote:
>>
>> None of the suggestions so far have panned out, but that's not
>> surprising since I deeply suspect this is a problem in the code itself.
>>
> What makes you so sure it's code related? I never get this error and my
> system is running 24/7.
>
>>
>> Is there nothing at all I can do to gather enough information for a
>> developer familiar with this code to figure out what's going wrong?  Do
>> I just have to live with an unreliable MythTV missing recordings on a
>> seemingly random basis?
>>
>> All in all tonight, 4 recordings were simply just not recorded.
>>
>
> Have you ran it under gdb to be able to get a backtrace of what is causing
> the problem.
>
> Am not a developer by the way, but there is things to do and the one above
> is it, and then create a ticket with the trace of what's happened.
>

Are you running current trunk code? There were a few issues around
this that have been fixed in the last week or so. Also, do you have a
slave backend?

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 11-05-05 09:22 AM, Simon Jones wrote:
>
> What makes you so sure it's code related? I never get this error and my
> system is running 24/7.

You just don't have the same environment that I do. Really. It is code
related. See previous discussions about this issue.

> Have you ran it under gdb to be able to get a backtrace of what is causing
> the problem.

Of course. It's attached to the bug.

> Am not a developer by the way, but there is things to do and the one above
> is it, and then create a ticket with the trace of what's happened.

It's all been done already. Nothing has happened on the ticket.

b.
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 11-05-05 10:53 AM, Tom Lichti wrote:
>
> Are you running current trunk code?

No. 0.24-fixes.

> There were a few issues around
> this that have been fixed in the last week or so.

Oh, well those most definitely need to be backported to 0.24 then.

> Also, do you have a
> slave backend?

I did in the past but I have since disabled it. It was not running last
night when this happened again.

Cheers,
b.
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On Thu, May 5, 2011 at 10:59 AM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> On 11-05-05 10:53 AM, Tom Lichti wrote:
>>
>> Are you running current trunk code?
>
> No.  0.24-fixes.
>
>> There were a few issues around
>> this that have been fixed in the last week or so.
>
> Oh, well those most definitely need to be backported to 0.24 then.
>
>> Also, do you have a
>> slave backend?
>
> I did in the past but I have since disabled it.  It was not running last
> night when this happened again.

Okay, I don't know that the problems in trunk existed in.24-fixes, so
I can't really comment on that.

>From what I've seen, it's very hard to debug deadlocks, it took quite
a few tries to fix the issue in trunk.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 11-05-05 11:03 AM, Tom Lichti wrote:
>
> From what I've seen, it's very hard to debug deadlocks, it took quite
> a few tries to fix the issue in trunk.

Quite. I am by no means arguing with how difficult these types of
problems are to debug. I am willing to help in any way that I can,
given that I have the environment to reproduce. Nobody seems to want to
take me up on it though.

b.
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 5 May 2011 23:11, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> On 11-05-05 11:03 AM, Tom Lichti wrote:
>>
>> From what I've seen, it's very hard to debug deadlocks, it took quite
>> a few tries to fix the issue in trunk.
>
> Quite.  I am by no means arguing with how difficult these types of
> problems are to debug.  I am willing to help in any way that I can,
> given that I have the environment to reproduce.  Nobody seems to want to
> take me up on it though.

Brian

This is the mythtv-users list. As a first step, I'd suggest you post
your concerns to the mythtv-dev list. I can't make any promises that
it will get any more traction but you will at least stand a better
chance of grabbing the attention of the correct developer(s).

regards,

Mark
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 05/04/2011 11:13 PM, Brian J. Murrell wrote:
> So, after a brief hiatus, this problem:
>
> 2011-05-04 21:05:11.556 MythSocket(8abec58:11): readStringList: Error,
> timed out after 7000 ms.
> 2011-05-04 21:05:11.557 Protocol version check failure.
> The response to MYTH_PROTO_VERSION was empty.
> This happens when the backend is too busy to
> respond,
> or has deadlocked in due to bugs or hardware
> failure.
> 2011-05-04 21:05:11.558 MythCoreContext: Connecting to backend server:
> 10.75.22.2:6543 (try 1 of 5)
>
> and missed recordings is back again.
>
> None of the suggestions so far have panned out, but that's not
> surprising since I deeply suspect this is a problem in the code itself.
>
> Is there nothing at all I can do to gather enough information for a
> developer familiar with this code to figure out what's going wrong? Do
> I just have to live with an unreliable MythTV missing recordings on a
> seemingly random basis?
>
> All in all tonight, 4 recordings were simply just not recorded.

I can't guarantee that this is the issue, but it's definitely worth
testing. Stuart Morgan noticed that he was getting this issue and the
0-byte/missing recordings and locked up mythbackend when it attempted to
record to a spun-down HDD. He disabled HDD spin down and hasn't seen
the problem since.

If you can do the same and if it works around the problem, the
information would be /very/ useful to a dev who tries to get a real fix.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
On 11-05-05 01:50 PM, Michael T. Dean wrote:
> I can't guarantee that this is the issue, but it's definitely worth
> testing. Stuart Morgan noticed that he was getting this issue and the
> 0-byte/missing recordings and locked up mythbackend when it attempted to
> record to a spun-down HDD. He disabled HDD spin down and hasn't seen
> the problem since.

I don't have spindown on my drives configured, AFAIK. And in most
cases, like last night, there are enough recordings typically going on
that no drive will be idle (and hence spun down).

> If you can do the same and if it works around the problem, the
> information would be /very/ useful to a dev who tries to get a real fix.

I'd be happy to report the results of a command to verify the spindown
status of my drives.

b.
Re: once again, (4) missed recordings due to MythSocket(8abec58:11): readStringList: Error, timed out after 7000 ms. [ In reply to ]
Mike,

Forgive me "me too".
I can provide You tenths per months reports about deadlocked BE.
My sys is my own distro based on Arch base with full control of init
process. I'm almost sure BE deadlocks are not user misconfig result.
Personally I give 5-10% probability for environment (kernel/glibc/mysql)
and 90-95% for multithreaded code locking logical errors or thread
timing races issues.
br