GNOME Bugzilla – Bug 708341
Transfer to mass storage player hangs after last song
Last modified: 2013-12-10 22:19:40 UTC
With Rhythmbox 3.0 on Fedora 20, a mass storage 'player' (actually just an SD card with a .is_audio_player file) is detected fine, I can list the songs on it out, etc. I can transfer a set of songs to it successfully. However, RB seems to get stuck right at the end of the process. Say I picked 13 songs for transfer; it'll transfer all 13 - apparently successfully, they're all present and complete on the card so far as I can tell - but the UI will stick showing '13 of 13' with a just-about-100% progress bar, and never apparently fully 'complete' (left it that way for at least 45 minutes). I can happily do any other operation in RB while it's in this state - the app isn't hung, or anything - but I can't transfer any *more* songs to the device; if I decide I want to transfer more I have to unmount the card and start over.
Tried running from a console, nothing too interesting showed up, only a: (rhythmbox:4120): Gtk-CRITICAL **: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed around the time the transfer finishes.
Output from 'rhythmbox -D encoder' or 'rhythmbox -D transfer' would be helpful. Maybe lsof (or just ls -l /proc/`pidof rhythmbox`/fd) too.
I've seen this a couple of times now, mostly when I drag tracks to the device before it has been scanned. The actual bug here seems to be that the task list doesn't update properly, but the task itself has finished. I am able to transfer more tracks to the device when this happens though - are you sure you aren't able to?
Like I said, I left it sitting there for like half an hour. The media in question has 4000+ files on it so scanning it takes some time, but I think that should have been long enough. It's possible something else timed out while it was waiting for the scan to finish, I guess? Given that SD cards are only getting bigger, the slowness of the media scan seems to be a problem in its own right, if it has to complete before you can do anything much with the card.
Can you answer this question please: (In reply to comment #3) > I am able to transfer more tracks to the device when this happens though - are > you sure you aren't able to?
That's what the first paragraph of my comment was supposed to answer. I had dragged another set of files to the player, and sat there waiting for half an hour for them to transfer, and they never did.
commit 51db199 fixes what I've seen of this. If you could test whether it fixes anything for you, that would help a lot. Otherwise, I'll need the details I requested in comment 2. To clarify, when I say 'before it has been scanned', I mean that I haven't selected the source yet, so rhythmbox has not started scanning it. The scan only starts when you select the source or try adding tracks to it.
I'll do my best, unfortunately I'm away from home at the moment and won't be at my most responsive. But if I can manage to set things up to test the patch I will.
With 3.0-3.fc20 I do still see some completed transfers hanging around, but now I can start another transfer and it'll go ahead.
So, what would you like to do about the 'stale' transfers hanging around? Should I close this bug and file a new one for that? is there already one? thanks!
oh, looks like 51db199252f44b4b07188c3d46407a06c135e750 was for that, and it should be fixed in 3.0.1. I'll build that and confirm.
Looks improved in 3.0.1 indeed, completed transfer tasks seem to disappear from the status area after a short delay. Let's close for now, I'll file new bugs if I find more problems.