USB hdd support

Tue May 30 03:14:59 UTC 2006

Max--

The Wiki sounds like a good plan actually...it'll let you keep an up-to-date 
document of your plan and ideas that people can look at and comment about.

Thanks,
Jeff

On Monday 29 May 2006 17:19, Maximilian Kossick wrote:
> 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