Opened 12 years ago

Closed 12 years ago

#4472 closed defect (fixed)

Multirec merge causes backend crash with 3-digit firewire tuning

Reported by: robert.mcnamara@… Owned by: danielk
Priority: critical Milestone: 0.21
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

mythtv-multirec was merged with trunk this morning. Following a svn up and compile, I am finding that attempting to tune any three-digit channel over firewire results in a crash of the backend. I have tested 20-30 different SD and HD channels with three-digit channel numbers, and they all cause the backend to stop responding. The firewire input is not a part of a shared input group. I have made no changes whatsoever to any input groups. Attached is a backtrace on mythbackend made with mythtv, libiec61883, and libraw1394 w/ debug symbols.

Generated with SVN 15446.

Attachments (6)

firewire3digitcrash.txt (45.8 KB) - added by robert.mcnamara@… 12 years ago.
backtrace of mythbackend crash caused by 3-digit channel on firewire
4472-test-1.patch (513 bytes) - added by danielk 12 years ago.
Testing patch to try
firewiretunecrash.txt (51.7 KB) - added by robert.mcnamara@… 12 years ago.
Backtrace with further info. Crash is *not* caused by 3-digit tune.
4472-test-2.patch (7.8 KB) - added by danielk 12 years ago.
2nd test patch
firewiresolution.zip (49.5 KB) - added by robert.mcnamara@… 12 years ago.
Firewire tuning - Solved. Backend Log.
4472-v1.patch (7.0 KB) - added by danielk 12 years ago.
fix

Download all attachments as: .zip

Change History (20)

Changed 12 years ago by robert.mcnamara@…

Attachment: firewire3digitcrash.txt added

backtrace of mythbackend crash caused by 3-digit channel on firewire

comment:1 Changed 12 years ago by danielk

Owner: changed from Isaac Richards to danielk
Status: newassigned

Changed 12 years ago by danielk

Attachment: 4472-test-1.patch added

Testing patch to try

comment:2 Changed 12 years ago by danielk

Status: assignedinfoneeded

I'm going to need a little more info:

  • Repeat this with "mythbackend -v channel,record,siparser"
    • Tell me what you keyboard input do you provide to MythTV. Are you just entering LiveTV on a particular channel from the main menu, or do you start on a different channel and this when you key in a 3-digit channel?
  • Try the 4472-test-1.patch to see if that resolves the problem.
  • You say this happens with 3-digit channels, does this mean it does not happen with one and two digit channel numbers?

The test patch removes an optimization from ChannelUtil::IsOnSameMultiplex?() which might be causing this by starting a digital tuning code path which may be inappropriate for firewire recorders, but this should only be triggered if changing to a channel you are already on (like when LiveTV starts up), which is why I ask what input you are providing to MythTV.

comment:3 Changed 12 years ago by robert.mcnamara@…

No problem. I will test with this patch following my recording this evening... or if I can squeeze it in in the next hour. I enter live tv on a two digit channel. All one and two-digit channels work successfully. I then up-arrow in browse mode until I come to a known working and non-5C'ed three-digit channel... let's say, TNT HD. Mythbackend *immediately* croaks. It may be that the three-digit tuning has nothing to do with it and it is some other factor, but I can only trigger it on three-digit channel numbers, and all one and two digit channels are tested and working.

Since posting this backtrace I have rolled back to 15429 and firewire tuning on all channels was restored.

comment:4 Changed 12 years ago by danielk

Very strange. I can't find any changes where the number of digits should matter. My guess is this has something to do with how long those channels take to tune, are 3 digit channels HD channels and 2 digit channels SD channels? That might make 3 digit channels take longer to tune.

comment:5 Changed 12 years ago by anonymous

700-range channels are HD, but there are 100, 200, and 400 range channels which are SD and produce the same crash. At first I thought it might be an HD issue, but having tried a number of other three-digit SD channels, the same crash is reproducible. I will attach a backtrace shortly while attempting to tune a known good SD, three-digit channel.

comment:6 Changed 12 years ago by robert.mcnamara@…

Well, so much for it being a three-digit thing. I just noticed that channel 63 (Comedy Central) will also crash the backend. Channel 10 (PBS) appears to tune fine every time. Both are SD. So, here's how I got to there. I set starting channel in mythtv-setup to 10. I go to watch live TV and it tunes successfully. I use the arrow keys to browse to 63, hit enter... and immediate backend crash. Here is the backtrace.

I apologize for sending you off in the wrong direction initially. Thank you for looking into it so quickly, and for your hard work on multirec. This crash was *with* the patch applied, btw.

Reverting to 15429 again resolves the error.

Changed 12 years ago by robert.mcnamara@…

Attachment: firewiretunecrash.txt added

Backtrace with further info. Crash is *not* caused by 3-digit tune.

comment:7 Changed 12 years ago by danielk

Status: infoneededassigned

Okay, I think I traced down the problem to this code in TVRec::TuningGetChanNum?():

if (request.flags & kFlagLiveTV)

channel->Init(input, channum);

It tries to set the channel number before we make sure the recorder is paused, so it creates a race condition on whether the recorder has actually managed to pause yet. I need to look at what this code is used for before I can write a fix. I should have a patch for you to test by tonight.

Changed 12 years ago by danielk

Attachment: 4472-test-2.patch added

2nd test patch

comment:8 Changed 12 years ago by danielk

Ok, assuming I'm correct about the channel init, the test patch should avoid the segfault. Even if it doesn't it adds plenty of debugging output to help me trace the problem so the 'mythbackend -v record,channel,siparser' log should tell me something useful.

comment:9 Changed 12 years ago by robert.mcnamara@…

Hi Daniel,

I tested your patch against 15450. This appears to have solved the problem, thank you! I think your suspicions are right as, to be honest, my firewire sometimes takes quite some time to tune (very occasionally on the order of ten seconds before getting a lock). I am including the log from gdb (no backtrace, obviously, as there was no crash) in case the information contained in it is of any use to you.

Thank you so much for looking into this.

Changed 12 years ago by robert.mcnamara@…

Attachment: firewiresolution.zip added

Firewire tuning - Solved. Backend Log.

comment:10 Changed 12 years ago by danielk

Thanks for the testing. I'll rewrite this as a proper patch tomorrow.

comment:11 Changed 12 years ago by danielk

(In [15461]) Refs #4472. Commits some of the additional debugging from the 4472-test-2 patch.

Changed 12 years ago by danielk

Attachment: 4472-v1.patch added

fix

comment:12 Changed 12 years ago by danielk

Status: assignedinfoneeded

Can you test the attached patch? I only need logs if it doesn't work..

comment:13 Changed 12 years ago by robert.mcnamara@…

Daniel,

Yes, this works w/ 15461.

Robert

comment:14 Changed 12 years ago by danielk

Resolution: fixed
Status: infoneededclosed

(In [15470]) Fixes #4472. Refs #4480. Fixes a channel initialization problem.

The problem was causing segfaults in the firewire recorder as the channel was sometimes reinitialized on channel changes before the recorder had successfully paused. This was causing channel change scripts to be executed twice per channel change rather than once.

This adds a new function to ChannelBase?, IsTunable?() which only verifies whether the channel is tunable in terms of being a valid channel and not conflicting with input groups, but does not actually try to tune it. This also adds a parameter to ChannelBase::Init() called setchan, which when set actually intializes the channel, and when cleared does all the verification and has all the side-effects of Init() except for actually performing the initialization of the hardware.

Note: See TracTickets for help on using tickets.