Opened 18 years ago
Closed 18 years ago
#770 closed defect (fixed)
progress dialog in mythmusic not going away
Reported by: | 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)
Change History (14)
Changed 18 years ago by
Attachment: | progress-fix.patch added |
---|
Changed 18 years ago by
Attachment: | progress-fix-really.patch added |
---|
proposed patch (this time, for real)
comment:1 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 18 years ago by
Attachment: | mus.freeze.txt added |
---|
Changed 18 years ago by
Attachment: | mus.freeze2.txt added |
---|
comment:3 Changed 18 years ago by
Unfortunately, there's nothing obvious in the backtraces. I'm tempted to remove the progress dialog..
comment:4 Changed 18 years ago by
Milestone: | → 0.19 |
---|---|
Version: | → head |
comment:5 Changed 18 years ago by
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 18 years ago by
Attachment: | checkplaylist.diff added |
---|
Patch to add Mutex, seems to work/improve situation
comment:6 Changed 18 years ago by
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 18 years ago by
Attachment: | checkplaylist3.diff added |
---|
Alternative solution, using one shot timer
comment:7 Changed 18 years ago by
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 18 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(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.
proposed patch