Opened 14 years ago

Closed 13 years ago

#770 closed defect (fixed)

progress dialog in mythmusic not going away

Reported by: mythtv@… Owned by: Isaac Richards
Priority: minor Milestone: 0.19
Component: mythmusic Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Some people on mythtv-dev report that the "Loading music" progress bar does not always go away. This patch closes one potential path (the playbackbox being destroyed), which fixed it for at least one person.

Attachments (6)

progress-fix.patch (253.9 KB) - added by mythtv@… 14 years ago.
proposed patch
progress-fix-really.patch (442 bytes) - added by mythtv@… 14 years ago.
proposed patch (this time, for real)
mus.freeze.txt (10.7 KB) - added by wseltzer <wseltzer@…> 14 years ago.
mus.freeze2.txt (10.5 KB) - added by wseltzer <wseltzer@…> 14 years ago.
checkplaylist.diff (5.8 KB) - added by stutty@… 13 years ago.
Patch to add Mutex, seems to work/improve situation
checkplaylist3.diff (5.1 KB) - added by stutty@… 13 years ago.
Alternative solution, using one shot timer

Download all attachments as: .zip

Change History (14)

Changed 14 years ago by mythtv@…

Attachment: progress-fix.patch added

proposed patch

Changed 14 years ago by mythtv@…

Attachment: progress-fix-really.patch added

proposed patch (this time, for real)

comment:1 Changed 14 years ago by Isaac Richards

Resolution: fixed
Status: newclosed

(In [8174]) Close #770 by applying patch.

comment:2 Changed 14 years ago by wseltzer <wseltzer@…>

Resolution: fixed
Status: closedreopened

I'm attaching a couple backtraces from sessions where I clicked "Play Music" on the MythMusic menu and got the "Loading Music" popup stuck onscreen at 100%. The popup does not respond to keypresses, although the computer is still getting LIRC events (wakes from display blank). This may be a more generic problem (mythtv, not mythmusic), as I've also seen other popups fail to disappear sporadically.

In the attached backtraces, no music was queued to play, though it also happens if there is music in the active playlist.

In case it's relevant I'm running a P4 hyperthreaded; Debian-base system. Backtraces were at svn 8184, and the problem persists through 8371.

Thanks. --Wendy

Changed 14 years ago by wseltzer <wseltzer@…>

Attachment: mus.freeze.txt added

Changed 14 years ago by wseltzer <wseltzer@…>

Attachment: mus.freeze2.txt added

comment:3 Changed 14 years ago by Isaac Richards

Unfortunately, there's nothing obvious in the backtraces. I'm tempted to remove the progress dialog..

comment:4 Changed 14 years ago by danielk

Milestone: 0.19
Version: head

comment:5 Changed 13 years ago by stutty@…

Attached patch, which includes a VERBOSE point to show that double timeout expiry does occur.

I was going to rewrite using QMutexLocker, but this is causing segfaults in PreviewGenerator? so thought I'd leave it to someone more knowledgeable.

Intermittent fault, but this has fixed it for me (so far).

Paul

Changed 13 years ago by stutty@…

Attachment: checkplaylist.diff added

Patch to add Mutex, seems to work/improve situation

comment:6 Changed 13 years ago by paulh

It's possible to reliably reproduce this bug by setting the time in the waiting_for_playlists_timer to a small value so it looks like you are correct.

It would probably be cleaner to change the waiting_for_playlists_timer->start() call in the constructor to be a single shot timer and restart the timer just before exiting from checkForPlaylist() that way it is impossible for the timer to fire while in checkForPlaylists().

Changed 13 years ago by stutty@…

Attachment: checkplaylist3.diff added

Alternative solution, using one shot timer

comment:7 Changed 13 years ago by stutty@…

That would work too, see attached patch, although QMutexLocker is probably the safer route from an ease of maintainance point of view.

Only funnies I've seen are that occasionally it only displays the dialogue once with 100% progress then quickly finishes, this is probably another underlying issue that triggered this fault to be uncovered in the first place.

I peppered the code with log points but have not managed to recreate since.

comment:8 Changed 13 years ago by paulh

Resolution: fixed
Status: reopenedclosed

(In [8702]) Fix #770 by applying patch. Looks like under certain circumstances more than one instance of the MythProgressDialog? was being created.

Thanks to Paul (stutty (at) gmail.com) for finally tracking down this bug.

Note: See TracTickets for help on using tickets.