Locks up when podcast download finishes

Bug #140036 reported by Matthew
6
Affects Status Importance Assigned to Milestone
rhythmbox (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: rhythmbox

Title pretty much says it all. Started happening recently. Completely removing the program, including files from ~/.gnome2 doesn't seem to have any effect. When the downloads reach 100% (doesn't matter what the feed is), the program freezes and must be forcibly quit.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem. What version of Ubuntu do you use? Could you give an example of podcast url to use?

Changed in rhythmbox:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Matthew (mcphil2) wrote :

It stopped doing it. I guess I must have had another piece of software installed that was interfering. I hadn't tried using it for a while, but I just did and the downloads are completing successfully, and the program is not freezing.

I'll keep this bookmarked in case it starts happening again.

Revision history for this message
Sebastien Bacher (seb128) wrote :

closing the bug then, feel free to reopen if you get the issue again though

Changed in rhythmbox:
status: Incomplete → Invalid
Revision history for this message
Matthew (mcphil2) wrote :

how do you reopen a bug?

Changed in rhythmbox:
status: Invalid → Incomplete
Revision history for this message
Matthew (mcphil2) wrote :

i think i figured out how to do that. OK, so now it's locking up when I START a podcast download. I attached the debuging thing from that link you gave me.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks but your trace isn't really useful, can you try again?

Revision history for this message
Matthew (mcphil2) wrote :

Sure, i'm attaching another. I'm worried that it's still not doing anything useful though.

I think this might be because the program doesn't crash. It just freezes up and I eventually have to force-quit it.

Revision history for this message
d1663m (duane-meyer) wrote :

$ rhythmbox

(rhythmbox:18405): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_string: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:18405): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_string: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:18405): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:18405): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:18405): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:18405): Gtk-CRITICAL **: file /build/buildd/gtk+2.0-2.12.0/gtk/gtktreeview.c: line 4890 (gtk_tree_view_bin_expose): assertion `has_next' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

Changed in rhythmbox:
status: Incomplete → Invalid
Revision history for this message
mikekchar (mikekchar) wrote :
Download full text (5.2 KiB)

Hmmm.. I know this bug is closed and there is another closed bug that's a duplicate, but I'm still running into the problem on Intrepid Ibex.

I've added the terminal output to this message as the previous person did, but I guess it's not enough to track down the problem. Unfortunately it doesn't crash, it just doesn't display anything in the UI (I'm guessing that GTK is very confused) so I'm not sure that a traceback would be of any use.

The feed I'm having trouble with is: http://feeds.feedburner.com/akg

I haven't been able to reproduce this at will, but it's happening fairly frequently. Pseudo-reproduction steps:

1. Double click on an un-downloaded item in the list
2. Go to a different application (each time I remember it happening I was looking at something in Akregator, although I can't imagine that there's a connection)
3. After a while realize that I didn't get notified that the download was finished.
4. Iconify the other application
5. Rhythmbox does not repaint. No amount of iconfying etc will get it to repaint or do anything. It's just an empty white window.
6. Terminal that Rhythmbox was started from has the output at the bottom of this message.
7. Kill Rhythmbox and restart it. Go to podcasts.
8. The item that I downloaded appears to have an empty status.
9. Double click on the item and it immediately has a "Downloaded" status.

If I were to guess, I *think* the issue might be because the item in question has an "unknown" time when the download starts and then it has a time. The model and the view in the table get out of sync and the whole thing gives up. I don't know why it only appears to happen when I'm not looking at it (possible just coincidence).

If possible, please reopen this bug. If you can't I'll be happy to submit another one. I've included all the information I can think to give, but if you need more, please tell me what it is and I'll try to provide it.

(rhythmbox:31923): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:31923): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_get_string: assertion `entry != NULL' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:31923): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed

(rhythmbox:31923): RhythmDB-CRITICAL **: rhythmdb_entry_unref: assertion `entry != NULL' failed

(rhythmbox:31923): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:31923): GLib-CRITICAL **: g_sequence_get: assertion `!is_end (iter)' failed

(rhythmbox:31923): RhythmDB-CRITIC...

Read more...

Revision history for this message
mikekchar (mikekchar) wrote :

Another update. Got it to happen again, this time as soon as I started downloading. Rhythmbox is definitely still working along, it's just the UI that stops. When I killed the app and started it again the progress indicator jumped to 60% immediately.

Now that I've seen that, I'm reasonably confident that the problem is in having the progress bar in the table. For whatever reason it's getting out of sync (probably some kind of race condition, but I'd have to look at the code to figure out exactly what it is).

Revision history for this message
SimpTechMike (simptechmike) wrote :

Think I might be experiencing the same thing here. Attaching backtrace

Revision history for this message
SimpTechMike (simptechmike) wrote :

Trying again to attach a backtrace with something inside the file this time.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

SimpTechMike, please open a new report, this was closed months ago, thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.