Difference between revisions of "Feature Wishlist"

From MythTV Official Wiki
Jump to: navigation, search
m (edit category)
m (Protected "Feature Wishlist": Historical archive: Replaced by Feature Suggestion Forum ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
 
(19 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{Note box|Before making any feature requests to the MythTV developers, one first needs to understand the most basic truth about MythTV: ''"MythTV is a project by developers, for developers."'' If you look at things in that light, comments that get made by developers to users who submit feature requests ("Sounds good; I look forward to your patch") make a whole lot more sense.}}
+
{{Note box|Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.}}
  
 
The developers of MythTV work for free (obviously), in their spare time. Most/all of them write software for a living, where they work all day long on things that other people want them to work on. When they work on Myth they focus on what's important to them. A feature gets implemented because a developer wants it bad enough to spend his spare time writing it and testing it, and believes in it strongly enough to defend it from the other developers (which helps to avoid the feature creep common in some projects). Bugs, especially crash bugs, get worked on by all of the devs as they encounter them as those impact everyone.
 
The developers of MythTV work for free (obviously), in their spare time. Most/all of them write software for a living, where they work all day long on things that other people want them to work on. When they work on Myth they focus on what's important to them. A feature gets implemented because a developer wants it bad enough to spend his spare time writing it and testing it, and believes in it strongly enough to defend it from the other developers (which helps to avoid the feature creep common in some projects). Bugs, especially crash bugs, get worked on by all of the devs as they encounter them as those impact everyone.
  
 
That's not to say that the users don't matter, or that the developers never implement something that comes from a user. It's just that unless a developer says either "why didn't I think of that" or "I could knock that out in a couple hours" it will be a much lower priority.
 
That's not to say that the users don't matter, or that the developers never implement something that comes from a user. It's just that unless a developer says either "why didn't I think of that" or "I could knock that out in a couple hours" it will be a much lower priority.
 +
 +
= MythTV Feature Suggestion Forum =
 +
 +
The new [https://forum.mythtv.org/viewforum.php?f=9 Feature Suggestion Forum] replaces this wiki page. Please use it instead.
 +
 +
= Archived Feature Request List =
  
 
{{HelpUs}}
 
{{HelpUs}}
Line 9: Line 15:
 
Requests from people who have contributed back to the project in some way carry a LOT more weight. Developers by and large tend to be rather blunt. People often mistake being terse and to the point for being insulting. Then they start a [http://www.gossamer-threads.com/lists/mythtv/users/59418 flame war on the mailing list] (which is pretty much certain death for a feature request) all because a developer either '''a)''' didn't take 3 paragraphs to tell them "I'm not going to work on this" or '''b)''' they think that the developer should drop whatever they're doing because *they* want it done. A lot of the devs are a bit defensive when it comes to requests, largely due to previous bad experiences.
 
Requests from people who have contributed back to the project in some way carry a LOT more weight. Developers by and large tend to be rather blunt. People often mistake being terse and to the point for being insulting. Then they start a [http://www.gossamer-threads.com/lists/mythtv/users/59418 flame war on the mailing list] (which is pretty much certain death for a feature request) all because a developer either '''a)''' didn't take 3 paragraphs to tell them "I'm not going to work on this" or '''b)''' they think that the developer should drop whatever they're doing because *they* want it done. A lot of the devs are a bit defensive when it comes to requests, largely due to previous bad experiences.
  
And, finally, remember this: if there's something you want badly enough, [http://www.gossamer-threads.com/lists/mythtv/dev/166419 you can always offer to pay someone to do it].
+
And, finally, remember this: if there's something you want badly enough, [http://groups.google.com/group/mythtv-contractors you can always offer to pay someone to do it].
  
 
:Editor's note: Even moreso than on most pages, if you add a note here that a wishlist item is now available or in process, ''please note which version that information applies to'' ('added in 0.19', for example).  Remember: wiki pages live forever. --[[User:Baylink|Baylink]] 17:00, 12 February 2006 (UTC)
 
:Editor's note: Even moreso than on most pages, if you add a note here that a wishlist item is now available or in process, ''please note which version that information applies to'' ('added in 0.19', for example).  Remember: wiki pages live forever. --[[User:Baylink|Baylink]] 17:00, 12 February 2006 (UTC)
Line 25: Line 31:
 
* Requests from people who have contributed back to the project in some way carry a LOT more weight.
 
* Requests from people who have contributed back to the project in some way carry a LOT more weight.
 
When you're ready to submit your suggestion, add it to the end of the relevant page and section listed in "The Wishlists" section below.
 
When you're ready to submit your suggestion, add it to the end of the relevant page and section listed in "The Wishlists" section below.
 
== In Development ==
 
 
There are many items which are in active development (people are writing code).  Some of them are listed below, and others [http://svn.mythtv.org/trac/wiki/FutureDevelopment at the developers' Trac wiki page].
 
  
 
__NOTOC__
 
__NOTOC__
  
 
== The Wishlists ==
 
== The Wishlists ==
* It's not a feature. But it can make things easier for people who use mythtv mainly for mythvideo, mythgame & mythmusic. If it is possible to move TV features in a optionnal plugin, this can help to make things more clear and easier.
+
* [[Feature Wishlist (Setup)|Setup and Configuration]] -- Anything for the setup process including hardware support. These are '''things you want mythtv to do prior to actually running mythtv'''.
 
 
=== Setup and Configuration ===
 
 
 
:''See [[Feature Wishlist (Setup)]]''.
 
 
 
Anything for the setup process including hardware support.
 
 
 
=== Backend Addons ===
 
 
 
:''See [[Feature Wishlist (Backend Addons)]]''.
 
 
 
Backend additions are '''things you want mythtv to do when you're not around'''
 
 
 
* One feature that is sorely missing in mythtv is the option to repair mpeg2 transport streams to make them standards compliant (like fixing the timecode) after they've been captured. This is not transcoding but just fixing the errors that occurred during transmission. This is especially a problem for embedded consumer electronic devices that play TS files because they have little or no tolerance for errors in the TS file. There seem to be several utilities that do this for Windows (like mpeg2repair) but I have not found any on Linux that perform this task.
 
 
 
* New commandline cleanupRecordings to remove everything with an autoexpire value equal or greater than commandline value X.  E.G. cleanupRecordings 1000 will remove all live tv files and database entries.
 
 
 
* Add an option to allow mythtv to shut down even if a client is connected, including "client idleness" in the decision to shutdown.  I know that mythwelcome is supposed to handle this but it requires users (i.e. kids) to actually exit the frontend when done watching, something which never happens in my universe.  I think this change would allow simple combined frontend/backend boxes to be more energy efficient by shutting down when not in use without any user interaction.
 
 
 
* Add the following features to [[mythtranscode]]:
 
** Support for libx264 video-codec (for example with [[ffmpeg]] -vcodec libx264)
 
** Support for choosing one or more audio-stream(s) to retain (for example with [[ffmpeg]] copy-mode and -map)
 
** Support for AVI, MP4 and MKV container-formats
 
  
=== Frontend Addons ===
+
* [[Feature Wishlist (Backend Addons)|Backend Addons]] -- Backend additions are '''things you want mythtv to do when you're not around'''.
  
:''See [[Feature Wishlist (Frontend Addons)]]''
+
* [[Feature Wishlist (Frontend Addons)|Frontend Addons]] -- Frontend additions are '''things you want to do in mythtv while using recordings'''.
  
Frontend additions are '''things you want to do while using mythtv'''
+
* [[Feature Wishlist (Plugin Addons)|Plugin Addons]] -- Plugin additions are '''things you want to do in mythtv while not using recordings'''.
  
* [[MythTouchMote]] A new frontend where the user interface split from the playback device onto a remote tablet (UMPCs, netbooks, iPhone, Nokia-n800i, Android phones) a user interface specification for this has been created and a bounty is negotiable. 
+
* [[Feature Wishlist (New Plugins)|New Plugins]] -- New plugins are '''new things you want to do in mythtv while not using recordings'''.
 
 
* Would like to propose adding Live TV functionality to the UPnP server. To my knowledge only Nero {7,8} Home Media Server has this capability, but it is proprietary and runs only on proprietary OS. This could be done by adding (aside from Recodings, Music and Videos) a fourth folder (i.e. LiveTV) with all channels being listed as media files. Watching a channel should generate live recording as it does when viewed on a frontend. Potential caveat would be tuner availability, however with USB tuners (DVB-*+EIT and analog+listings), it would be possible to add N+1 (where N is a number of frontends) amount of tuner devices to the system without a problem ensuring scheduled recordings and LiveTV functionality is available at all time.
 
Appropriate calls that would feed back to the backend seem to exist: PrepareForConnection() and ConnectionComplete() in ConnectionManager (requesting a channel switch and releasing it) and InstanceID allows to distinguish between different UPnP frontends.
 
 
 
* It would be nice to have a "Grouped Display" in the "Watch Recordings" section. That means currently you have to select the displayed group through a seperate menu, but it would be nice if you could navigate through the groups like in the MythVideo section. e.g.
 
All Recordings -
 
Series - Stargate SG1 - Series 1
 
                        Series 2...
 
          Columbo - Series 1 ...
 
Movies - Movie 1 - ...
 
 
 
=== Plugins ===
 
 
 
:''See [[Feature Wishlist (Plugin Addons)]] for existing plugins''
 
:''See [[Feature Wishlist (New Plugins)]] for new plugin ideas''
 
 
 
Plugins are '''applications that not related to recording programs, but can be integrated into MythTV,''' ''e.g.'' viewing weather reports, watching DVDs, and playing games.
 
  
 
=== Platforms ===
 
=== Platforms ===
  
* MythTV Frontend and backend runnning on a Casio fx7000G (1985) pocket calculator
 
* MythTV Frontend running on the [[:Category:PS3|Playstation 3]].
 
 
* MythTV Frontend running as a [http://en.wikipedia.org/wiki/Wii_Channels Wii Channel] (There is a [http://www.fossfactory.org/project.php?p=p102 small bounty] for this on FOSS Factory.  You can contribute to the bounty if you want.)
 
* MythTV Frontend running as a [http://en.wikipedia.org/wiki/Wii_Channels Wii Channel] (There is a [http://www.fossfactory.org/project.php?p=p102 small bounty] for this on FOSS Factory.  You can contribute to the bounty if you want.)
 +
* MythTV Frontend (TV client only) running natively on GlobalScale Linux D2 Plug ARM Marvell PXA510 – 800MHz see http://www.globalscaletechnologies.com/c-8-d2plug.aspx - ** UPDATE June '12 ** New D2 Plug availability occurred in October 2011.  We have received product and are now implementing the platform.  Some delays due to other work.  We are having good and bad results. We can compile code on the D2 plug, we are having problems with decoder (OpenMAX is not supported on ARM cpu) we are looking at the options. We still think that it is doable. Send suggestions to mythtv@quickcycle.com 
 
* MythTV Frontend running on AppleTV (doable: see [[Installing MythTV on an AppleTV]] and a thread on the [http://www.gossamer-threads.com/lists/mythtv/dev/288558 developer] mailing list)
 
* MythTV Frontend running on AppleTV (doable: see [[Installing MythTV on an AppleTV]] and a thread on the [http://www.gossamer-threads.com/lists/mythtv/dev/288558 developer] mailing list)
 
* MythTV Frontend (TV plug-in only) running natively on AppleTV i.e. using Apple's FrontRow for menus.  See [http://wiki.awkwardtv.org/wiki/BackRow_Developers%27_Kit AwkwardTV Wiki] and [http://alanquatermain.net/brdevkit/ BackRow Developers' Kit].  This would create a single, modeless AppleTV front end / user interface.
 
* MythTV Frontend (TV plug-in only) running natively on AppleTV i.e. using Apple's FrontRow for menus.  See [http://wiki.awkwardtv.org/wiki/BackRow_Developers%27_Kit AwkwardTV Wiki] and [http://alanquatermain.net/brdevkit/ BackRow Developers' Kit].  This would create a single, modeless AppleTV front end / user interface.
* MythTV as a replacement for DVR/PVR interfaces, such as the Philips DVDR3455H/37.  The Rockbox.org is a UI replacement project for music players, and MythTV could do the same for DVRs.
 
 
* MythTV Frontend on Windows Mobile. Since a frontend is working on Windows, a Windows Mobile version could be promising, One challenge might be a touch interface.
 
* MythTV Frontend on Windows Mobile. Since a frontend is working on Windows, a Windows Mobile version could be promising, One challenge might be a touch interface.
 +
* MythTV Backend ported to ARM SoC i.e. NVIDIA's [http://blogs.nvidia.com/2011/02/tegra-roadmap-revealed-next-chip-worlds-first-quadcore-mobile-processor/ Ka-el and/or Denver projects].  While it is unknown if graphics accelerated drivers (VDPAU) will be made available to run a frontend the raw horsepower should be sufficient for a backend with storage, comm flag, and USB based tuners.  Imagine your 35W TDP Core2 Duo (T7200) CPU replaced by a 1W TDP CPU/GPU that has vastly less performance...
  
 
Platforms are the '''hardware and operating system''' setups that actually run the Myth applications.  This section should track the request to support platforms other than the default x86 PC environment.  This would include console ports like X-Box and PS3.
 
Platforms are the '''hardware and operating system''' setups that actually run the Myth applications.  This section should track the request to support platforms other than the default x86 PC environment.  This would include console ports like X-Box and PS3.
  
=== Ideas with response ===
+
=== Will Not Implement ===
 +
These are suggestions which for one reason or another will not be implemented in MythTV.
 
* [http://gossamer-threads.com/lists/mythtv/dev/2899 Non-time shifting mode for watching regular TV], would be a bit difficult since the frontend/backend split, but might be possible when both are on the same machine. You could still draw the OSD if you would want.
 
* [http://gossamer-threads.com/lists/mythtv/dev/2899 Non-time shifting mode for watching regular TV], would be a bit difficult since the frontend/backend split, but might be possible when both are on the same machine. You could still draw the OSD if you would want.
:''this defeats the purpose of a PVR, add a menu item to launch a non-buffering tv program in place of Myths "watch tv" item'' - This is better stated as a request for "fast channel changing" or "no 2 second delay". Current workaround is to switch channel changing behavior to "browse mode", but actually having "fast channel changing" would really help new user acceptance of mythtv.
+
:: MythTV is designed as a PVR, which by definition necessitates that all TV be recorded and buffered. As mentioned, the frontend/backend split was designed with this requirement in mind, and MythTV would require a significant rework of the livetv code in order to reduce this buffer.
::Alas, "fast channel changing" in the sense these people mean it is next to impossible to accomplish in an MPEG decode-reencode environment, and note that digital cable STB's don't do it, either...
+
:: '''fast channel changing''' is also an unachievable goal due to hardware constraints. Tuners and cable boxes take time to lock, mpeg encoders need to fill video buffers, digital tuners need to wait for stream information and then the first I-frame. All of this adds up to MythTV's internal lag becoming a less significant portion of the problem.
:::What about channels on the same multiplex or user with an idle tuner card? Would be nice if user is in browse mode and channels are already locked when he hits OK.
 
* [http://gossamer-threads.com/lists/mythtv/users/30199 Peer-to-peer sharing of shows with friends who also use MythTV] {[http://gossamer-threads.com/lists/mythtv/dev/7175 2], [http://www.gossamer-threads.com/lists/mythtv/dev/263548 3]}
 
:(uhm... can you spell l-a-w-s-u-i-t?) ''NEVER going to happen with core Myth''
 
::Why not just implement some way of sharing what channel/recording you're watching? Could be something like altering your jabber status message to 'Watching XXX on MythTV' where XXX could be a channel unique identifier (UK:Channel 4, US:CNN etc) or the name of the show (if its a recording). MythTV could grab your friends list, show only those of the same format (ie. MythTV updates) so you can see what your mates are watching. You could even chat with people on the same channel as you!
 
* [http://gossamer-threads.com/lists/mythtv/dev/3547 Auto update, or update notification] {[http://gossamer-threads.com/lists/mythtv/dev/5683 2]} (update notification should be feasable, IMHO - HenkPoley)
 
:''Very distro dependant, apt-get solves 99% of the problem for most folks (those who are *using* packages, maybe... --Baylink)''
 
:PackageKit?  It was created to solve exactly this kind of problem! --andy_js
 
* [http://gossamer-threads.com/lists/mythtv/dev/6465 Action sound], a short confirmation 'blip' to say that a keypress was received and is 'being processed'
 
:This is difficult to achieve without implementing and requring all audio devices to be routed through an ALSA mixer (which has its own issues at the moment)  --- As a work around, look on the backend setup screen. There is a config option for "Execute command when key pressed" (or something like thing) that you can configure to play a sound
 
* Ability to rename existing recordings. As an example, one might record PBS's "Nova"  each week and wind up with a dozen recordings entitled "NOVA", but otherwise distinguished only by date. The nice-to-have would be the the ability for the user to name them things like "Mt McKinlley (nova)", "Sea Mammal Rescue (nova)".... and whatever else.
 
:: This sounds more like a deficiency in listings data rather than anything MythTV has control over.
 
  
* Ability to set Reminders/ autoview from TV guide. It would be nice if you could setup up reminders in the TV guide for upcoming programmes. I imagine the reminder dialogue could be added to the schedule recordings screen.  It would also be nice if this reminder had the options to "autoview" automatically tuning the tv card to the channel at the start time (similar to sky +).
+
* Peer-to-peer sharing of shows with friends who also use MythTV
:: This defeats the purpose of a DVR. You're setting alerts that 'you need to watch this now', rather than recording it so you can watch it later at your leisure.
+
:: MythTV is designed for use with commercial TV. Fair use precedence allows you to record this for your own personal use, but does not authorized you to share or redistribute in any fashion. MythTV will never implement a feature whose sole purpose is to facilitate this, or any feature which would primarily be used for this.
  
* Jump point to quit the application.  This will allow a single remote command to quit from anywhere, particularly useful for a frontend/backend machine running mythwelcome which is set to turn itself off when idle.
+
* [http://gossamer-threads.com/lists/mythtv/dev/3547 Auto update, or update notification] {[http://gossamer-threads.com/lists/mythtv/dev/5683 2]}
** You can run `irexec` with the command `killall mythfrontend`(or `killall mythfrontend.real` on ubuntu)
+
:: For those using package managers, your distro should provide this service automatically.
** You can run `irxevent` to send the keystroke 'Alt-F4'.
+
 
 +
* Migrate to use VLC, or gstreamer, or some other codec library.
 +
:: MythTV was written from the start to be based off of ffmpeg. Any move away from that would require vast changes throughout MythTV, and is not likely to ever happen.
 +
 
 +
* I demand MythWeb be rewritten in PythonBecause that's just the way open source works.
 +
:: This was actually emailed to a developer.  It's a prime example of when to go back and try it again. Demanding things will never endear you and your cause to someone whom you expect to do your work for free.
 +
 
 +
* MythTV Frontend and backend runnning on a Casio fx7000G (1985) pocket calculator
 +
:: This platform is too limited to support a frontend or backend.
 +
 
 +
* MythTV Frontend running on the [[:Category:PS3|Playstation 3]].
 +
:: While running a backend on Playstation 3 is doable, the hardware is too limited to run the standard frontend satisfactorily. It is possible to use MythTV's UPnP support to play back most MPEG-2 recordings on the PS3.
 +
 
 +
* MythTV as a replacement for DVR/PVR interfaces, such as the Philips DVDR3455H/37The Rockbox.org is a UI replacement project for music players, and MythTV could do the same for DVRs.
 +
:: The hardware on commercial DVR's is too limited to run MythTV. While these are getting more powerful every few years there is a second problem in that many of these devices use hardware without Linux drivers or run only signed binaries.
  
* ADD easy function to delete a program from the command line.
+
* Have MythTV setup and define network interface
** Could be easily done in a couple lines of perl/python using the respective bindings.
+
:: The network interface is outside of MythTV's purview. Most Linux distro's and other platforms MythTV runs on provide decent tools for doing simple network configs automatically or through a GUI and provide command line tools for more complex setups (ifconfig/ipconfig).
  
 +
* mythbackend (Ubuntu x86_64 v0.20.20070821-1) appears to catch signals (all, most?) and will exit with return code 0 even when core dumping.  I suggest to reserve exit code 0 for a deliberate, graceful shutdown, and instead using a non-zero exit code for other, non-graceful shutdowns and crashes.  This allows the user, or any process monitoring mythbackend (in my case I'm [[Using_pcsk_to_Supervise_mythbackend]]) to distinguish between the two situations.
 +
:: Please make sure you are checking the 8th bit of the exit code, Linux normally sets that to one and puts the signal in the low order bits. MythTV does not catch the segfault signal so the operating system is setting the return value.
  
=== Already implemented ===
+
* Optionally disable the sync loop on the backend; comments say it's for NFS.. on a combined front end + back end this short-periodic sync can wreak havoc with file allocation, and cause excess fragmentation.
 +
:: The comments are out of date, this is required on Linux with the CFQ and AS elevator algorithms. Since CFQ is the default on most Linux distro's the sync will stay for the time being. The need to disable it is too low to justify another setting. Commenting it out is fairly simple to do if your one of the few mythtv users changing elevator algorithms for greater backend performance. NFS does not require the sync on any modern Linux kernel.
  
* UserRemoveJobs.  See [http://www.mythtv.org/wiki/index.php/User_Jobs UserJobs].  These commands should be run when removing an episode.
+
* Support for USB-UIRT - IR blaster
:: see [http://svn.mythtv.org/trac/changeset/23012 r23012]
+
:: This is a job for LIRC.
  
* It would be cool to have an event oriented socket available on backend. When an event happens, like start recording, etc... it would be written to socket, so any app could read from it and show on any way (an applet on gnome/kde/windows/mac os x, an email, a sms, etc...).
 
:: see [http://svn.mythtv.org/trac/changeset/23012 r23012]
 
  
 
[[Category:Wishlist]]
 
[[Category:Wishlist]]

Latest revision as of 11:35, 29 October 2014

Important.png Note: Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.

The developers of MythTV work for free (obviously), in their spare time. Most/all of them write software for a living, where they work all day long on things that other people want them to work on. When they work on Myth they focus on what's important to them. A feature gets implemented because a developer wants it bad enough to spend his spare time writing it and testing it, and believes in it strongly enough to defend it from the other developers (which helps to avoid the feature creep common in some projects). Bugs, especially crash bugs, get worked on by all of the devs as they encounter them as those impact everyone.

That's not to say that the users don't matter, or that the developers never implement something that comes from a user. It's just that unless a developer says either "why didn't I think of that" or "I could knock that out in a couple hours" it will be a much lower priority.

MythTV Feature Suggestion Forum

The new Feature Suggestion Forum replaces this wiki page. Please use it instead.

Archived Feature Request List

MythTV logo square.png Join us making your favorite media center even better than it already is today.

Requests from people who have contributed back to the project in some way carry a LOT more weight. Developers by and large tend to be rather blunt. People often mistake being terse and to the point for being insulting. Then they start a flame war on the mailing list (which is pretty much certain death for a feature request) all because a developer either a) didn't take 3 paragraphs to tell them "I'm not going to work on this" or b) they think that the developer should drop whatever they're doing because *they* want it done. A lot of the devs are a bit defensive when it comes to requests, largely due to previous bad experiences.

And, finally, remember this: if there's something you want badly enough, you can always offer to pay someone to do it.

Editor's note: Even moreso than on most pages, if you add a note here that a wishlist item is now available or in process, please note which version that information applies to ('added in 0.19', for example). Remember: wiki pages live forever. --Baylink 17:00, 12 February 2006 (UTC)

How to make a suggestion

If you've got an idea for a feature that you'd like to see implemented here's some guidelines for submitting it:

  • Before anything else, check the Current Version release notes to make sure it's not already in there (yes, this happens).
  • Clearly indicate that it's a request, not a demand.
  • Understand that code speaks louder than words. If you can, write a patch and submit it to TRAC
  • Be very clear with how you envision your idea working. The more details you have in your request the better chance you have hitting that magical "knock it out in a couple of hours" mark.
  • Make sure you're not repeating a previous request. (Search the wiki and mailing list archives)
  • Do NOT be offended if a developer responds with "sounds good; I look forward to your patch".
  • Requests from people who have contributed back to the project in some way carry a LOT more weight.

When you're ready to submit your suggestion, add it to the end of the relevant page and section listed in "The Wishlists" section below.


The Wishlists

  • Setup and Configuration -- Anything for the setup process including hardware support. These are things you want mythtv to do prior to actually running mythtv.
  • Backend Addons -- Backend additions are things you want mythtv to do when you're not around.
  • Frontend Addons -- Frontend additions are things you want to do in mythtv while using recordings.
  • Plugin Addons -- Plugin additions are things you want to do in mythtv while not using recordings.
  • New Plugins -- New plugins are new things you want to do in mythtv while not using recordings.

Platforms

  • MythTV Frontend running as a Wii Channel (There is a small bounty for this on FOSS Factory. You can contribute to the bounty if you want.)
  • MythTV Frontend (TV client only) running natively on GlobalScale Linux D2 Plug ARM Marvell PXA510 – 800MHz see http://www.globalscaletechnologies.com/c-8-d2plug.aspx - ** UPDATE June '12 ** New D2 Plug availability occurred in October 2011. We have received product and are now implementing the platform. Some delays due to other work. We are having good and bad results. We can compile code on the D2 plug, we are having problems with decoder (OpenMAX is not supported on ARM cpu) we are looking at the options. We still think that it is doable. Send suggestions to mythtv@quickcycle.com
  • MythTV Frontend running on AppleTV (doable: see Installing MythTV on an AppleTV and a thread on the developer mailing list)
  • MythTV Frontend (TV plug-in only) running natively on AppleTV i.e. using Apple's FrontRow for menus. See AwkwardTV Wiki and BackRow Developers' Kit. This would create a single, modeless AppleTV front end / user interface.
  • MythTV Frontend on Windows Mobile. Since a frontend is working on Windows, a Windows Mobile version could be promising, One challenge might be a touch interface.
  • MythTV Backend ported to ARM SoC i.e. NVIDIA's Ka-el and/or Denver projects. While it is unknown if graphics accelerated drivers (VDPAU) will be made available to run a frontend the raw horsepower should be sufficient for a backend with storage, comm flag, and USB based tuners. Imagine your 35W TDP Core2 Duo (T7200) CPU replaced by a 1W TDP CPU/GPU that has vastly less performance...

Platforms are the hardware and operating system setups that actually run the Myth applications. This section should track the request to support platforms other than the default x86 PC environment. This would include console ports like X-Box and PS3.

Will Not Implement

These are suggestions which for one reason or another will not be implemented in MythTV.

MythTV is designed as a PVR, which by definition necessitates that all TV be recorded and buffered. As mentioned, the frontend/backend split was designed with this requirement in mind, and MythTV would require a significant rework of the livetv code in order to reduce this buffer.
fast channel changing is also an unachievable goal due to hardware constraints. Tuners and cable boxes take time to lock, mpeg encoders need to fill video buffers, digital tuners need to wait for stream information and then the first I-frame. All of this adds up to MythTV's internal lag becoming a less significant portion of the problem.
  • Peer-to-peer sharing of shows with friends who also use MythTV
MythTV is designed for use with commercial TV. Fair use precedence allows you to record this for your own personal use, but does not authorized you to share or redistribute in any fashion. MythTV will never implement a feature whose sole purpose is to facilitate this, or any feature which would primarily be used for this.
For those using package managers, your distro should provide this service automatically.
  • Migrate to use VLC, or gstreamer, or some other codec library.
MythTV was written from the start to be based off of ffmpeg. Any move away from that would require vast changes throughout MythTV, and is not likely to ever happen.
  • I demand MythWeb be rewritten in Python. Because that's just the way open source works.
This was actually emailed to a developer. It's a prime example of when to go back and try it again. Demanding things will never endear you and your cause to someone whom you expect to do your work for free.
  • MythTV Frontend and backend runnning on a Casio fx7000G (1985) pocket calculator
This platform is too limited to support a frontend or backend.
While running a backend on Playstation 3 is doable, the hardware is too limited to run the standard frontend satisfactorily. It is possible to use MythTV's UPnP support to play back most MPEG-2 recordings on the PS3.
  • MythTV as a replacement for DVR/PVR interfaces, such as the Philips DVDR3455H/37. The Rockbox.org is a UI replacement project for music players, and MythTV could do the same for DVRs.
The hardware on commercial DVR's is too limited to run MythTV. While these are getting more powerful every few years there is a second problem in that many of these devices use hardware without Linux drivers or run only signed binaries.
  • Have MythTV setup and define network interface
The network interface is outside of MythTV's purview. Most Linux distro's and other platforms MythTV runs on provide decent tools for doing simple network configs automatically or through a GUI and provide command line tools for more complex setups (ifconfig/ipconfig).
  • mythbackend (Ubuntu x86_64 v0.20.20070821-1) appears to catch signals (all, most?) and will exit with return code 0 even when core dumping. I suggest to reserve exit code 0 for a deliberate, graceful shutdown, and instead using a non-zero exit code for other, non-graceful shutdowns and crashes. This allows the user, or any process monitoring mythbackend (in my case I'm Using_pcsk_to_Supervise_mythbackend) to distinguish between the two situations.
Please make sure you are checking the 8th bit of the exit code, Linux normally sets that to one and puts the signal in the low order bits. MythTV does not catch the segfault signal so the operating system is setting the return value.
  • Optionally disable the sync loop on the backend; comments say it's for NFS.. on a combined front end + back end this short-periodic sync can wreak havoc with file allocation, and cause excess fragmentation.
The comments are out of date, this is required on Linux with the CFQ and AS elevator algorithms. Since CFQ is the default on most Linux distro's the sync will stay for the time being. The need to disable it is too low to justify another setting. Commenting it out is fairly simple to do if your one of the few mythtv users changing elevator algorithms for greater backend performance. NFS does not require the sync on any modern Linux kernel.
  • Support for USB-UIRT - IR blaster
This is a job for LIRC.