Feature Wishlist (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.
- Use MythTV-Setup on your frontend machine to configure the backend. So every part wich mythtv-setup uses to detect hardware or other things need to be integrated into the backend. So that on a backend machine no X11 is needed to configure myth!
- This is very easy to do without making any changes to MythTV, just basic unix/X Windows
- Try using vnc to connect remotely to your backend server, with this solution you can even use a windows machine to remotely configure your headless/keyboardless machine
- Or try remote X Windows display, back to a machine with a X Server running, google ssh -X
- This is very easy to do without making any changes to MythTV, just basic unix/X Windows
- 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 )
- suggestion that would require some v4l support... autodetect / enumerate all cards (and then of course allow deletion of individual sources via mythtv-setup).
- 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.
- mythtv-setup fail explicitly on (first) sql failure
- Current behaviour: In mythtv-setup, a channel scan in Input Connections sets the starting channel for the tuner used in the scan. No other tuners that use the same channel source are affected. Proposal: When a starting channel is set (by a human or via a channel scan), also set the starting channel for all other tuners that use the same channel source. Only apply the enhancement to a tuner with no _defined_ starting channel or no _valid_ starting channel.
- If the above is not implemented please change the HOWTO to indicate that if you use the grabbers you MUST tell them which channels you have (if you don't know, tough!).
- 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.
- setup and define network interface -- Huh? Why would you want to define your network interface through MythTV?--GBee 18:38, 22 March 2008 (UTC)
- 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.
- Support for additional tuners/cards on Mac OS X running Mythbackend.
- A solution to allow MythTV to watch and record encrypted digital cable broadcasts that the user has licensed. This is an EXTREME pipe dream as it would require 1) cooperation, or at least noninterference, from the cable companies; 2) digital receiver cards that can accept CAMs from the cable provider; 3) volunteers to code the drivers.
- Note that this isn't *quite* as far fetched as it sounds. It *may* prove possible to receive unencrypted (non-pay) digital cable channels in the US with the pcHDTV3000 card. The encrypted ones would require a card compatible with a CableCard decryption card -- which cable companies *are* required to provide if you ask for one... but we're unlikely to see such a card ship *before* the July 1 2004 advent of the broadcast flag. So support EFF in getting it thrown out. :-) -- BayLink
- 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
- 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.
- 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.
- Have a limit (user specified) of the lowest accepted signal-strength can be and ignore any transponders below that limit.
- 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)
- Simple maintenance of channels via the front-end, maybe even during playback, where you can change the xmltv-id and if it should be visible, use eit etc. This is primary for easier handling of channels when using DVB-S and have thousands of channels that you want to skip or correct information for.
- This is already implemented, hit E while watching TV to bring up the channel editor
- 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.
- 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.
For Example, my tuner has coax/tuner in and svideo in. I define one zip2it line-up of the unencrypted channels, and one with the encrypted. I create two videos sources connected to the two line-ups, and then two input connections, one for the tuner and no channel change script and connected to one the unencrypted lineup, and one with the svideo and channel change script for my blaster connected to the svideo and encrypted channels.
- 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).
- The Hauppauge HVR-1300 Hybrid DVB-T/MPEG/Analogue card outputs a Linux TV DVB v3.x DVB-T stream, Hardware MPEG encoding and V4L frame grabber of Analogue TV/S-Video/Composite inputs.
The card works perfectly as a 'DVB DTV Capture Card (v3.x)'. Just load the cx88_dvb module. However, loading the cx88_blackbird module does not. The reason is that (possibly due to the internal wiring of the card) only DVB-T OR MPEG/analogue can be used, not both at the same time. MythTV sees this as three separate cards and tries to use them both at the same time, locking the other out. There are possibly more cards for which this behavior is the case. Rather than trying to allow for this explicitly, introduce the notion of card groups. Only one card in any group can be used at a time. Any card that can be used simultaneously is assigned another group number. In the case of the HVR-1300, the DVB-T input is configured as a 'DVB DTV Capture Card (v3.x)' in group 1 and the hardware MPEG encoder input would be configured as /dev/v4l/video1 under 'MPEG Capture Card' group 1. If you really want to cook your CPU or if you have hardware MPEG on the motherboard, the analogue input can be configured as /dev/v4l/video0 under 'V4L Capture Card'. A second card would be configured in a similar manor but assigned to group 2 indicating that this card can be used concurrently with one of those in the other group.
The following features have already been implemented, either in previous releases or head.