USB hdd support

[Andrew Turner]

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