elisa-developers team mailing list archive

[Michał Sawicz <michal@xxxxxxxxxx>]

Dnia 2010-09-11, sob o godzinie 21:05 +0100, Peter pisze:
> I guess from the lack of replies, that not many on the list care about
> a maintenance version of Moovida 1.0.x - but on the other hand this
> is a small closed mailing list, we could ask on the Moovida Forum?

I don't think it's a case of cares or does not - it's rather the case of
limited resources to do so...

> Getting back to Florian's email about where do we go from here
> which started this whole thread, he touched on a lot of important
> issues about aims and so on. One of these was media scanning,
> and I've mentioned in the case of photos that it would be practical
> to just access another tool's database (e.g. iTunes, DigiKam,
> F-Spot, what ever) rather than building up a duplicate database.
> What I'm outlining below goes a step further in avoiding media
> scanning as part of the media center GUI application itself.

The problem with that approach is that you can't run that on a dedicated
HTPC without reverting to standard UIs.

--8<--

> This is related to the split Fluendo are making with Moovida 2.0,
> having their yet to be released "Immersed media center" for the
> TV, and the modified Banshee for media management.

Oh? AFAIR the "Immersed media center" UI will just be a separate UI
running for Banshee on _the same_ machine, not possible to separate with
a network.

> I'm thinking that this client/server separation is a very good idea
> to use - note that the front end and back end could be on the
> same machine, or you may have a single back end server and
> a front end running on a little machine hooked up to each TV in
> the house.

Well, I like (and repeatedly said so) that idea, especially since I have
several media frontends at my house.

> Ideally I would like have a new client based on the existing
> Moovida UI which talks to an existing 3rd party server that
> handles all the messy things with media scanning, tagging,
> cover art and so on.

Well, that's what we were aiming at with the Elisa-Qt stuff, using as
much as possible of existing solutions (Tracker for local media, Grilo
for remote ones, Rygel/GUPnP for UPnP).

> The Apple protocol has been reverse engineered and
> covers music, photos and video - with meta data. See for
> example http://github.com/jasonmc/forked-daapd
> This has the appeal that we could link into existing Apple
> products and even just play content from an iTunes server
> (or a forked-daapd server running on Linux).

Not the latest version of the protocol. Last I checked you couldn't use
iTunes >= 7 with any non-Apple product. And there's not much sense in
revengineering it again as they can as easily close it again. UPnP/DLNA
is the open stuff here.

> We don't know what exactly Fluendo will use, but there may
> be other OSS systems out there (e.g. MythTV?) without the
> closed and subject to change problems with the Apple
> protocols.

Yes, UPnP.

> I hope I've managed to get across the idea I have in mind
> here. What would be interesting to try as a proof of principle
> would be a client for the Apple Digital Audio Access Protocol
> (DAAP), either using Apple's iTunes or an OSS equivalent
> like forked-daapd as the server. Things like cover art and
> meta data would be particularly important after the basics
> of browsing and playback.
> 
> So, does this sound like an interesting idea - or are there
> some major flaws I've missed?

Not really, but obviously we lack processing power :/ Also, did you
actually get a look at the Elisa-Qt prototype from the original post in
that thread?

> P.S. Thinking about this, there would still be a need for a very
> basic media scanner even in the UI client I imagine: Local
> media such as a CD-ROM, DVD, or USB memory stick or
> hard drive. Something the Apple TV doesn't do of course ;)

At least part of that we get for free from Tracker.

Cheers
-- 
Michał (Saviq) Sawicz <michal@xxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part