Add channel change monitoring into the signal monitor

[jppoet@…]

The signal monitor reports the status of tuning events to the mythfrontend. By adding the channel change process to this list of events, the user gets immediate feedback during a channel change. If the channel change fails or takes a long time, the user can see this, and choose to select a different channel or abort LiveTV.

Mythfrontend has a 15 second timeout before it gives up waiting for the backend to send it data. Some external channel change scripts can take over 15 seconds, which means they must be run in the background to prevent a timeout. However, if a signal monitor is desired, the channel change could not happen in the background because the monitor needs to know when the channel change is complete. By moving channel change monitoring into the "signal monitor", this problem is solved.

Note: With this change, any pre-existing external channel change scripts which ran in the background, must be modified to run in the foreground.

[jppoet@…]

Adds channel change monitoring to the signal monitor.

[eric.bosch@…]

I attempted to use this patch to test out, as I have the exact issue this is to fix... I receive compilation error:

channelscan/channelscan_sm.cpp: In member function â: channelscan/channelscan_sm.cpp:1333: error: no matching function for call to â ./signalmonitor.h:45: note: candidates are: virtual void SignalMonitor::Start(bool) make[2]: * [channelscan_sm.o] Error 1 make[2]: * Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/media-tv/mythtv-0.22_alpha20878/work/mythtv-0.22/libs/libmythtv' make[1]: * [sub-libmythtv-make_default] Error 2 make[1]: Leaving directory `/var/tmp/portage/media-tv/mythtv-0.22_alpha20878/work/mythtv-0.22/libs'

[jppoet@…]

First version of the patch was incomplete. Sorry.

New patch uploaded.

[jppoet@…]

Updated with missing diffs

[eric.bosch@…]

Thanks, working now. Seems to help a lot. Will watch for any issues.

[eric.bosch@…]

I've been running this test for several days now, and I think this may have eliminated some issues I had when running a script to prime firewire and tune, as my firewire itself can be problematic. The constant segfault no longer occurs, and it seems to return to a state to try a new channel after restarting playback, so Thank You, this seems to work flawlessly for me.

[jppoet@…]

New version of patch (channel-thread-v1.2.patch) compatible with changeset 20938

[jppoet@…]

Compatible with 20938

[jppoet@…]

Updated for trunk

[jppoet@…]

New patch (channel-thread-v1.2a.patch) updated to apply to current trunk.

[myth@…]

FWIW, the above patch together with the patch in ticket 6611 makes channel changes work fine with an HD-PVR here.

[eric.bosch@…]

I will test this again. It was working well before, but I dropped using it at one point due to a different problem. Now, after an upgrade to current CVS today (21623) my firewire capture has ceased to function, failing to lock on signal, even though firewire tester shows it as fine

[jst-myth@…]

For anyone using the patch in this bug, or an HD-PVR in general, you probably also want the deadlock fix in ticket #7132.

[r.d.vaughan@…]

At least as of r22034 this patch has a failed hunk with channelscanner_gui.cpp at line 150. Also is there a specific order that the #7132 should be applied versus the other HDPVR patches?

[jppoet@…]

Address possible issues noticed by mark.buechler and jst-myth

[jppoet@…]

Updated patch against r22038

[jppoet@…]

Update for r22198

[jppoet@…]

Updated for r22198

[Johnny Stenback <mythtv@…>]

Fix a deadlock in the last patch when a livetv user prevents a scheduled recording from starting.

[Johnny Stenback <mythtv@…>]

For the record, the patch I just attached fixes a reproducible deadlock in channel-thread-v1.4a.patch. The deadlock comes from a thread deadlocking on attempting to re-lock pendingRecLock, which is non-recursive. This is the stack for the deadlock:

#3 0x0683e982 in QMutex::lock() () from /usr/lib/libQtCore.so.4 #4 0x08075ffc in QMutexLocker::relock (this=0xad9f3828)

at /usr/include/QtCore/qmutex.h:120

#5 0x08075f7d in QMutexLocker::QMutexLocker (this=0xad9f3828, m=0x8358904)

at /usr/include/QtCore/qmutex.h:102

#6 0x00fe0352 in TVRec::RecordPending? (this=0x8358870, rcinfo=0xa85bd590,

secsleft=-1, hasLater=false) at tv_rec.cpp:383

#7 0x00fe1fa1 in TVRec::CancelNextRecording? (this=0x8358870, cancel=true)

at tv_rec.cpp:480

#8 0x0807de73 in EncoderLink::CancelNextRecording? (this=0x8387150,

