Difference between revisions of "Feature Wishlist (Setup)"

Latest revision as of 20:04, 12 January 2014

Initial setup

• Export and Import of frontend settings. Perhaps into the backend, so all new frontends could take it as template in the initial setup.
• Simple request: Could there be name coherency among the setup commands (mythtv-setup, mythwelcome --setup, mythfrontend ("embedded" setup)? Or even better, can there be a single setup command that can setup all three sections?
• Provide visual feedback when external commands don't exist (e.g. when you type in a channel change command and mistype it). Printing "WARNING: Command not found" in red right below the text box if the entered path or command is not found would be sufficient.
• Provide an option under setup that will gather system/mythtv config and info and allow a user to send an email to mythtv-users mail lists after careful prompting to ensure that new users can file useful bug reports or ask for help while including as much required information to provide a solution (Something similar to bug-buddy )
• Provide autodetection of cards across card types, to provide a list of all available tuners to be added, rather than requiring user to know the type of card they want to add.
• When no channels are found during the channel scan it would be less confusing to have a message indicating this.
• Choose to avoid the tuning of the last tuned channel at the first startup of MythTV. If the last tuned channel was scrambled or fault the frontend hangs.
• Re-organization of configuration menus, hiding "advanced" features (or those which are normally fine when set to default), to assist an easier install for new users.
• Create a complete list of what libraries are required to compile the various options (ALSA, DTS-Passthrough, etc...)
• Increase the limit on the combo box for time to wait for the next recording. The current limit of 120 minutes is too short for some cases, and there is no apparent reason for such a limit. Suggest increasing to at least 720, if not 1440 (24 hours). The setting can be found in mythtv-setup/backendsettings.cpp, line 344.
• Gentoo Packaging Provide processor feature-set (instruction-set-extensions) support via USE-flags: I try to build a Gentoo-based system using MyhtTV in a virtual-machine (VirtualBox) on an AMD Phenom II X6-based host. Later, I'll copy the system to the actual target which is a Celeron-M based on the PentiumIII (Coppermine). The target CPU only supports MMX and SSE. The host CPU supports much more (SSE2, SSE3, ...) and MythTV's build system (I use the ebuilds from https://github.com/MythTV/packaging/tree/master/Gentoo) detects the CPU's features at compile-time. On the target, mythfrontend gets killed with SIGILL (Illegal instruction). Either MythTV should use run-time CPU detection (quite some work to implement) or the ebuilds should have USE-flags to hard-force the instruction set extensions that the target-processor supports (Not so much work, there are many ebuilds in the official tree that do so and since you have the configure-options anyways...)
• Not exactly suited for inclusion in MythTV itself, but I don't know where to put it: It would be immensely helpful to have a desktop-based MythUI theme development tool with a graphical frontend, for people who want to customize their MythBox's look and feel but are hopeless with the XML required. The frontend could probably even be hacked from a FOSS DVD authoring program like DVDStyler.

Hardware support

• Support for additional tuners/cards on Mac OS X running Mythbackend.
• Menu navigation through mouse-wheel and possibility to assign actions to mouse buttons. --Matt 12:09, 28 April 2007 (UTC) -- Already possible to some degree and 0.22 will have full mouse support, though it's more about supporting touchscreens.--GBee 18:41, 22 March 2008 (UTC)
• Support for Consumer Electronics Control (CEC) bus on HDMI interface equipped systems. --Rhulme
• Support for the V4L radio device on Hauppauge cards as another TV channel (as per DVB radio channels) - tuned Radio can be played off /dev/video0, so extending the available inputs in the card set up should make this simple.
• Add to mythbackend setup menu item to reset dish motor (move to reference position).

Channel Management

• Editing more than one channel at the time for example to set them to visible should be possible
• Sort/select channels by missing XMLTV ID
• Option to tag channels as belonging to a group. For example, Premiere channels in Germany, Digital+ channels in Spain (all being on one Satellite). Enable filtering by these groups.
• Modern way to add channel icons (selection box, or by naming scheme like for example chanid.png) -- See #3334 -- Matthew Wire
• Reordering the channels to a preferred viewing order without changing the channel number (as it currently breaks the recording schedules if you do so)
• Preview selected channel, to allow the user to easily choose what channel to keep and what channel to delete. This is expecially useful after a DVB-S receiver scan, which often discover thousands of channels.
• DVB-T channel scanning here in Sweden (maybe the same setup elsewhere?) depending on the location you can have multiple transponders providing the same stream, but some of those transponders can be far off. The problem that we have here is that it some times chooses the weak transponder instead of the strong one. This could be solved the easy way or the hard way.
  1. Have a limit (user specified) of the lowest accepted signal-strength can be and ignore any transponders below that limit.
  2. After a scan has been done display a list of "conflicting" transponders, and their signal-strength, and ask what transponders it should use.
• Save the signal-strength/signal quality of each transponder to the database (update each time you try to tune to it) for easier lookup so it can be displayed in mythweb for easier maintenance of "good" channels. (Good for DVB-S)
• Enable some type of "channel/transponder available from 22.00->07.00" that would pause any type of attempted recording from that channel/transponder. This is a problem for people that are on the edge on the reception area of some satellites and able to tune into them during the day but not the night etc. Could also be useful if you want to use a specified card for something else during specified hours every night.
• At least display both physical channel number & subchannel number for digital channels in one of the channel editing channel lists. I can get a channel mapping between physical channel number_subchannel to Comcast channel numbers, and I can get a mapping of XMLTV IDs to Comcast channel numbers, but the channel numbers that MythTV chooses are random. While buried in the channel editor I can get the physical channel to mythTV channel number mapping, that does not help a whole lot when each physical channel can have as many as 50 subchannels, and the subchannel number is nowhere to be found without dumping the database.

Card Management

• Provide a way of deleting all transports for a given video source.
• Make myth use vendor ID's or something so it doesn't rely on /dev entries which can come up in any order on reboot. (Note: This could be fixed by fiddling around with udev but it's a lot of work and there's very little documentation. You also have to change the udev rules every time you add/remove a tuner from a different vendor).

Won't Implement

The following features are either ones that should either be implemented as a 3rd party solution, are are something outside the capability or designed intent of MythTV.

• While I'm sure its already somewhat possible with DSLinux and lynx, why not create a Nintendo DS homebrew application that would allow you to interact with mythTV? Imagine it, the remote like size of a DS lite, paired with the limitless possibilities for a gui interface with 2 screens and stylus/button control. I can't imagine an easier way to interact wirelessly with mythTV from my couch. Please make this happen, The DS homebrew community is thriving, it really wouldn't take much to slap a prototype together, and I'm sure things would move quickly after that. Someone with the skills needs to do this.
  • An initial version of this has already been done, take a look at this MythRemote for NDS
• Front-end setup option to mythvideo allowing user to select whether or not changing to a higher parent control level includes all lower levels in the display or not. For example, currently parent control level 3 displays all videos from levels 1-3 vs only those set to parent control level 3. This eases navigation when a large number of videos is present. I've hard coded this in videofilters.cpp but don't have the skill to code this as a user selectable option into the setup screens.
  • Parental controls are only intended to restrict access to certain content, not as an organization tool. If you need something to speed navigation through a large library, use the Filter through the 'm' menu. The Genre and Category fields already exist to do exactly what you want. wagnerrp 00:44, 5 November 2009 (UTC)
• During setup use a font that allow's you to tell the difference between 0 and O and I and l at least for the mysql password field.
  • The font is defined by the theme, not mythtv-setup.
• mythtv-setup fail explicitly on (first) sql failure

mythtv-setup application is slated for removal

• Front-end setup to set screen dimensions. If a TV/monitor reports the wrong dimensions via EDID the only way to fix this currently is to edit xorg.conf to add a DisplaySize entry. Requiring users to edit xorg.conf is cruel & unusual punishment. Include a couple of boxes on the Setup>Appearance menu defaulting to 0 for X & Y dimensions. If zero accept what xorg says, if non-zero take these dimensions when scaling TV display.

scaling is determined by the theme, and physical display size set in X has no effect

• Combine video source and input connection into one entity. Video source is a basically Data Direct lineup, and input connections are inputs to the tuner. You can of course set up video source and input connection one to one by having multiple zap2It lineups, but why not just make it so by combining the two together? The fact that you can set up one video source and two input connections is pretty confusing.

The proposal would increase processing, disk, database, and bandwidth load, for both user and provider, on multi-tuner systems, based off the assumption the user cannot grasp a fairly simple concept. The two may be renamed to be more explicit to the user, and the internal workings may be hidden from the user, but the behavior will remain.