[mythtv] Some Ideas for MythTV (Repost from the AVS Forums)
Cameron
mythtv-dev@snowman.net
Tue, 03 Dec 2002 23:18:06 +0900
*** The following is not my thoughts, but the post of someone who goes
by the handle of Ago. It was originally posted at
http://www.avsforum.com/avs-vb/showthread.php?threadid=186892, and was
directed towards Issac, but I thought the entire MythTV community could
benefit from the discussion. ***
<snip>
Well 2 interested users in a month does not look like enough to get
started... Nevertheless some positive notes. I went (quickly) through
the code of Mythtv and I think it would make a VERY good starting point.
Indeed to a certain extent most of the things I said have already been
implemented, I mostly have issues with the amount of stuff which is
hardcoded, integration between GUI and rest of interface and separation
between different media types.
I would really like to hear from ijr, the author of MythTv. Probably it
might be a good idea just to help out on MythTv, but my wishlist is LONG
and I am afraid I might piss off a few people there, starting with ijr
(I do not like it too much myself when someone comes to me with a long
wishlist...).
Nevertheless here is a partial wishlist with respect to MythTv:
1) Obviously separate a bit more the GUI from the rest of the interface,
so that the low level interface (ML) passes only list of items (as xml)
to the GUI. It would be easier to implement different types of GUIs for
different display devices. To me the main effort consists in integrating
applications/players/grabbers/media-db/epg/scheduler. And MythTv already
does most of it. But the GUI is a separate issue and should be kept as
such. The less is hardcoded the better.
2) A single DB for ALL media files (even games) that contains both
meta-info and playlists (AUDIO+VIDEO). Not sure if different tables
should be maintained for each media type or if it is best to use a
single table with standardised fields valid for all media types +
media-specific ones in general text fields (or only one addition text
field containing all the media-specific xml tags), maybe an additional
"keywords" field...
3) Media files should be accessed only indirectly through the db not as
real files. If you want to delete a file, you must find the path through
the db at this point the application will delete the file itself, its
meta-info on the db, and amend any playlist that contained the file...
Similarly when you want to add a new media-file. Once the files are
grabbed (from cd/dvd/hd/network/live recording/web...) their meta info
in parsed authomatically (or manually) from the files themselves, from
the web or the epg and inserted into the db. For what matters ALL media
files should be saved in a single folder with the name represented by a
simple ID, almost impossible to access directly...
4) A single smart "Grab" button would be nice with subitems: "record
currently playing item", "get from CD/DVD", "get from HD/network", "get
from aux", "scheduled recording of live event"... According to the
actual media types it will choose the appropriate codecs and recording
settings. As mentioned this will also populate the multimedia db,
grabbing the meta-info using appropriate info-grabbers according to the
mime type being grabbed...
5) Possibility of customizing menus by inserting SQL queries directly in
the xml menu files. This would allow us to create virtual folders (by
author, album, etc and different hyerarchical structures for browsing
the files), irrespective of the media type used. It should be possible
to play also files that have not been grabbed and inserted in the db
(from cd/hd/network...), again by using a special synthax in the xml
menu files (eg all files in foledr XXX beginnig with "a*"). A list of
mediafiles after all should not be dependent on the file types. I might
want a favourites list that includes songs, games and movies all in the
same list, or, more likely, I do not see the need to put in separate
lists movies recorded from live tv and the ones from my dvd
collection... At the same time I might want live tv documentaries to be
in a different list from the movies. Media file lists are generated
simply by querying the db, browsing through folders or from epg, but at
the end they are just list of items with some properties (xml tags),
some of wich are common to all media files some of which are not....
6) xml files that specify how a particular file is played or recorded
and according to what settings. Such settings might be overridden in the
various menu.xml files. An abstraction layer is needed here.
7) It might be nice to separate the audio and video channels so I can
listen to an audio playlist while watching formula1. When I choose to
watch tv I might want this action to affect only the video channel
leaving the audio channel to play whatever it was playing. Playlists
should also be AUDIO+VIDEO, not just a list of songs. I might want to
create a playlist which shows different pictures of my wife (sql on
pictures with keyword="wife") coupled with some romantic songs (in order
to improve the waf...). Very nice also for a party. Playlists should
support an sql query not just a list of media files.
</snip>