elisa-developers team mailing list archive

[Peter <peter@xxxxxxxxxxxxxxxxxxxxx>]

On Tue, Jul 6, 2010 at 10:34 PM, Olivier Tilloy <olivier@xxxxxxxxxx> wrote:
>
>>> Otherwise as Olivier has pointed out, any effort to continue Moovida 1.0
>>> more or less as is would need new hosting etc (but so would any new
>>> rewrite as Florian was outlining). Personally in the short term I'm happy
>>> running Moovida 1.0 from bzr on Linux.
>>
>> I talked to Florian about what we are doing as "We should treat the
>> fork in a similar way the Plex guys forked XBMC".
>> Meaning, they took what they needed from the XBMC project, applied
>> their vision to it, new name (Plex), new hosting and ended up with a
>> much more satisfying and successful end product.
>
> No doubt that this is the way to go. The open question now is: do we
> want (is it worth?) to invest time and efforts in releasing a
> maintenance version of Moovida 1.0, with bug fixes? If so, what bugs do
> we want fixed, and what exactly do we want to release?
> All opinions are welcome!

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?

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.

With the imminent release of the 2nd generation Apple TV, I've
been following various discussions about that. What is interesting
about this new device is it only handles the UI and playback - not
storage or media scanning which is done by iTunes on a separate
machine (or the Apple servers for rentals).

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.

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.

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.

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).

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.

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?

Peter

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 ;)