elisa-developers team mailing list archive

[Paul van Tilburg <paul@xxxxxxxx>]

Hello guys,

Sorry for the late reply.  David's long mail required some digestion
and I also had to find the time.

On Wed, Feb 10, 2010 at 05:18:07PM +0000, David Mcleod wrote:
> I wasn't sure about where or if I should add all this on the Wiki. 
> Instead I will share it via email for now.  [...]
> Here you go...*KABAM!!!*....
> 
> Problems With Media Centers In General
> 
> - Heavy reliance on API's or crappy RSS Feeds

I agree with you on this.  However, a lot of sites trust that this is
the way users in general want to gather this stuff.  And we are not
going to be able to change this fact by per principle not replying on
feeds and/or APIs.

> - Content isn't in a form that is easily 'captured'
> - Content is usually not high quality but marketed as being better.

True, but this is not something we can change.

> - Translating the web for TV for every site/plugin is tiresome

I have been using Miro a lot and there it works quite well.
They are on "my mother can use it" level (tested this :))...  you browse
through the guide (http://miroguide.com), select a feed and watch.
Actually, I have been running the Miro app a lot in parallel with Moovida
and let if feed it's library (although nothing is recognised by
the scanner of course).

> - Difficult to just find something to watch outside 'my' content
>   (Instead App/Plugin Hopping)

Yes, agreed!  I found this also weird in Moovida.  I had to go to Youtube
and search.  Ok, by now you can do video search and also find things
in Vimeo at the same time but still.  Should I care whether I have it
local, in some feed that is downloaded in the background or plain online?

> - Users have to wait for developers to build an App/Plugin to get
>   access to content they like.

This is a reoccurring theme on the Internet.  Either you make something
generic, but then it's get complicated due to the fact that the world,
the Internet, is not perfect--there are exceptions everywhere, or... 
you make specific plugins that shield the user from this complications
and exceptions.  I feel that this is a fact of life, unfortunately. 

This does not mean however that it should be hard to write plugins.
If I look at some of Moovida's Internet media plugins internals they are
quite full of code, but actually it comes down to some tables (list
controllers), i.e. some fixed/dynamic list of categories and RSS feeds
tied to them.  So, making a plugin for my_media_site shouldn't be more
than defining such a table, done.  On the other hand, it does not mean
that it should be hard to access media that is offered on some site for
which there is no plugin.  This is also the direction that
makeinternettv.org is heading.  All kinds of blogging software and
services offer to create some way to setup a feed of your stuff.  If I
use an RSS feed reader, I can often just point to
http://someinterestingsite.com and it'll find the goods.

> - App/Plugin driven, not 'search based' (meaning I don't care how or
> where the media comes from, long as its the best possible)

Ah, yes, the point I was making above.

> - When I want good quality stuff, I want to be able to buy it. Now.

A tough thing to setup though?

> Specific Problems With Moovida/Elisa
> 
> - Playback needs to be on par with VLC

Definitely.  I think everyone agrees on this.

> - Ignores other media players and 'clues' to what the media is when scanning.

Yes, I was discussing this on the channel the other day. It is also the
other way around.  If Moovida's media scanner finds some info, why will
Moovida keep it to itself.

> - Local content and playback has to be solid before attempting anything more.

Fully agree.

> - Media scanning needs to be better or equal to XBMC/Boxee (people
>   complain about it being bad there though as well)

I'll have to test the new media scanner branch to see where we stand now.

> - The 'Hulu Technique' is vitally important for future content acquisition.

> - There are vital missing parts to Pigment to do some basic UI stuff
>   (scrolling text)

I almost don't dare to suggest this, but since there will also not be
much development on Pigment anymore (please correct me if I am mistaken),
we might want to consider alternative.

> - Lots of annoying UI building issues in general.  (i.e specifying a
>   box or item, or widget has a set pixel size...can we build UI stuff as
>   easily as it can be built on the iPhone)

Yes, there should be an abstraction layer in place. 

> - Idea bloat and pertains to the idea that it should/can do
>   everything.  It needs to concentrate on a few key features and goals
>   and stick to it.
> 
> 
> Core Key Concepts/Ideas (From David)
> 
> 1. Local content scanning, organisation and playback should be solid.

Discussed above already.

> 2. Focus more on user driven content, not developer driven content.

(I have removed the nice but long explanation!)
I agree here.  I have covered the issue above.

> 3. Media exploration

I liked the idea that was offered in the other thread.  It is somewhat
similar to what Banshee/Rhythmbox is doing with the context pane.

4. Social context

I would like to add the social aspect as the 4th point, also already
mentioned on the wiki.  It would be a real advantage w.r.t. the other
media centers if you could not only sit on the couch and surf your
media, but also share suggestions and media with your friends/family.
This is something that is done a lot online, but right now the media
center confine the scope to your local machine.

An example of this is one that I also explained on IRC a while ago is to
watch some series episode synced with friends.  I used to do this with
TV shows and we talked and commented on the show as it was live on TV.
I was lots of fun.
Now, I watch a lot of series from downloaded files and this is not really
possible anymore.  With telepathy and such tools we could easily do some
signalling between two media center instances, even also feature the
chat, who knows what is possible.
N.B. This is just a random idea, probably one of the last things that
  should be implemented :P but you know what I mean.

Kind regards,
Paul

P.S. The mail might come across as some kind of brain dump, it actually is
  but I wanted to dump it before it was lost. :)

-- 
PhD Student @ Eindhoven                     | email: paul@xxxxxxxx
University of Technology, The Netherlands   | JID: paul@xxxxxxxx
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181