Make sure to CC the developers mailing list :)
I am all for keeping it simple as an initial plugin, but maybe some
thought can eb given to some TV like features such as:
- Season Pass
- Scheduled recordings (good when you are on holiday)
- Set Reminder (Remind me when a show is on..maybe via a popup telling
me the show I set a reminder for is about to start... want to watch it?)
Initial Questions...
1. Will this be a standalone plugin, or would you also like to add the
three hierarchal items you list below in our current TV show section
on the Main Menu?
2. Where do recording exist for later review and playback? (see Q3
which might relate to it)
3. Should any recordings that have completed need the ability to add
them directly to TV Section Library currently in Moovida?
(automatically or does the user see a recording and say 'yeah, move
that to the Main TV Shows library... delete that... ok, move that...
delete that etc)
I will pick through it properly when I find some time later today.
Only scanned it quickly right now
David
On 30 Jun 2009, at 16:32, Keith Cirkel wrote:
Not one to mince words, here is my idea of a proposal:
1. A Good general overview of the 'idea'
The plugin will give Moovida users the ability to watch TV, and make
recordings of TV shows. They will have the full range of channels
they would expect, and be able to record the channels in a way they
would expect.
2. UX (User Experience) Overview
The most important factor for users is just watching TV. This should
be a priority - to make sure users can hit a button and get the TV
experience they are used to. When they begin watching a TV channel,
they should be greeted by a familiar, simple and unobtrusive HUD
describing the channel they are on, the current program airing
(which would be fetched from either the DVB card or from internet
listings), they should also be given a visual clue of the ability to
move up and down the HUD, which would give them information on other
channels. When the user hits "okay" on a differing channel to the
one currently on view, the channel changes and presents them with
the channel they "okayed". The HUD should also offer a visual clue
to move forward (and possible backward) in time, to show past and
future shows on air. If the user wants a more comprehensive guide, a
full EPG should be available, filling the screen with (for example)
a list of 10 channels, with the upcoming 5 hours of programming, for
quick browsing, also available should be a picture in picture, so
the user can watch the tv with one eye, while browsing the epg with
the other.
In addition to being able to view live TV, and browse listings, the
user should be able to pause livetv. When paused, it should start
"recording" the program, so the user can watch everything past the
moment of pause (as opposed to the moment they paused it, and the
moment they unpause). The user should also be able to rewind through
the currently watched content on the channel - so as an example, I
am am watching the news for half an hour, I should be able to rewind
to 15 minutes, pause, go for a coffee, come back and play from the
15 minute mark onwards.
Also a "scheduling" interface should be available, for the user to
browse through their EPG, and to be able to select a program to
record. This should be possible to do with the full screen EPG while
watching TV, as well as in a separate user interface (which is
easier to get to, for those specific times where you wish to just
record a program and not watch TV).
Also, a search function should be available, to search through the
EPG for a desired program. The program should be displayed with the
ability to record (if it is on later) or watch now (if it is
currently airing)
Lastly, an area to navigate through recorded programs should be
available, and the ability to watch and delete recordings should be
possible, as well as remove+rerecord. (Im not sure about this,
perhaps when a user records the program it should apear in TV Shows
or Movies sections?)
3. UI Hierarchy
TV
Watch
TV Guide
Search
Keyboard + Results
Media Results
4. Development Overview
The TV can be done in two ways (based on the discussion above).
Using MythTV backend as a service, getting the EPG data from that,
getting live tv stream from the backend, telling the backend to
change channels, and using the backend to record channels.
The other method is to use Gnome DVBD, this means providing our own
code for TV streaming, interfacing with GDVBD's EPG or using an
outside source (preferable). Also this means writing our own code
for things like recording, schedules, expiration, ad skipping, and
possibly alot more.
5. A look at other similar projects and resources
http://www.linuxtv.org/
http://www.mythtv.org/
http://linuxmce.com/
http://live.gnome.org/DVBDaemon
http://gshowtv.sourceforge.net/xmltv-druid.html (external epg grabber)
I will upload a video on Sunday of my mythtv setup, detailing as
much as I can and I'll link it here then. Also on Sunday I'll do
mockups of the UI.
----
Keith Cirkel
On Tue, Jun 30, 2009 at 12:49 PM, David McLeod <[email protected]>
wrote:
Hi All,
As I have worked on some EPG/PVR type UI's before I am willing to
revisit and create the designs for the UI that will fit in with
Moovida.
Here at Fluendo though, we do not take on any job without a good
well written initial specification of the 'idea' which details areas
to look at and possible solutions for both the back-end code (dev
work) and front end (how the user will use it).
If you guys are serious and want to get together on it to make it
happen, then please put together a specification with the following:
1. A Good general overview of the 'idea'
This should chart what it is you are looking to do, what the overall
concept is about (laymens language) without going into specific
detail.
2. UX (User Experience) Overview
This is very important and must come first before any development
happens.
Here you need to list all the features that you think the user
should be able to access.
Briefly describe how the user should use all those features and if
possible consider how you think they should each one in turn.
This of course is subject to change and is considered to be a bit of
brainstorming but it starts to formulate the idea and it focuses you
on the user and not the geeky back end 1's and 0's.
3. UI Hierarchy
This is a loose first draft at the UI hierarchy and is useful for a
discussion point when considering usability. It is very very
important in Moovida to have everything within 3 clicks before
something can play.
We strive to make sure that everything is quick to use and you
aren't going through multiple screens before something plays back or
you can do something. (yes folder browsing being an acception :p).
A simple way to do the hierarchy is like the one I did for the Music
section in Moovida... I typed it out like this:
MUSIC
......Library
......Search
............Keyboard + Results
.......................Media Results
......Artists
...........List of
....................Albums
......Albums
......Tracks
......Genres
...........List of
.....................Albums
......Music Videos
......Playlists
............List of
.....................Tracks
So I loosely in a crude visual way describe the hierarchal structure
there and it gives you a sense of what you will see onscreen. Note,
something like 'Library' goes straight to the media so I dont define
it.
4. Development Overview
This is about detailing what should be done and what you think is
needed for 'the backend'. Known problems in relation to your goals
as well as possible ways to tackle them as well as put the code
together.
5. A look at other similar projects and resources
Always good to point to all the relevent sources and information you
can find in this area.
Link to Opensource projects or code you are going to use.
Link to other similar projects (e.g. Media Portal have TV + EPG as
well...might be useful to see from a UX perspective)
Link to other UI's that you find interesting or useful (video is
also good as well... for example, a nice video of the MythTV EPG).
So, for all the Myth TV guys, if you want to get together and do
this, if you can organise a specification with the detail needed.
The next step is discussing the UX experience and at that point I
can help out and we can take it from there. Then come some 'mockups'
and development work.
There you go :)
David
David McLeod
Senior Designer & UI Lead
Fluendo S.A.
World Trade Center Edificio Norte Pl.2
08039 BARCELONA SPAIN
Tel: +34 936 002 323
Skype: Daiode
Jabber/GMail: [email protected]
Email: [email protected]
On 30 Jun 2009, at 01:37, Kevin Fox wrote:
I worked on it a bit a while ago using libgmyth and the myth
gstreamer
plugin. It was close to working, but I couldn't easily get the
metadata
into Elisa at the time, and between lack of time and Elisa getting
several major over halls, the project never went anywhere. It still
would be a good thing todo IMHO.
On Mon, 2009-06-29 at 15:21 -0700, Keith Cirkel wrote:
I'm getting rather tired of the outdated feel of mythfrontend.
When I
downloaded moovida it was exactly what I wanted in a media centre
frontend, it just lacked the tv bit!
I'd like to propose development of a plugin for moovida to provide
support for the mythtv-backend service. I am pretty familiar with
mythbackend, but I am quite new to python (dabbled a bit in it,
mostly
with Django). I am pretty happy to just get stuck in though, and try
and get a (somewhat) working plugin asap, problem being I am out
of my
depth when it comes to the code.
Here is as much as I know about this, in my attempt to get this
project kickstarted as fast as possible:
For the uninitiated, the mythtv-backend is a service that has the
hardware implimentations for tuners, as well as a database backend
to
store tv listings. The backend actually does all the heavy lifting -
so recording shows, managing schedules, managing tuners,
expiration of
recordings, infact pretty much everything you can think of. All the
frontend does is spit out the video output, and schedule hud.
The service runs on a custom protocol, running on port 6543, so
one is
able to setup a mythtv backend service running on one machine, and a
mythtv frontend service running on a separate machine. The backend
also handles backends, so you could have an arbitrary amount of
backends in a internetworked configuration of backends which can be
accessed from multiple frontends. In summary, its a many to many
kind
of thing.
The protocol basically picks up on a connection from the port,
requiring a MYTH_PROTO_VERSION response, which tells the backend
which
version of the protocol you're using. When this handshake is done
you
can run a huge list of commands. The caveat is that the protocol
version you're running must match the backends protocol version.
For a more in depth analysis of the protocol, you can see here:
http://www.mythtv.org/wiki/Using_the_Myth_protocol
For a list of commands with details on each one, head over here:
http://www.mythtv.org/wiki/Myth_Protocol_Command_List
There is an implimentation which seems to take out alot of the hard
work from using the mythtv protocol here:
http://gmyth.sourceforge.net/wiki/index.php/Main_Page. This was
linked
from the originating forum post.
To flag up some future problems, you can read here:
http://www.mythtv.org/wiki/
Using_the_Myth_protocol#Getting_Guide_Data
which details one quirk with getting TV Guide data, where the
frontend
will simply query the *sql database direct; rather than the backend.
This unfortunately would add a whole layer of crap into the
plugin, as
while you can pull the authentication details from the backend, it
means extra db code needs to be added for such neccessary functions.
...so... anyone interested in getting this going?
----
Keith Cirkel
David McLeod
Senior Designer & UI Lead
Fluendo S.A.
World Trade Center Edificio Norte Pl.2
08039 BARCELONA SPAIN
Tel: +34 936 002 323
Skype: Daiode
Jabber/GMail: [email protected]
Email: [email protected]
