Feature Wishlist

Note: 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.

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.

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.

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)

And finally, if you're not after a feature, per se, but there's some why you feel Myth is less than perfect, talk about that over on Why MythTV Sucks.

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.

The Wishlists

Setup and Configuration

Backend Addons

Backend additions are things you want mythtv to do when you're not around

I suggest The Original Air Date gets added to the mysql data table for a given recorded program so it opens up possibility to sort by original air date and have a new duplicate check method for scheduling programs. From what I see now MythTV does not have this. This will probably involve reading data from the Schedules Direct data and adding it to the database with new options on the frontend and the web interface to reflect the change.

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.

Consider running Project-X as a background job to clean up DVB recordings and remove all but the (user-defined) streams to reduce disc space (reducing a UK standard DVB broadcast stream to just video+1 audio+subtitles streams gives a size reduction of about 33%). MythArchive could also take note of when this is done and skip this stage of the DVD mastering process too. -- Can be implemented as a user job, won't be implemented officially (that's what mythtranscode is for). You can also opt not to record data streams to start with.--GBee 18:49, 22 March 2008 (UTC)

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.

UserRemoveJobs. See UserJobs. These commands should be run when removing an episode.

It would be cool to have an event oriented socket available on backend. When an event happens, like start recording, etc... it would be wrotten 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...).

Frontend Addons

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.

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.

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.

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.

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

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.

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

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