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

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 

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.