elisa-developers team mailing list archive

[Peter <peter@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, Sep 12, 2010 at 9:29 PM, Michał Sawicz wrote:
> 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...

And I recognise everyone working on this now is doing so in their
free time.

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

Do you mean if you want to manage the media from the HTPC?
As I see it, the idea is the media center UI is for consuming media,
trying to manage it on a TV with a 6 button remote or a touch
screen or what ever is never going to be fun. Is it worth trying?
When the automatic video scanning failed, manual categorising
on Moovida 1.0.x was annoyingly fiddly.

>> 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 just meant they have separated the UI for media consumption
on a TV (Immersed media cente) from the UI for media management
(their modified Banshee).

I don't know if they will allow if to run on a separate machine over
the network - I'd hope so but wouldn't expect it.

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

Right - I think I'd gotten side tracked by the idea of tracker for the
local media, and the fact that would need programming effort.

What I was thinking instead was by having a media server running
on the local machine (which might use tracker internally), you could
treat local media just like remote media - less code if all you do is
talk to a server (local or remote).

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

I've heard http://github.com/jasonmc/forked-daapd works with the
iTunes 10 (where iTunes is the client), but I don't know exactly
what is supported. Of course, for a media center we'd like to talk
to talk to iTunes as the server (or forked-daapd as the server).

If UPnP/DLNA already has meta data and cover art sorted out,
then that would be more straight forward.

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

That's good.

>> 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?

Not closely enough I guess. I didn't see anything in the email about
it talking to a server - but as a prototype you wouldn't have to.

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

True.

Peter