Bug 101125 - Offline & Removable collections are deleted
Summary: Offline & Removable collections are deleted
Status: RESOLVED DUPLICATE of bug 87391
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.2-CVS
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-08 20:25 UTC by JPD
Modified: 2006-06-11 12:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JPD 2005-03-08 20:25:00 UTC
Version:           1.2-CVS (using KDE 3.3.2, Gentoo)
Compiler:          gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
OS:                Linux (i686) release 2.6.10-gentoo-r6

With present functionality if the collection is either on mounted removable media or a network share, and the media is either removed or the network share is for some reason not reachable, the collection is deleted when amaroK discovers it is gone since it detects this in it's "watch for changes" periodic scan.
This is undesirable for several reasons and the following scenarios:
a) Audrey loves her laptop and uses it while at home to listen to music with amaroK using a network share from her desktop computer. When she arrives at university from her apartment and opens amaroK to play a couple of songs she has on her HD, her collection gets deleted. Each time she returns home she has to rebuild her collection of 100'000 songs taking up precious studying time.
b) Beatrice works in an office with 3 workstations. The one holding the music sometimes isn't rebooted after the UPS fails until the others are. When the others boot and the mountpoint isn't there because it hasn't booted yet, amaroK deletes the collection.
c) Catherine works in a studio where the network technician is very very clumsy. He frequently unplugs the network cable to the server. amaroK is fast to notice this disconnection and proceeds to delete the whole collection.
d) Daniella is very cautious with her music and keeps it backed up on several DVD's. Whenever she changes DVDs she has to rebuild her collection for the new DVD because amaroK cannot store collection specific information for removable media.
e) Elizabeth loves amaroK.

I have discussed these points with Sellaro and we have come up with some possible solutions. First of all there could be a simple warning when amaroK sees a major change. It can check fstab to see if the collection point is a mount point, then check mtab to see if it is mounted. If it isn't mounted, instead of deleting it, ignore it for N hours/days, after which a warning is sent to the user "Part of your collection, /mnt/xyz/ has been unavailable for N hours/days. Would you like it removed from your collection, Would you like to be reminded in N more hours/days, Or Would you like to keep it and remove it yourself if you change your mind?".
The collection manager would then be divided into two parts, much like many instant messengers, where it has "Online collections" and "Offline collections".
This pretty much would solve a, b, and c.

Removable media requires a slightly different approach because two DVDs should be recognized as two different DVDs. For usb media the USB GUID which is often used as a unique identifier is not actually unique. If a serial number can be polled, then it can be combined with a label if one is set then a hash could be generated from that. These could be used to identify the different removable media. Each one could have a user chosen name so when it needed media with hash c4ca4238a0b923820dcc509a6f75849b it could ask the user for "Super Music Disc #443". The details on this would of course have to be worked out but these are just some very general ideas.
Comment 1 Seb Ruiz 2005-03-09 13:07:34 UTC
That was a great bug commit.  Why were all the examples with females?

Sorry to cut it short and mark it as a duplicate :-)

*** This bug has been marked as a duplicate of 87391 ***
Comment 2 JPD 2005-03-13 00:26:38 UTC
That's alright, I will resubmit the parts which are not duplicates. Or add the missing parts to the bug which you thought it ressembled most.

As for the females, I was trying to be unselfish so used use cases featuring people other than myself and my gender. Anyway Markey complains about there not being enough of them in #amaroK anyway so I thought I could dream them up for him. I will do the sorting tomorrow.

Cheers.