Bug 143647 - Rhythmbox looses all information about files
Rhythmbox looses all information about files
Product: Fedora
Classification: Fedora
Component: rhythmbox (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: John (J5) Palmieri
Depends On:
  Show dependency treegraph
Reported: 2004-12-23 04:57 EST by Tim
Modified: 2013-03-13 00:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-15 10:28:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim 2004-12-23 04:57:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:

I keep all my music files on an external hard drive. Whenever I start
rhythmbox without the harddrive plugged in and mounted then rhythmbox
removes all information about my music. This includes my carefully
selected playlists (I have over 4000 songs - the playlists are
important), play counts of songs, and ratings.

While I understand that rhythmbox is trying to be nice and not show
files that I might have deleted, does rhythmbox have to loose all
fucking info about them? It's rather frustrating.


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. unplug external hard drive
2. start rhythmbox
3. stop rhythmbox
4. plug drive in
5. start rhythmbox

Actual Results:  all my playlists are empty. The music library ios
empty and I ahve to reimport it. This takes ages.

Expected Results:  My playlists and song info should still be there.

Additional info:
Comment 1 Simon Heimlicher 2005-01-12 03:20:46 EST
I have exactly the same problem and it's a major nuisance. 

Why can it not just indicate by a small cross or whatever that the
song file is currently unavailable?
Comment 2 W. Michael Petullo 2005-09-03 23:10:23 EDT
My music is stored on a NFS share and I have the same problem.  If I start
rhythmbox when the NFS server is not available, the music list is lost.

See also http://bugzilla.gnome.org/show_bug.cgi?id=315204.
Comment 3 W. Michael Petullo 2005-09-04 00:16:17 EDT
See also http://bugzilla.gnome.org/show_bug.cgi?id=167763.

In the above report, it is claimed that 0.9 hides songs that are temporarily
unavailable.  This may be fixed in 0.9.
Comment 4 W. Michael Petullo 2005-09-04 18:13:01 EDT
This seems fixed in Rawhide's rhythmbox-0.9.0.cvs20050902-1.
Comment 5 Jef Spaleta 2005-09-04 19:05:26 EDT
Re: comment #4
this is still not working for me on my rawhide box.

I have music on a vfat usb drive mounted as /media/MUSIC_1/
rhythmbox-0.9.0.cvs20050902-1  does not "remember" any files on that drive, I
still have to re-import any files on the next run if I run rhythmbox while that
drive is disconnected.

Comment 6 Jef Spaleta 2005-09-04 19:14:08 EDT
Correction... it attempts to remember "one" folder location. Its not remembering
anything beyond the first folder.  I attempted to import 11 seperate folder
locations totalling about 300 songs. All the songs imported but when rhythmbox
was asked to "remember" those files only the songs from the first import are

It's also segfaulting when trying to import the full tree of 5000+ flacs but
I'll need to file that as a separate bug report. Its segging out at about 2k songs.

Comment 7 Colin Walters 2005-09-06 16:43:20 EDT
Jef: Are you mounting the device manually?  

Can you look in ~/.gnome2/rhythmbox/rhythmdb.xml; there should be a mount-point
entry; is it file:///?

As for the segfault; could you run with gdb?  My suspicion is that the GStreamer
importer is segfaulting.
Comment 8 Jef Spaleta 2005-09-06 17:45:24 EDT
(In reply to comment #7)
> Jef: Are you mounting the device manually?  

Yes I am mounting and unmounting the usb drive manually using mount and umount.
Sort of have to at the moment on my rawhide box.. nautilus isn't playing nice in
rawhide right now. (see bug 167108 in this bugzilla)

> Can you look in ~/.gnome2/rhythmbox/rhythmdb.xml; there should be a 
> mount-point entry; is it file:///?

I see <mountpoint>file:///</mountpoint>  for the songs which are not being
displayed. For the songs that do get re-displayed I see

the <location> entries for each song are correct and all start with
file:///media/MUSIC_1/  like they are suppose to.

All 242 songs do appear to be in the xml file. I'll retest this again now that I
know what to look for and see if I can narrow down when
<mountpoint>file:///</mountpoint> is being generated and when its not.

> As for the segfault; could you run with gdb?  My suspicion is that the 
> GStreamer importer is segfaulting.

Anything specific options you want when i run against gdb? I take it i need to
install the debuginfo version of rhythmbox?

Comment 9 Jef Spaleta 2005-09-06 21:50:25 EDT
(In reply to comment #7)
> Can you look in ~/.gnome2/rhythmbox/rhythmdb.xml; there should be a 
> mount-point entry; is it file:///?

Okay.. I nuked the rhythmbox.xml file and let it be recreated from scratch. I
can no reproduce the missing songs problem now.  I'll chalk this up to random
rawhide growing pains.  So to clarify.. it looks like the initial issue reported
in this thread is now dead. I did multiple seperate folder imports totalling 289
songs. All 289 songs reappear on re-mount and are hidden when the usb device is
not available.  Anything I have to suggest with regard to the new hiding feature
is going to be filed as new feature requests.

> As for the segfault; could you run with gdb?  My suspicion is that the 
> GStreamer importer is segfaulting.

crap I can't get this thing to run under gdb. Installed the debuginfo package
and gdb is just sort of hanging out. 
gdb rhythmbox
rhhtombox main windows comes up but when I go to import folder... the rbox ui
just hangs instead of going to the filechooser window. gdb gives me:

Program received signal SIG33, Real-time event 33.
[Switching to Thread -1221653584 (LWP 12117)]
0x005a0402 in __kernel_vsyscall ()

and then everything just stops there.  

Feel free to close this one out as fixed. I'll refile the segfault as a seperate

Comment 10 John (J5) Palmieri 2005-12-15 10:28:51 EST
closing as per comment #9

Note You need to log in before you can comment on or make changes to this bug.