XMLTV grabber selection/navigation broken

[Nick Morrott <knowledgejunkie (at) gmail (dot) com>]

As reported on the mythtv-users mailing list some months ago (​http://www.gossamer-threads.com/lists/mythtv/users/430675), there is an issue with XMLTV grabber selection for some users.

The issue I describe below is separate to that of tv_find_grabbers taking longer than 25s to complete, causing it to fail.

There is a related video source config issue (see #6637) on which we describe the broken navigation within the video source setup page.

This testing was carried out with XMLTV CVS HEAD as of this evening, Date::Manip 6.11, QT 4.6.2 and MythTV trunk @ r25561.

Compilation info:

MythTV Version   : exported
MythTV Branch    : trunk
Network Protocol : 58
Library API      : 0.23.20100802-1
QT Version       : 4.6.2
Options compiled in:
 linux debug using_alsa using_oss using_pulse [[BR]]
using_pulseoutput using_backend using_dvb [[BR]]
using_frontend using_hdpvr using_iptv [[BR]]
using_ivtv using_lirc using_mheg [[BR]]
using_opengl_video using_opengl_vsync [[BR]]
using_qtdbus using_qtwebkit using_v4l [[BR]]
using_x11 using_xrandr using_xv using_xvmc [[BR]]
using_xvmc_vld using_xvmcw using_bindings_perl [[BR]]
using_mythtranscode using_opengl using_ffmpeg_threads [[BR]]
using_live using_mheg

I see the following behaviour:

i) Enter the "Create new video source" screen

ii) Give the video source a name (but note that a blank name is considered valid and will be stored)

iii) Choose XMLTV as the listings grabber. The first time this selected in a mythtv-setup session, tv_find_grabbers is called and there is a small delay whilst the list of grabbers is populated. When tv_find_grabbers finishes, the selected listings grabber changes back to the SchedulesDirect? config screen. The second time the XMLTV listings grabber option is chosen, the cached grabber data is used. However, only the Argentinian grabber is displayed for selection.

iv) With the tv_grab_ar grabber selected, attempt to navigate down to the Finish button - you can't as the navigation loops through all the other XMLTV grabbers that were found but are hidden (see #6637).

I have included the relevant output of running mythtv-setup with -v xmltv,extra' logging to verify that tv_find_grabbers is successfully completing, which it is:

2010-08-05 02:30:34.033 XMLTVFindGrabbers: Running 'tv_find_grabbers baseline'.
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_ar
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_ch_search
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_combiner
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_dk_dr
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_dtv_la
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_ee
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_es_laguiatv
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_es_miguiatv
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_eu_epgdata
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_fi
2010-08-05 02:30:48.122 Found /usr/local/bin/tv_grab_fr
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_hr
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_huro
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_il
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_in
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_is
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_it
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_na_dd
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_na_dtv
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_nl
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_no_gfeed
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_pt
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_re
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_se_swedb
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_uk_bleb
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_uk_rt
2010-08-05 02:30:48.123 Found /usr/local/bin/tv_grab_za
2010-08-05 02:30:48.142 XMLTVFindGrabbers: Finished running tv_find_grabbers

The issue seems solely with the display of this data and the associated navigation involved when one of them is selected.

As we near a code freeze for 0.24, is this likely to be fixed if the MythUI stuff gets bumped for 0.25?

[stuartm]

Nick, although as you rightly say the 25s timeout isn't related to the issue you are reporting, I'm still tempted to turn the tables and file that as a bug upstream. As I reported to the xmltv-dev mailing list at the time, that check used to take no more than a second, it's not the search which takes so long but the decision to restructure the scripts so that args like --capabilities are handled by the xmltv module. Instead of bailing out early, the entire script and module must be compiled to squirt out a few bytes of hardcoded text.

I'd like to remain behind --capabilities and tv_find_grabbers, but 25s+ is a ridiculously long time to wait for anything to happen in a UI. Especially when that same info could be returned in a couple of hundred ms.

[robertm]

For closure upon rewrite.

[danielk]

I'm not the person to judge the seriousness of this bug. But it should be either closed or assigned to someone familiar with xmltv to fix...

[sphery]

(In [25639]) Fix some breakage in comboboxes populated item by item caused by [23803] using a patch by Daniel K. Refs #6662, Refs #8726, Refs #8729, Refs #8730.

[Nick Morrott <knowledgejunkie <at> gmail <dot> com>]

Tested with trunk @ r25642. The grabbers combobox is now populated correctly with the list of available grabbers, but I note the following:

i) after the list is populated for the first time, the page reverts back to the SchedulesDirect? configuration page, and the user must navigate back to the XMLTV grabbers list to choose a particular grabber;

ii) navigation on the XMLTV configuration page is not natural (top->bottom) but top->bottom->top middle->bottom middle. The SD page's fields are navigated top->bottom as one might normally expect; and

iii) the XMLTV option is listed last of the 4 grabber types, even after "No Grabber"...

[Nick Morrott <knowledgejunkie <at> gmail <dot> com>]

Further testing:

Editing a pre-existing OTA video source and got stuck in the infernal loop again when trying to navigate to the Finish button. This also happens when selecting SD, None or XMLTV from the grabber type selection.

[stuartm]

I can't reproduce ii

[sphery]

(In [26662]) Fix tab order and focus issues in video sources setup. Fixes #8726 ( comment:7:ticket:8726 ). Refs #6637 ( comment:1:ticket:6637 ).

This was broken in [17597]. Because the XMLTV_generic_config widgets were added to the XMLTVConfig after the XMLTVConfig is created and displayed, they were added as (stacked, obscured) visible widgets, and, therefore, receive focus when tabbing. The patch basically reverts the non-blocking part of [17597]. In the worst case, the blocking may cause a delay of 25s (until timeout), but generally should be much shorter. The change, however, makes the screen functional and, since the screen is a Qt-based screen whose code will be replaced in the setup rewrite, I don't feel it's worth trying to salvage the non-blocking functionality.