Opened 11 years ago

Closed 8 years ago

#11797 closed Bug Report - General (Need more Info)

Get "UNKNOWN_COMMAND" errors on master backend when slave backend starts recording

Reported by: davideshay@… Owned by: stuartm
Priority: major Milestone: unknown
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Every time a slave backend starts a recording, the master backend gets an UNKNOWN_COMMAND error as well as other socket related errors:

2013-08-30 13:09:58.650837 E MythSocket?(1fdede0:97): Got MythEvent? on non-event socket 2013-08-30 13:09:58.650848 E PlaybackSock::SendReceiveStringList?(): No response. 2013-08-30 13:09:58.681245 N AutoExpire?: CalcParams?(): Max required Free Space: 3.0 GB w/freq: 15 min 2013-08-30 13:09:58.682951 I Canceled recording (Unknown): "American Restoration":"Cooler Kings": channel 4447 on cardid 16, sourceid 4 2013-08-30 13:09:58.683133 I Reschedule requested for CHECK 0 2466 0 AddHistory? | American Restoration | Cooler Kings | Rick plans to convert a 1950s Coke cooler into a hot-dog grill; the Pawn Stars come by with a broken-down barbers pole. | EP013286140005 2013-08-30 13:09:58.929191 E Unknown command: -10

Similarly, the slave backend also reports an error:

2013-08-30 13:09:58.922073 E Got 'UNKNOWN_COMMAND' out of sequence.

Prior to ticket/patch 11318 this used to crash the master backend, but now I get this behavior.

Ticket 11316 may also be related.

Change History (8)

comment:1 Changed 11 years ago by bobnvic@…

I'm having the exact same issue, except the slave backend will eventually segfault after one of these 'UNKNOWN_COMMAND' statements. Would a backtrace help? Like, David the MBE used to segfault as well prior to the fix in ticket 11318.

comment:2 Changed 11 years ago by David Scammell <davescammell@…>

#11780 (mine) likely the same? has a backtrace enclosed

comment:3 Changed 11 years ago by bobnvic@…

It does appear to likely be the same issue, at least the logs look the same. I'm not having an issue with the master backend having a segfault anymore since the fix for 11318 however, and it appears that it was your MBE that crashed in your tiket, right? My slave backend will reliably segfault after two or three recordings. So, the difference is whether a slave backend backtrace is helpful. Perhaps this ticket should be marked as a duplicate of yours?

comment:4 Changed 11 years ago by David Scammell <davescammell@…>

bobnvic hi, It seems certainly related, probably is a dup, perhaps leave open for now, only a dev (i'm not) would know if they are exactly the same issue. Your right, its my MBE which is faulting, my SBE seems to be solid. My MBE never records (has a virtual tuner). I'll likely do another update from git in the next couple of days and see if anything has changed but I've not caught any commits which looked related in the email. my humble opinion would be that this is a major issue for anyone with a SBE configuration in 0.27.

comment:5 Changed 11 years ago by stuartm

Milestone: 0.270.27.1
Owner: set to stuartm
Status: newaccepted

comment:6 Changed 10 years ago by paulh

Status: acceptedinfoneeded

Is this still a problem in 0.27 there have been a few related tickets fixed?

comment:7 Changed 9 years ago by Stuart Auchterlonie

Milestone: 0.27.20.27.6

comment:8 Changed 8 years ago by Karl Egly

Milestone: 0.27.6unknown
Resolution: Need more Info
Status: infoneededclosed

Closing without reply in 14 months.

Note: See TracTickets for help on using tickets.