RFC: Amarok 2.0 deadline September, 1

[Jeff Mitchell]

On Friday 13 June 2008, Dan Meltzer wrote:
> On 6/12/08, Alejandro Wainzinger <aikawarazuni at gmail.com> wrote:
> > On Thu, Jun 12, 2008 at 7:46 AM, Maximilian Kossick
> >
> > <maximilian.kossick at googlemail.com> wrote:
> > > way to many crucial tasks imo.
> > >
> >  > tasks that can be downgraded:
> >  > -all other media devices - unlikely that we'll have support for all
> >  > media devices again, but we'll be take all we can get
> >
> > I'll be doing mtp devices, not just ipods.
> >
> >  > -service framework
> >  > -service - both are the most polished part of A2 at the moment.
> >  >
> >  > new tasks:
> >  > -generic media device : crucial
> >
> > Agreed, but from what I hear this is going to be hell.  I'm confident
> >  I can get something reasonably usable, but generics are currently at
> >  the end of my todo list.  I can work on that instead of MTP in light
> >  of this release schedule idea though, to make it on time.
>
> I think the simplest way to handle generic media devices as
> collections would be to genericify the sqlcollection code and use
> amarokcollectionscanner + a prefixed set of tables in the database to
> show data.  The trick would be translating that properly into an
> on-disk layout when music gets synced.

It sounds simple but there are loads of issues that can present themselves 
with generic devices.  Most of the come down to the same thing, which is that 
we'd need to scan them to make them usable as a collection, and many of them 
could be over low bandwidth links (bluetooh, remote KIO, older USB 1.1-based 
devices).  Even those that aren't low-bandwidth could have issues -- like a 
60GB hard-drive based player that could take hours to scan.  If you cache the 
data in a database, how do you sync it (note that it's not really reasonable 
to assume mtimes on these kinds of devices)?  Because this could be so 
bandwidth-intensive, even if scanning of these devices is implemented, there 
must be a per-device way to opt out, so the code has to handle this case as 
well.

In 1.4 this was handled by showing a view of the filesystem and loading each 
directory on demand.  I think this might be how it has to be done for the 
generic collection, as much as that may entail nasty hacks, and not be 
searchable.  Perhaps if the user allows scanning, this could go on in the 
background, with all collection features becoming available when it is 
finished.

Because of the complexity, I'm more tempted to say Alejandro should work on 
MTP after iPods, not generics, and have generics be a feature that will be 
reintroduced later if they cannot all three be made to work for 2.0.  All 
three are essential, but since there are loads of very popular MTP devices 
(think of the Sansas, for instance, not to mention the Zens), focusing on 
that instead of generic means that we'll be more likely to have two device 
types working for 2.0 instead of just one.

--Jeff