USB hdd support

Mon May 29 21:19:56 UTC 2006

Hi
I've been thinking about how to improve amarok's handling of songs which are 
not available all the time for a while now, and after my exams I finally had 
the time to sit down and write some code. I am fully aware that this is a 
major change and needs some careful thought, but most of the devs were in 
Holland, Andrew is still busy with his exams, and my fingers were itching to 
write some code, so I went ahead and wrote it. Simply regard the patch
I sent to the mailing-list as a proof-of-concept. It  is barely able to play 
music at the moment ( for a while, then the GUI freezes ).

It is probably a good if I describe the changes I have in mind in some more 
detail, which would allow a better discussion about it. Although the e-mail 
exchange between Andrew and me contain some information, both of us were 
already thinking along the same lines so it might be a bit cryptic for 
somebody else. How do you prefer me to do that? An e-mail to the mailing-list 
or on the wiki?

Cheers, Max

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20060529/2cc66e30/attachment.sig>