cancel=true) at encoderlink.cpp:587

#9 0x080cb925 in MainServer::HandleRecorderQuery? (this=0x8389180,

slist=@0xad9f40a0, commands=@0xad9f4098, pbs=0x8384428) at mainserver.cpp:3468

...

[hansonorders@…]

channel-thread-v1.4a.patch does not compile on 0.22-fixes r22859. A reference in signalmonitor.cpp to channelchangemonitor.h seems to be the problem. Log to follow.

[hansonorders@…]

channel-thread-v1.4a compile error

[hansonorders@…]

I re-worked the channel-thread-v1.4a.patch for 22890 (attached as v1.5) and was able to build my package and install. Things were looking good until I had back-to-back recordings on the same channel/mulltiplex using the multirecord feature. Using a HD-3000 ATSC card, the second recording of the back-to-back fails. (file size is "B" in mythweb and when searched for, does not exist.)

[mythtv@mythbox-mbe ~]$ mythbackend --version
Please include all output in bug reports.
MythTV Version   : 22890M
MythTV Branch    : branches/release-0-22-fixes
Network Protocol : 50
Library API      : 0.22.20091023-1
QT Version       : 4.5.2
Options compiled in:
 linux debug using_oss using_alsa using_backend using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

config.log:
Tue Nov 24 13:19:57 PST 2009
   ./configure --prefix=/usr --arch=i686 --disable-vdpau --enable-xvmc --enable-xvmc-pro --enable-opengl-vsync --enable-libfaad --enable-dvb --enable-firewire --compile-type=debug --with-bindings=perl,python --enable-audio-alsa --disable-audio-jack --disable-audio-arts

[hansonorders@…]

Example log file when failure occurs

[hansonorders@…]

gdb debug output when back-to-back DVB failure occurs

[hansonorders@…]

channel-thread-patch for 22890

[John Patrick Poet <jppoet@…>]

Compile fix

[John Patrick Poet <jppoet@…>]

Updated patch.

hansonorders, this patch is slightly different than the one you uploaded. I have no way of testing your situation, so I do not know if it will help you.

[jpoet]

Updated patch for r23670

[jpoet]

Updated for r23670

[jpoet]

Updated patch for trunk r24052

[jpoet]

For the 0.23-fixes branch

[jpoet]

This version tightens up a critical section, a little bit.

[jpoet]

This version shrinks a critical area, and prevents a possible deadlock

[jpoet]

This version fixes a possible deadlock

[bhuffman@…]

Have some failed hunks in rev 25179: <snip> Hunk #8 FAILED at 322. 1 out of 10 hunks FAILED -- saving rejects to file libs/libmythtv/signalmonitor.cpp.rej <snip> patching file libs/libmythtv/tv_rec.cpp <snip> Hunk #2 FAILED at 404. <snip> Hunk #5 FAILED at 576. <snip> Hunk #14 FAILED at 2520. <snip> 3 out of 19 hunks FAILED -- saving rejects to file libs/libmythtv/tv_rec.cpp.rej

[jpoet]

Fixes interaction with multi-rec

[jpoet]

Fixes dvb multirec problem. Updated for trunk r25379

[jpoet]

Updated patch which fixes problem with multirec and dvb.

I big thank you to Mark Goldberg for his help in tracking down the problem and figuring out how to reproduce it.

[jpoet]

(In [25543]) Make the actual process of changing the channel part of the signal monitor. Refs #6719

For LiveTV this allows feedback to be given to the user, instead of leaving them in limbo until the channel change is complete. Also allows for situations where channel changes can take a very long time (e.g. using IR blaster).

This does require the channel change process to be moved into it's own thread, and is therefore a somewhat major change.

[jpoet]

(In [25642]) Fix issues with DiSEqC caused by [25543].

Creating the LiveTVRingBuffer before the channel change operation means that the channelbase::sourceid may not be up to date when multiple sourceids are associated with a single input. Therefore a call to CheckChannel? is needed to determine that information.

Also, when initializing the inputs in ChannelBase?, retrieve the "default input" from the DB in case the capture device is opened "on demand".

Both of these issues could result in incorrect program information being displayed when changing from one channel to another in LiveTV, as well as tuning failures due to DB lookup problems.

Thanks to Gus Bourg for discovering and diagnosing the problem with DiSEqC.

Thanks to Benny Sjöstrand for discovering the issue with opening devices "on demand", and fixing it.

Thanks to Mark Buechler for his help in analyzing log files, and diagnosing the problems.

Fixes #8742 Fixes #6719