Multirec merge causes backend crash with 3-digit firewire tuning

[robert.mcnamara@…]

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.

[robert.mcnamara@…]

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

[danielk]

Testing patch to try

[danielk]

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.

[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.

[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.

[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.

[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.

[robert.mcnamara@…]

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

[danielk]

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.

[danielk]

2nd test patch

[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.

[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.

[robert.mcnamara@…]

Firewire tuning - Solved. Backend Log.

[danielk]

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

[danielk]

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

[danielk]

fix

[danielk]

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

[robert.mcnamara@…]

Daniel,

Yes, this works w/ 15461.

Robert

[danielk]

(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.