Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#4096 closed defect (fixed)

Incorrect handling of the (All) datasource in mythtv-setup

Reported by: Stuart Auchterlonie Owned by: danielk
Priority: minor Milestone: 0.21
Component: channelscan Version: head
Severity: medium Keywords: scanning
Cc: Ticket locked: no


If you perform a delete all channels with the (All) datasource selected then the channels are deleted from the (All) view but the channels are not actually deleted, they are still present if you select just the datasource those channels belonged to.

Additionally, if you go and scan for channels with the (All) datasource selected for viewing, and scan against a specific datasource, when you are returned to the listing of all the channels it appears like you have no channels. They were in fact scanned and correctly associated with the datasource, but the (All) view isn't updated with the results of the scan.

Change History (7)

comment:1 Changed 13 years ago by Matthew Wire <devel@…>

See for a patch for the second problem

comment:2 Changed 13 years ago by Matthew Wire <devel@…>

See for an additional patch which remembers the last selected channel

comment:3 Changed 13 years ago by danielk

(In [14729]) Fixes #4045. Refs #4096. Fixes loading of All channels in channel editor after loading another channel list by giving the All combobox entry a non-empty value. Error report and patch by Matthew Wire.

comment:4 Changed 13 years ago by danielk

Resolution: fixed
Status: newclosed

(In [14735]) Fixes #4096. Handles All label correctly when deleting channels.

There was also another complaint in the ticket about the new channels not being shown after a channel scan, this was fixed by [14729].

comment:5 Changed 13 years ago by Matthew Wire <devel@…>

Resolution: fixed
Status: closedreopened

There is still a reproducible issue with channels not being shown.

  1. Open the channel editor.
  2. Select a channel and run the editor wizard for that channel.
  3. Now run channel scanner or transport editor.
  4. Channel list is empty until channel editor is exited and reloaded.

I cannot find out what on earth is causing this but it's very consistent here.

comment:6 Changed 13 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(In [14791]) Fixes #4096. Channel list was empty after a certain series of actions.

The problem was not in the channel editor but in the ListBoxSetting? itself which deleted the reference to the current MythListBox? widget after configWidget was called the second time. Also clearSelections() did not properly clear the list if there already was a widget. This fixes both problems.

This change requires recompiling plug-ins due to the updated binary version for change in the ListBoxSetting? signature.

comment:7 Changed 13 years ago by danielk

(In [14813]) Fixes #4128. Refs #4096. This fixes segfault on use of invalid widget pointer in "Capture cards", "Video sources" and "Input connections" screen.

* This changeset requires a "make distclean" due to ABI changes in settings.h *

These segfaults were a regression caused by [14791] which fixed #4096.

The problem in #4096 was that the "destroyed(void)" signal of the QWidget returned by ListBoxSetting::configWidget() was being used to set a different QWidget pointer to NULL. Unfortunately, the QWidget we were getting the "destroyed()" signal for was not the last QWidget ListBoxSetting::configWidget() had returned. This caused us to enter an inconsistent state.

This problem is also present in other Configurables which use a pointer to a QWidget to update the UI after the configWidget() call.

The solution is to invalidate the QWidget pointers before configWidget() is called again on a Configurable. To do this I added a virtual widgetInvalid(QObject*) method to Configurable. The one in configurable one does nothing, because most Configurables do not use a QWidget pointers. But those that do can use this to clear the pointers. This is called by all classes that call configWidget() before the widget is either deleted or configWidget() is called again on the same Configurable, basically it is called when the widget is removed from it's layout. This ensures the Configrables that rely on a QWidget pointer can be sure it is set NULLed before the widget is deleted but before configWidget() is called again.

But I also wanted to make sure that if widgetInvalid(QObject*) is called after configWidget() is called again on a Configurable, this will not cause any problems. So widgetInvalid's param is the pointer it returned from configWidget(). If this doesn't match the last pointer returned from configWidget() the Configrable must ignore the widgedInvalid() call.

Since we give the widget pointer to the Configurable in widgetInvalid() we can also call it on the destroyed(QObject*) signal. This shouldn't be needed, but if any class forgets a widgetInvalid() call on a widget they instanciated, this will prevent the Configurable from having a pointer to a deleted QWidget. Unlike the primary fix of calling widgetInvalid() at the appropriate times, this doesn't prevent a Configurable from updating the wrong QWidget if a Configurable is being updated from outside the Qt event thread, but it does prevent this error from causing a segfault.

Note: See TracTickets for help on using tickets.