USB hdd support

[Jeff Mitchell]

I think that adding this support is a necessary step for supporting remote 
collections.  I want to inform/caution you about a few things, however.

First, you can't rely on having a UUID.  UUIDs are provided for some media 
devices by HAL/DBUS, but not everyone is using that, and some devices don't 
support it either.  For that reason we have a UID scheme with media devices 
where if there is a HAL-provided UID, it uses that, otherwise it uses the 
string:

manual|deviceName|deviceMountPoint

which allows the user to identify the device by name, and also gives us the 
mount point which in many cases is necessary to know.

I'm not saying that your scheme must be the same, but just keep in mind that 
automatic UUIDs are not always available and you'll have to account for that.

Second, the amaroK devs have learned the hard way, multiple times, the 
drawbacks of hacking a major piece of code together without careful planning 
(think of collectionbrowser.cpp, playlist.cpp, or the pre-redesign 
vfatmediadevice.cpp).  Converting the collection to a modular, plugin-based 
system, which could presumably also handle locally-attached media devices, is 
not an easy task and it should be very carefully planned out.  I haven't 
looked at your code enough to comment on how good/bad/ugly it looks, but if 
you are looking at this in a long-term perspective, as the first step towards 
modularization of the Collection, I can almost guarantee that unless you've 
thought about all the details of the system for a couple of weeks before 
doing much coding, you haven't thought about it enough.

Speaking of long-term, Max, if you want to commit yourself long-term, then it 
would probably be very beneficial to Andrew to have someone to work with 
towards modularization of the Collection, and I'd urge you to hold off 
applying this code until then. Since SoC didn't accept him (grrrr), he won't 
be able to commit himself as much as he would have been able to had he been 
funded, so having a second person to work with helps all around.  (It would 
even if he *had* been accepted, but you know, gotta earn your pay... :-)  ).

--Jeff


On Monday 29 May 2006 12:39, Andrew Turner wrote:
> Ian,
>
> We support USB devices both as "Media Devices", allowing you to copy
> files to/from the device, and also (if it's mounted) as just as
> another folder in the Collection. This patch changes the behaviour of
> the second type so that if you remove the USB device, it doesn't
> remove the relevant rows from the collection database, but rather
> disables them. This is obviously beneficial, and could be extended to
> provide support for remote collections.
>
> I have added on an email exchange Max had with me which covers the
> impementation. Due to the joys of top-posting, it's best to read from
> the bottom.
>
> Also, a quick thought on the patch:
> I believe "upgrading" the DB shouldn't be necessary, assuming it
> doesn't touch the "permanent" tables (eg statistics). A version number
> bump should therefore suffice (not that I know where in the code it
> is).
>
> Andrew
>
> ______
>
> Max,
>
> So far, I haven't actually done any coding. The reason Jeff pointed
> you to me is that I applied for Google's Summer of Code to make the
> Collection Browser modular, but didn't get accepted. I will though
> probably be doing some coding on it in a while, once I've finished my
> exams, which is in about 2 weeks.
>
> The way I was thinking of doing it would be to make a plugin system
> for the Collection Browser, with plugins for remote collections (eg
> Ampache www.ampache.org and iTunes' DAAP, which is being implemented
> by Ian Monroe) and for media devices. For remote collections, this
> would work well, as they generally give you structured results, so you
> could quite easily get a list of all the artists in the remote
> collection. For media devices, you obviously can't get a structured
> list without scanning the whole device, which is not something you
> want to have to do very often. I hadn't really thought of a good
> solution for that, but I think yours is.
>
> One other advantage yours would have over mine is the ability to keep
> track of scores and ratings for all types of media, as, if I
> understand correctly, it would use the database, where mine would only
> use the Collection Browser.
>
> My current thoughts about how best to do things are far more similar
> to yours. I would suggest changing the DB and adding unique device ID
> and relative path columns (probably just to the tags table at the
> moment). That gives you the ability to know the device ID of almost
> anything in the DB (eg whether an artist is stored on one device or
> another, or both), without having to try to remove the URL column
> (something that maybe ought to be done eventually, but might prove
> hard work). Then, all removable and remote devices have an ID (for
> remote shares, you could just hash on the URL of the root) and each
> song can have some kind of device specific path. For media devices,
> that might just be the actual relative path, but it might be something
> like a song ID for a remote share.
>
> Obviously, with all the talk of device specific paths, a plugin
> framework still seems to me the best eventual solution, however it
> might prove to be far too large a project to attempt in one go. The
> best thing might be to do your idea first, using the extra DB columns
> (I'm assuming that's how you were going to do it) to make it so the
> incremental scanner doesn't automatically drop rows associated with
> media devices unless they are plugged in (and the file doesn't exist
> anymore). You could also make it so that it automatically updates the
> URL column in the DB if the mount point changes (although it's
> probably not likely to happen that much, it might be a nice feature,
> and a good first step to removing the URL column). The scariest part
> there would be changing the database structure, something I've never
> done myself.
>
> After that, the changes start to sound even more scary, but hopefully
> I will have finished my exams.
>
> In any case, a discussion about this sort of thing probably ought to
> happen on IRC, but I'm rather busy revising at the moment, and lots of
> the developers are currently in Holland at a conference, so may not be
> spending too much time on IRC.
>
> The one thing that may also be a problem is making major changes too
> close to a release date, but hopefully as long as the changes are kept
> small enough so that amaroK continues to work then everything will be
> fine.
>
> Just in case you don't know, the IRC channel is #amarok on Freenode.
>
> Andrew
>
> On 27/05/06, Maximilian Kossick <mkossick at gmx.de> wrote:
> > Hi
> > In response to the e-mail I sent to the mailing list yesterday, Jeff told
> > me that you are already looking at projects to make amarok handle music
> > on removable media devices better.
> >
> > It has been annoying me for a while that i can't use the amarok to listen
> > to the music stored on my external  usb harddisk without having to
> > rebuild the collection from time to time because i forget to connect the
> > usb devices in the right order. Now that the exams are over I have
> > finally some time to do something about it.
> >
> > I have already written some code to identify harddisks by their uuid
> > (using parts of the removable media device framework already available in
> > amarok), and then identify files by a combination of the harddisk's id
> > and the relative path on that harddisk. The code figures out on which
> > harddisk a file is on by comparing its absolute path with all known mount
> > points. As soon as somebody figures out a way to uniquely (or
> > sufficiently unique) identify other devices like cd-roms or even network
> > shares which are mounted, it should be pretty straightforward to add
> > those devices.
> >
> > Before I work further on my code, I would like to know what other ideas
> > are there to handle files on removable medias in the collection. Jeff
> > mentioned two projects, one which sounded similiar to what I am doing,
> > and another about modularizing the collection.  Are there any projects
> > actively worked on? If so, I would like to help there instead of writing
> > a second solution to the problem. If not, are there any ideas or code
> > which I could use and develop further instead of my code or in my code?
> >
> > -Max
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok