Difference between revisions of "Feature Wishlist (Backend Addons)"

From MythTV Official Wiki
Jump to: navigation, search
m (Backend Addons)
 
(119 intermediate revisions by 45 users not shown)
Line 3: Line 3:
 
== Backend Addons ==
 
== Backend Addons ==
 
=== General ===
 
=== General ===
*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.
+
*It is an excellent feature of MythTV that you can delete recordings and they are kept until they have to autoexpire (because the disk is getting full). The problem is that this all occurs within MythTV, so backup programs etc. don't know about it. It would be great if deleted-but-not-expired recordings could be put in a "Deleted" folder within the recordings folder. This should not take any disk I/O, as the folder will nearly always be on the same disk. It would allow me to schedule a backup that included my recordings folder, but excluded my "Deleted" folder. At the moment, the folder is too big to backup, so I just can't --[[Hooloovoo]].
*Display "Next Scheduled Recording" through LIRC VFD. It would be nice to have the next scheduled recording andif recording has aready started, a VFD display of program name and graphical status bar of recording. ie.. Heros - 0-------x----100%
+
:: You could run [[Mythrename.pl|mythrename.pl]] with the --link option, to add a bunch of symlinks to a separate folder. Deleted recordings will be marked with the 'Deleted' recgroup, which corresponds to the '%U' flag in the format string. Simply set your backup to filter based off that.
*Password protection.  Before being able to talk to the backend a frontend must send a password.  This would make it more secure if a user wanted to open up their mythtv port to the outside. -- '''Is this really neccessary when you can port forward through ssh for security anyway?''' [[User:UKDude|UKDude]] - Please point to howto instructions. --[[User:Turpie|Turpie]] 00:42, 6 August 2007 (UTC)
 
*Keep statistics of "Time Saved" - Keep individual stats on ammount of time saved using time stretch, as well as time saved using commercial skipping and the sum of the two in order to tell the user how much total time of TV they've watched and how much total time they've saved using time stretch and commercial skipping.
 
*More intelligent job queue system/ui for each recorded show, showing jobs as an actual queue instead of just started or stopped (similar to what the system status shows.)  This will make clear what order jobs will run in as well as allow a user to queue a single job twice.
 
*Give Commerical Flagging jobs priority over Transcoding jobs.
 
*Give the option to only process one (or some arbitrary number) HD job at a time - 3 HD transcoding jobs can clog up the queue and prevent commercial flagging jobs and faster SD transcoding from occurring for long periods of time.  
 
*Give separate options for number of jobs on a backend for each job type. For example, I could say a backend can do 2 commercial flagging jobs, 1 transcoding job, and 2 User Job #1s at once. Maybe replace the "Allow Transcoding Jobs" checkbox with a text field that sets the number allowed?  This would allow better processing distribution across several backends.
 
*Add new flag to recorded shows that indicates if they have previously had their commercials/cut-list cut from them.  The commercial and cut-list flags are currently erased after a show is transcoded.
 
*Differentiate between actual transcoding of formats and those jobs that will simply implement the cut list.
 
*Allow user to transcode out of .nuv entirely for users who use MythTV more as an personal video file server than as a Tivo. Also useful for Windows users. (See [[MythArchive]].) --'''could this be removed now that all mpg streams are no longer given the nuv extension?''' [[User:UKDude|UKDude]]
 
*Allow for an arbitrary number of User Jobs (create a userjob table in the database?)
 
 
* Have mythbackend back up the mythconverg database on a flexible schedule.
 
* Have mythbackend back up the mythconverg database on a flexible schedule.
** ''Could this use the same interface & scheduling code as the existing mythfilldatabase scheduler?  If so, it might be a relatively simple feature to add.'' [[User:DStulken|DStulken]]
+
:: The [[Database Backup and Restore#Automating_Database_Backups|Database Backup and Restore]]. [[User:Wagnerrp|wagnerrp]] can be run through cron or the backend init script, and is automatically called in the event of a schema update.
* provide arbitrary encapsulation of ANY UNIX application started fullscreen inside of a VNC session and assign to a Channel - I.E - start a vnc session with xterm in fullscreen, assign to channel 100, start xchat logging into #mythtv-users and assign to channel 101, etc.
 
* more tightly integrate mythfilldatabase into mythtv-setup...the setup tool should be able to know if you're the backend or not and know when you last ran mythfilldatabase...and it should let you run it from the gui -- '''Unlikely to Implement''' --[[User:GBee|GBee]] 18:52, 28 January 2007 (UTC)
 
* add support for the backend to indentify itself to Apple's FrontRow App as a computer on the network with media available (basically tricking FrontRow into thinking that the backend is another apple computer with shared media)
 
* Provide an option to get time/date info for the system from DVB streams
 
* Would it be possible to create an addition or alter the mtd daemon in the MythDVD package to allow the transcode software to run in cluster mode over multiple backends/frontends to increase the speed of DVD Ripping by running the transcode sessions in parallel. (Somewhat similar to the perl DVD:Rip frontend)
 
* mythfilldatabase function for easier integration. An option like "--chanmatch" or similar could be used to get the mythfilldatabase to not only match the xmltvid, if no channel already exists with that id, but also match the name/callsign to it's best ability and ask the user if the match is correct, if yes then set the xmltvid to that chan. This is something i myself experienced when adding channels from the Astra2 sat-cluster when getting matches between the name from the xmltv output and the dvb-s scan that sometimes it got a perfect match on callsign and sometimes on the name.
 
* Ability to "schedule" a script that will do some work on one or more input cards and that via the mythbackend will determine when it's going to be run. Example of a schedule could be "Sometime between 02-17 and lenght of job is 30 minutes" and then the backend would run it at the first possible chance it has during this time. Example usage for this is for scanning for new channels via scripts (mainly dvb) or grabbing a custom stream of EPG data from a provider.
 
 
* Identify hardware in the system by it's pci-id and/or the cardname-string instead of having it go via a "dumb" sourceid and devicefiles. This would make the system much more stable when doing software/hardware upgrades that messes up the order the drivers gets loaded in and should be quite easy to implement. sourceid 0 = "PVR-150" -> find the devicefile that identifies itself with this string.
 
* Identify hardware in the system by it's pci-id and/or the cardname-string instead of having it go via a "dumb" sourceid and devicefiles. This would make the system much more stable when doing software/hardware upgrades that messes up the order the drivers gets loaded in and should be quite easy to implement. sourceid 0 = "PVR-150" -> find the devicefile that identifies itself with this string.
 +
** Ideally the operating system would assure a stable device order, though we know this isn't the case on any Linux distro's since the introduction of udev. The information available to udev is visible to MythTV in recent kernels, but it would probably be best if time was spent on writing udev rules and providing them to distro's rather than incorporating udev functionality into MythTV.
 
* Ability to give Myth a short video, channel and duration that whenever it is idle it watches the channel waiting for something that looks similar to the video and starts recording for the given duration. Maybe even keep the last x minutes on a ring buffer so that can be put on the start. Could be useful for example to record a generic show when guide data is unavailable, unreliable (which I've noticed is the case with certain channels (WIN) on their attitude towards filler programs (Farscape)), or subject to a last minute change (like when sport or an emergency news broadcast has been on beforehand).
 
* Ability to give Myth a short video, channel and duration that whenever it is idle it watches the channel waiting for something that looks similar to the video and starts recording for the given duration. Maybe even keep the last x minutes on a ring buffer so that can be put on the start. Could be useful for example to record a generic show when guide data is unavailable, unreliable (which I've noticed is the case with certain channels (WIN) on their attitude towards filler programs (Farscape)), or subject to a last minute change (like when sport or an emergency news broadcast has been on beforehand).
* Enable run a user defined job before recording
 
 
* option to create 'blacklist' of unwanted programs so that when zapping, mythTV will skip chanels on which these programs are running
 
* option to create 'blacklist' of unwanted programs so that when zapping, mythTV will skip chanels on which these programs are running
 
* keep statistics on DVB signal strength so you can see the effective quality of reception or aerial, and keep track of dropped packet counts for recordings, allowing people to know if a recording is good before trying to play it
 
* keep statistics on DVB signal strength so you can see the effective quality of reception or aerial, and keep track of dropped packet counts for recordings, allowing people to know if a recording is good before trying to play it
 
* Priority setting to select what EPG to use for a specific channel. If you have multiple capture cards (mix between analog and DVB-cards) you might want to use the EPG data from the DVB card also for the Analog channel.An option could also be, to reduce the size of the program table, to use the callsign and/or name and/or xmltvid instead of the chanid as the identifier for the program data that would then enable you to greatly reduce the amount of data needed in the program table and also enable you to use a DVB-EPG for a analog card that can receive the same channel.
 
* Priority setting to select what EPG to use for a specific channel. If you have multiple capture cards (mix between analog and DVB-cards) you might want to use the EPG data from the DVB card also for the Analog channel.An option could also be, to reduce the size of the program table, to use the callsign and/or name and/or xmltvid instead of the chanid as the identifier for the program data that would then enable you to greatly reduce the amount of data needed in the program table and also enable you to use a DVB-EPG for a analog card that can receive the same channel.
 
* When exiting LiveTV both the input and the channel number should be saved, so that when you re-enter LiveTV it will start at the last channel you were watching. As it is today it will always start at the first input when entering LiveTV. Ideally this should be handled by the frontend so that each frontend will automatically start at the channel it was last watching.
 
* When exiting LiveTV both the input and the channel number should be saved, so that when you re-enter LiveTV it will start at the last channel you were watching. As it is today it will always start at the first input when entering LiveTV. Ideally this should be handled by the frontend so that each frontend will automatically start at the channel it was last watching.
* 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.
 
 
* Additional setting to expiration of recordings that would enable automatic expiration of all recordings older than X days.
 
* Additional setting to expiration of recordings that would enable automatic expiration of all recordings older than X days.
* Converge the storage of videos from mythvideo and the recorded shows such that mythtv really doesn't care about what it's storing. This way you can set a new season of a show to record and be stored/accessed along side you're dvd backups of the previous season.  Then allow the importing/overwriting of shows with a supplied video file.  Each media item would have either a specified plugin or player for playback. [Dolcraith]
+
* Converge the storage of videos from mythvideo and the recorded shows such that mythtv really doesn't care about what it's storing. This way you can set a new season of a show to record and be stored/accessed along side you're dvd backups of the previous season.  Then allow the importing/overwriting of shows with a supplied video file.  Each media item would have either a specified plugin or player for playback. Dolcraith
* Allow the backend to support older versions of the frontend. Not necessary ad-infinitum, but at least the previous version or so. This would make upgrading a Myth setup easier so you don't have to upgrade everything at once.
+
:: Partial merging of the database tables for recordings/videos/music/photos is planned, along with matching internal code structures, however there is no intention to merge this content into a single view. Such content is more logically kept separate.
 
* If the backend attempts to record a showing and is unable to (cable box is turned off, cable disconnected, etc) and there is a spare tuner that is available and that can record the same show at the same time (possibly a tuner without a cable box, different connection) the backend should try to record the show on the unused tuner (possibly unless there is a tuner preference) instead of failing.
 
* If the backend attempts to record a showing and is unable to (cable box is turned off, cable disconnected, etc) and there is a spare tuner that is available and that can record the same show at the same time (possibly a tuner without a cable box, different connection) the backend should try to record the show on the unused tuner (possibly unless there is a tuner preference) instead of failing.
* Smarter transcoder profile selection.  Ability to specify the transcoder profile based on various parameters of the video file (resolution, rate, etc). Similar to the new playback modes selection. The idea here is that sometimes my system records a program in hi-def because the standard def tuner is in use. I really don't care about that program being in hi-def and would like to transcode it to a smaller size (resolution and bit-rate), but when the same program is recorded in standard def, I don't want the size changed.
+
* '''resume interrupted recordings''' also if later is available (record the later too of course if possible).
*mythbackend can be run as a daemon on *nix systems. As such, it should support the capability to log via syslog (to a user-configurable facility) rather than directly writing its' own log files.
+
**Reason: the whole thing is scheduled this way and changes are unexpected and ''(especially when reconfiguration has no gain)'' senseless and leave the recorder unused.  
 +
**Also if interrupts happen at all then more interrupts are likely too and the later recording could easily suffer interrupting too.
 +
** Proposed behavior: once recording has started keep that schedule and resume it if interrupted. if later airing is available and does not interfere with the schedule also the later airing should be scheduled too. [http://code.mythtv.org/trac/ticket/10048 apparently NoBUG?]
 +
** currently rerecording can override lower priority recordings , however generally rerecordings could have a general priority drop, when schedule changes for rerecordings would be required this way only very low priority recordings are overridden.
 +
**conclusion: in total the user only suffers a tiny loss of the recording
 +
** also often the user does not require the rerecording except of getting hold of the end at all --[[User:Sususu|Sususu]] 09:08, 20 September 2011 (UTC)
 +
* Preferred EIT Grabber channel. Some cable providers in Europe send only now/next on every channel. All other EPG is send on a specific transponder/channel. A checkbox in mythtv-setup to set a special algorithm for EIT scan together with a preferred channel would be nice.
 +
** Example: Main EIT channel is on channel-number 1 (preferred channel). Special algorithm: EIT grabber jumps to channum 1, then 2, then 1, then 3, then 1, then 4, then 1, then 5
 +
::: Follow-up Question: I don't understand the purpose of this 'special algorithm. Why not just ignore all the other channels and only pull data from channum 1?
 +
::::: Answer: You are right that is not really necessary (the reason i suggested this was, that now-next is updated too), but id would definitely be of great value if one could set 3 preferred channels or so ..
 +
: Doesn't MythTV currently scan through all channels marked for on-air data? Wouldn't this special channel already get polled to populate the other channels' long term data?
 +
: If you know of technical documentation describing ways to automatically find out about the "guide service" add it to {{ticket|11809}}, please. --[[User:Dekarl|Dekarl]] 20:44, 29 January 2014 (UTC)
 
* Multilingual EIT support. At least some networks in Finland broadcast program data in several languages, presented as multiple descriptors in the same event entry. The descriptors come in a changing and seemingly random order, and MythTV currently seems to take the first (or last?) of them. As a result, program titles may change back and forth between the languages, which can cause recordings to be missed. The solution to this would include:
 
* Multilingual EIT support. At least some networks in Finland broadcast program data in several languages, presented as multiple descriptors in the same event entry. The descriptors come in a changing and seemingly random order, and MythTV currently seems to take the first (or last?) of them. As a result, program titles may change back and forth between the languages, which can cause recordings to be missed. The solution to this would include:
 
** Adding a 'language' column to all tables that contain program data
 
** Adding a 'language' column to all tables that contain program data
Line 45: Line 38:
 
** As a simpler alternative to all of the above, could also keep database and frontend as is, and just add a preferred language(s) setting to the backend, to control which of the titles and descriptions the EIT scanner stores. Having all languages in the database and letting users select them in the frontend would seem like the better and more flexible solution, though.
 
** As a simpler alternative to all of the above, could also keep database and frontend as is, and just add a preferred language(s) setting to the backend, to control which of the titles and descriptions the EIT scanner stores. Having all languages in the database and letting users select them in the frontend would seem like the better and more flexible solution, though.
 
* Allow mythbackend to run a automatic minimal updates channel rescan. My cableco occasionally shifts around channels on QAM. When it fails to find the correct program id, check to see if that channel title exists under any other id, rather than reporting successful recording of a 0B file.
 
* Allow mythbackend to run a automatic minimal updates channel rescan. My cableco occasionally shifts around channels on QAM. When it fails to find the correct program id, check to see if that channel title exists under any other id, rather than reporting successful recording of a 0B file.
 +
** As such behavior would currently require a restart of all backends, running an abbreviated EIT scan that just makes sure all channels are tunable, and raising an error if not, would be a simpler solution. [[User:Wagnerrp|wagnerrp]] 20:59, 3 November 2009 (UTC)
 +
* Stop EIT update from preventing a backend box from going to sleep. Perhaps have a scheduled EIT update time per time period, so that EIT updates could still occur without preventing power saving.
 +
** As an alternative, allow users to select when and how an EIT update will occur. Constant EIT scans are not necessary when broadcasters provide 7 to 8 days information, as they now do in Australia. (As a work-around, turn EIT off and use the a script based on tv_grab_dvb to provide EPG data to mythfilldatabase.)
 +
: Your wish has been granted {{gitcommit|e73015ba7f}} --[[User:Dekarl|Dekarl]] 20:44, 29 January 2014 (UTC)
 +
* Add a panel application for MythTV back end that shows if it is recording or idle. Hovering the mouse should show next scheduled recording. This would be helpful for those who use their computer for front end, back end, and desktop. Currently, I must run mythweb, or myth front end to find out the state of myth back end. I must know the state of myth backend if I wish to do system maintenance, reboot the computer, or run a resource intensive application to prevent interrupting a recording. Myth welcome is nice, but it gets in the way when using the system as a desktop.
 +
:: Preliminary version for Gnome: [http://www.mythtv.org/wiki/Mythstatus.py mythstatus.py]
 +
:: exists for Windows -- [http://www.codeplex.com/mythtvSidebarGadget MythTV Sidebar Gadget]
 +
::: The Windows gadget is GPLd so it should be possible to port it to the widget engines used by X based desktops like KDE and GNOME for use on Linux and other FLOSS operating systems.
 +
* 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.
 +
:: Could be handled by an external script pulling a list of expiring recordings over the backend protocol.
 +
* 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.
 +
* Support for several titles to same program.
 +
:: Having localized titles improves WAF, but often breaks coverart scripts. Currently XML grabbers already know of different titles for same program - using the original title for covertart and localized title for display would be perfect.
 +
::: Recorded content does not currently have real artwork support. The artwork displayed by some themes is merely where the frontend thinks images for that title might be stored in the MythVideo folders. Planned changes to the way videos are stored in the database would allow proper handling of artwork for recorded shows, and would make at least the stated reason for needing multiple titles unnecessary.
 +
* about MySQL Queries on example of duplicate show markings:  i experience a great performance loss when "mythfilldatabase" is run and i traced it back to the mark first and last queries ... which are hard coded and the whole thing being glued together in "mythfilldatabse" ... so this is rather a general request uncouple the queries from the sourcecode ... maybe by scripts or maybe in a secondary file (PS: my approach speeds marking up by 900% explanation would be a bit longer so message me if you would like to know how )
 +
:: if it would be a different script one could also employ a "softer" duplication finder
 +
:: Why not force mythfilldatabase to occur during a time that it does not cause you problems? [[User:Wagnerrp|wagnerrp]] 12:19, 4 April 2012 (UTC)
 +
 +
=== Security/Multi-User Management ===
 +
* Password protection.  Before being able to talk to the backend a frontend must send a password.  This would make it more secure if a user wanted to open up their mythtv port to the outside. -- '''Is this really neccessary when you can port forward through ssh for security anyway?''' [[User:UKDude|UKDude]] - Please point to howto instructions. --[[User:Turpie|Turpie]] 00:42, 6 August 2007 (UTC)
 +
* Ability to have a required log-on for all frontends with a unique ID and pass after registering. Some features would include limmiting number of shows someone can record per week, giving users who are currently watching TV priority, aka locking the channel, to prevent other users from messing up the recording, most of the parental controls from above included, and the log of each user and their activity. Also the ablility to download the shows to the frontend to limit stress on server.
 +
* [http://gossamer-threads.com/lists/mythtv/dev/5680 Channel lock],or just 'lock'. ''Users can receive a warning when attempting to change the channel while not caught up to real time, so the original purpose behind this is moot.''. Might (still) be handy for parents with little kids.
 +
* Add ability for mythtv to log all shows watched (live or recorded) during a day and store in a unique log file per day to store tv watching history. Add ability to put parental controls on mythtv to only allow a given number of hours of tv watching during the day, only allow certain channels during certain times on certain days of the week.
 +
* How about a feature that would allow you to 'markup' DVD's to skip unwanted scenes for parental control or even look at the subtitles and mute when there are bad words? ''DVD subtitles are images, so that last part would require significant OCR'ing...''
 +
:* Add [http://www.clearplay.com ClearPlay]-like content filtering, not just identification, to MythTV.
 +
* The ability to lock out specific frontends from specific channels (still tuneable, just not watchable. 4-digit PIN code to override). Maybe you have one frontend in the living room, one in the bedroom and one in the kids' room. It would be nice to be able to only send Cartoon Network, etc. into the kids' room while sending Playboy TV, etc. only to the bedroom... I imagine setting up a "standard package" and then registering the frontends somehow and customizing their channels. I guess this sounds awfully broadcasterish, which is not the original intention, but apparently a positive side-effect ;-)
  
 
=== Hardware support ===
 
=== Hardware support ===
 
* Fedora 7 firewire support (The new Firewire stack uses /dev/fw[0-9] in place of /dev/raw1394 but is library compatible with the old system.. All of the old documentation in the wiki doesnt work however.  This stack will be added to the kernel soon, but it's hit us Fedora 7 Myth 20.1 SVN users early :..(  -- [[user:UKDude|UKDude]]
 
  
 
* Per-card audio level controls, to compensate for potentially double-digit dB differences in capture levels across differing revisions, models, and even brands of capture cards.  (Extra credit while working there:  per-input and per-channel controls as well.)  Discussion and potential design can be found at [http://www.gossamer-threads.com/lists/mythtv/users/173374 Why is my 350's audio so much l-l-louder! than the 250's?] and [http://www.gossamer-threads.com/lists/mythtv/dev/174147 No per-individual line-level adjust: bug or missing feature?] and (inadvertently broken thread) [http://www.gossamer-threads.com/lists/mythtv/dev/174303 here].
 
* Per-card audio level controls, to compensate for potentially double-digit dB differences in capture levels across differing revisions, models, and even brands of capture cards.  (Extra credit while working there:  per-input and per-channel controls as well.)  Discussion and potential design can be found at [http://www.gossamer-threads.com/lists/mythtv/users/173374 Why is my 350's audio so much l-l-louder! than the 250's?] and [http://www.gossamer-threads.com/lists/mythtv/dev/174147 No per-individual line-level adjust: bug or missing feature?] and (inadvertently broken thread) [http://www.gossamer-threads.com/lists/mythtv/dev/174303 here].
* [http://gossamer-threads.com/lists/mythtv/dev/2622#2622 Automatic record/playback tweaking] - trade-offs between CPU usage and disk size?
 
* USB-UIRT - IR blaster
 
 
* USB hard drive - have the ability to plug in a USB hard drive and transfer video files over to the hard drive with menus in the myth GUI
 
* USB hard drive - have the ability to plug in a USB hard drive and transfer video files over to the hard drive with menus in the myth GUI
 
* External script support for DVB-T tuner cards to control OTA antenna rotors.  This is especially important for US users since the NTSC analog shutdown is about one year away.  ATSC stations are difficult to tune in fringe areas, and there needs to be a linkage to allow an external IR rotor controler (such as the Channel Master 9537) to align the antenna.  This is NOT the same as Diseqc, since that controls LNB's and Dish rotators.  If there would be a flag and pointer to an external change script in the DVB-T tuning code, it may not be a major code overhaul.  I am willing to test any implementation, since without it, my ATSC options are very limited.  [[user:lbelan63|lbelan63]]
 
* External script support for DVB-T tuner cards to control OTA antenna rotors.  This is especially important for US users since the NTSC analog shutdown is about one year away.  ATSC stations are difficult to tune in fringe areas, and there needs to be a linkage to allow an external IR rotor controler (such as the Channel Master 9537) to align the antenna.  This is NOT the same as Diseqc, since that controls LNB's and Dish rotators.  If there would be a flag and pointer to an external change script in the DVB-T tuning code, it may not be a major code overhaul.  I am willing to test any implementation, since without it, my ATSC options are very limited.  [[user:lbelan63|lbelan63]]
 +
* Support SAT>IP. These are DVB-S or DVB-C receivers which are connected to the ethernet instead of Plugin to PCI, PCIe oder USB. See http://www.satip.info/. Example Devices are the "Octopus Network TV-Tuners from DigitalDevices" (see http://shop.digital-devices.de/)
 +
* To use SAT>IP equipment for home use (like http://www.tbsdtv.com/products/iptv-streamer.html), which can not stream all TV channels simultaneously, I am dependant on the "Recording pending" system event in order to tune the box to the wanted channel. Would it be possible to add a system event "Tuning pending" which is triggered when MythTV want to tune to a channel? This would make the IPTV equipment also work for live TV and receiving EIT data.
  
 
===Input Streams - TV/Radio/Other===
 
===Input Streams - TV/Radio/Other===
 
* Provide local channel rss feeds. (ie. cable station website gives rss feed for programming on a channel otherwise seen as "local programming" or similar)
 
* Provide local channel rss feeds. (ie. cable station website gives rss feed for programming on a channel otherwise seen as "local programming" or similar)
 +
** Better implemented in MythWeb, which already offers some iCal/RSS support. [[User:Wagnerrp|wagnerrp]] 20:59, 3 November 2009 (UTC)
 
* Provide some way for users with multiple available tv cards to switch channels, while keeping the ringbuffer for the previous channel until system runs out of tv cards. This would allow flipping between two shows and keeping the ringbuffer for both
 
* Provide some way for users with multiple available tv cards to switch channels, while keeping the ringbuffer for the previous channel until system runs out of tv cards. This would allow flipping between two shows and keeping the ringbuffer for both
* Add Support to use Internet TV from the backend, so that it could be use like a normal Channel (Record, Skip Back, ...) --[[User:Anaerin|Anaerin]] ''Also known as [[IPTV]]''
 
 
* Some stuff for channels with encryption to make it easier to manage channels that you have subscribed to. (especially with DVB-s since you can have multiple providers on the same sat)
 
* Some stuff for channels with encryption to make it easier to manage channels that you have subscribed to. (especially with DVB-s since you can have multiple providers on the same sat)
 
* Ability to read out the channel-name from teletext (useful when scanning channels). Maybe could be good to have this as a "script-plugin" where myth calls the script with the 2 top lines from the teletext and then the script should return the chan-name.
 
* Ability to read out the channel-name from teletext (useful when scanning channels). Maybe could be good to have this as a "script-plugin" where myth calls the script with the 2 top lines from the teletext and then the script should return the chan-name.
 
+
:: Already done for digital channels.  With analog TV being slowly phased out worldwide, it's not likely anyone is going to invest much time in a new feature only usable with analog channels.
 
* Audio Description support for blind and partially sighted folk, where this is available as a separate audio track.  Could be merged into main soundtrack (may be issues with differing bit rates) or stored separately from the main programme stream for later re-assembly?  On the DVB-T streams I'm capturing in the UK, something like this works as a post-processing job, but it would be much nicer to do within Myth rather than by unpacking, hacking around and then reassembling the MPEG stream...
 
* Audio Description support for blind and partially sighted folk, where this is available as a separate audio track.  Could be merged into main soundtrack (may be issues with differing bit rates) or stored separately from the main programme stream for later re-assembly?  On the DVB-T streams I'm capturing in the UK, something like this works as a post-processing job, but it would be much nicer to do within Myth rather than by unpacking, hacking around and then reassembling the MPEG stream...
  
Line 77: Line 94:
 
--[[User:Martinh|Martinh]]
 
--[[User:Martinh|Martinh]]
  
*'''VLC intergration'''  
+
* HTTP support for IPTV. Currently the IPTV feature only supports UDP and RTP streams. I have an IPTV provider that uses HTTP. The streams are indeed MPEG-TS compliant as I can access them with TSReader and it displays the various tables and pids.
 +
** Can you verify it's a TS over HTTP and not TS over RTSP over HTTP? (I can't find a reference for that anywhere) If it's MPEG over HTTP take a peek at {{Ticket|5928}} to see how to add a new protocol to the IPTV feeder. --[[User:Dekarl|Dekarl]] 16:12, 29 March 2010 (UTC)
 +
*** I believe it's TS over HTTP as VLC and mplayer were unable to connect when I switched stream URL to RTSP. Is there any reccomended test to be 100% sure if it's one or the other? (i.e. running vlc or mplayer on verbose and looking for a specific message in the output) --[[User:Kyl416|kyl416]] 22:10, 30 March 2010 (UTC) Let me see if i can find their test server
 +
*** Looking at that code in {{Ticket|5928}}, that's more for taking a regular MP3 stream from an icecast/shoutcast server and repackaging it into a MPEG-TS compliant stream with a PAT, PMT, etc. This doesn't apply to my situation as the IPTV provider is already delivering the streams with the MPEG-TS tables. I'm pretty much a novice when it comes to coding from scratch. I'll take a look at the existing iptvfeeder___ files to see if I can come up with something.--[[User:Kyl416|kyl416]] 00:07, 31 March 2010 (UTC)
 +
* Possible improvement to the IPTV function to also enable the ability to decode all internet based live streams so you can insert them into the EPG as if they were a regular channel, and not just limit it to available streams from your ISP's IPTV service. (i.e. Windows Media, Real, etc)
 +
* Allow a UPnP source to be an input. Needs to allow for quick download and live TV download. eg: file is being transcoded live and will transfer at live speed only. --[[User:TheRockApe|TheRockApe]] 02:34, 23 July 2010 (UTC)
 +
* Add support for [http://bestrussiantv.com BestRussianTV IPTV] <[http://www.iptv-distribution.net/cas_documentation/Content%20Access%20Service_Description_Users.doc API Documentation]>.  Format appears to be RTSP, but requires 'priming' by talking to an HTTP server to enable the stream.  Control server also provides EPG data, which could be used by an XMLTV grabber. If anyone will need authentication information, i might be able to provide it just e-mail me.--[[User:Krutoileshii|Krutoileshii]] 21:45, 24 December 2010 (UTC)
 +
* Add support for PPStream to enable watching chinese programs from www.ppstream.com. Possible check http://www.pps.tv/about/6/364.html, or http://code.google.com/p/totem-pps/, or http://code.google.com/p/gmlive/
 +
* provide arbitrary encapsulation of ANY UNIX application started fullscreen inside of a VNC session and assign to a Channel - I.E - start a vnc session with xterm in fullscreen, assign to channel 100, start xchat logging into #mythtv-users and assign to channel 101, etc. 
 +
** VLC can be used to capture from a Screen input, and stream back over RTSP, which can then be captured by MythTV [[User:Wagnerrp|wagnerrp]] 20:05, 14 July 2009 (UTC)
 +
* Allow a single tuner to record multiple streams of a single channel, allowing for overlap. This is already possible for digital tuner through multirec, but not for analog or firewire capture.
 +
* Enable slave DVB card: This card "free rides" on the pass through satellite signal from a master DVB card. The slave is bound to the DiseqC (Band, polarity, position) of the master DVB card but is freely able (encouraged?) to use another frequency in that band. This will enable the backend to more fully utilize the signal from a single cable to the dish. I am not sure about the effects on the scheduler. [[User:Brennelv|Brennelv]] 16 November 2011 (UTC)
  
1. The ability for VLC to be integrated into the mythbackend. So that each turner card can be locked to individual channel and streamed to the mythfrontends.
+
===Output Streams - UPnP/Multicast/MythProto===
 
+
* Build and serve chapter breakpoints to match commercial skipping endpoints, using byte offsets and the OFF= uPnP parameter.
2. The mythfrontends can connect to each stream as if it were a regular channel and have      all of the guide and channel info
+
:: A solution is currently in the works to use m3u playlists to offer the same behavior.
 
+
* Add recording date to upnpcdstv.cpp and change Title sort to recording date to provide a better indication of watching order of episodes (especially on the PS3).
3. The ability to be able to specify tuners just for recording.
+
:: I've submitted a pull request on Github that should fulfill this requirement (and a slight expansion) https://github.com/MythTV/mythtv/pull/19This may or may not be accepted but it is a simple change to a single file if you are comfortable rebuilding yourself.
 
+
* 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.
4. Also to be able to stream and play DVDs stored on the mythbackend and music on the frontend using VLC like a VOD.
+
* Not sure if it is a client (Sony TV) bug but at the moment if I start watching a program while it is still recording I cannot watch past the point that was being recorded when I started watching. It would be nice if chasing playback could be supported. If it is a client bug I suspect it may be a common one and it may be worth lying to the client in some way. The challenge may be proper handling of requests past the current recording point (fast forward or skip).
* Doesn't mythfrontend already act like this?  Why do you have to bring in VLC, there's not much of a gained benefit from this. Best choice would be to leave it as is unless you have a rebuttal?
+
* More music browsing options: I don't know if this is possible, but if you have a huge library, it can take ages to scroll to the item you want on a device. Perhaps they can be organized into sub-folders based on letters?
 
+
* add support for the backend to indentify itself to Apple's FrontRow App as a computer on the network with media available (basically tricking FrontRow into thinking that the backend is another apple computer with shared media) -- Do you mean like Firefly [http://www.fireflymediaserver.org/]?
===Output Streams - DivX/MPEG/Other===
+
** Does FrontRow not work with the existing UPnP server? [[User:Wagnerrp|wagnerrp]] 20:59, 3 November 2009 (UTC)
* The ability to encode in DVR-MS format.  My logic behind this it for MCE and MythTV to coexist. XBOX 360's could then be used as front ends for MythTV recordings.  Since DVR-MS is just wrapped MPEG2 this shouldn't be that hard, I would think.
 
* Keep DVB subtitles, both when transcoding and when storing recordings to DVD with mytharchive. Can be done manually with projectX, ifoedit (windows only) and a lot of wasted time see [http://www.digitv-forum.co.uk/viewtopic.php?t=371 here] and [http://linvdr.org/mailinglists/vdr/2005/01/msg00263.html here].
 
* [http://svn.mythtv.org/trac/ticket/637 Use Matroska (*.mkv) in mtd.] Matroska is an envelope for which there can be many audio, video and subtitles streams, allowing the user to store a complete movie or CD in a single file.
 
* Provide a transcode to divx or xvid while recording option. Save a ringbuffer that is transcoded to divx and store in database as a TV Recording after processing to divx
 
* After an initial transcode from mpeg2 to mpeg4, I would like to be able to do a mega-sqeeze using nuvexport for archival purposes but still keep the file in mythtv records -- not in videos. Can .nuv be used as a container for xvid? I.E. initial PVR250 recording for an hour takes up 2gb. Transcode to mpeg4 brings this down to 1gb. Nuvexport "transcode" to xvid brings it down to ~400mb and keeps the recording and program info in mythtv.
 
* Perform intelligent upconverting of Dolby ProLogic Surround Sound (inside MP3/2.0, AC3 2.0 etc.) to discrete 5.1 channels.  This is to assist those TV stations (very common in Australia) that broadcast only a two channel sound stream but this sound stream is Dolby ProLogic encoded. By upconverting to discrete channels, the user no longer needs to change the mode of their surround sound/dolby digital amplifier to force decoding of Dolby Prologic.  Similarly, when they want to listen to music (2 channels) they do not need to change their amplifier back from dolby prologic back to a stereo mode.  They just leave their amplifier on automatic detection and, with SPDIF, it will output on just the channels it needs to do so.  See http://matrix-mixer.sourceforge.net/ for an open source solution in this area.
 
* The ability to mark channels as "radio" channels, and for these channels record only the audio stream. ''(submitter's note: I've started having a bit of a go myself, but progress is quite slow as I'm unfamiliar with the code.)'' Recordings could then be  cut into songs and transferred to [[MythMusic]].
 
 
 
=== Parental controls / User permissions ===
 
 
 
* A separate page for [[Parental Controls]] has been created, using some of these ideas. '''Your ideas are welcome'''.
 
* Ablilty to have a required log-on for all frontends with a unique ID and pass after registering. Some features would include limmiting number of shows someone can record per week, giving users who are currently watching TV priority, aka locking the channel, to prevent other users from messing up the recording, most of the parental controls from above included, and the log of each user and their activity. Also the ablility to download the shows to the frontend to limit stress on server.  
 
* [http://gossamer-threads.com/lists/mythtv/dev/5680 Channel lock],or just 'lock'. ''Users can receive a warning when attempting to change the channel while not caught up to real time, so the original purpose behind this is moot.''. Might (still) be handy for parents with little kids.
 
* Add ability for mythtv to log all shows watched (live or recorded) during a day and store in a unique log file per day to store tv watching history. Add ability to put parental controls on mythtv to only allow a given number of hours of tv watching during the day, only allow certain channels during certain times on certain days of the week.
 
* How about a feature that would allow you to 'markup' DVD's to skip unwanted scenes for parental control or even look at the subtitles and mute when there are bad words? ''DVD subtitles are images, so that last part would require significant OCR'ing...''
 
:* Add [http://www.clearplay.com ClearPlay]-like content filtering, not just identification, to MythTV.  See the [[Parental Controls]] page for a (much) longer description of what I have in mind.
 
* The ability to lock out specific frontends from specific channels (still tuneable, just not watchable. 4-digit PIN code to override). Maybe you have one frontend in the living room, one in the bedroom and one in the kids' room. It would be nice to be able to only send Cartoon Network, etc. into the kids' room while sending Playboy TV, etc. only to the bedroom... I imagine setting up a "standard package" and then registering the frontends somehow and customizing their channels. I guess this sounds awfully broadcasterish, which is not the original intention, but apparently a positive side-effect ;-)
 
  
 
=== Intelligent Scheduling===
 
=== Intelligent Scheduling===
 
* Recognize subtle changes in the scheduled recording description so that they don't break the schedule. Some examples:
 
* Recognize subtle changes in the scheduled recording description so that they don't break the schedule. Some examples:
 
** The tv_grab_au grabber found a program called "Doctor Who", episode "Smith And Jones" that runs 7:30pm - 8:15pm. The EIT scan updated this to a show called "Doctor Who: Smith And Jones", with no episode name, that runs 7:32pm - 8:18pm. A scheduled recording based on the first description should still record - however the recording actually does not happen.
 
** The tv_grab_au grabber found a program called "Doctor Who", episode "Smith And Jones" that runs 7:30pm - 8:15pm. The EIT scan updated this to a show called "Doctor Who: Smith And Jones", with no episode name, that runs 7:32pm - 8:18pm. A scheduled recording based on the first description should still record - however the recording actually does not happen.
 +
*** At the risk of confusing bugs, feature requests and philosophical reflections; EIT updates should supersede old data.  If there is a 90% overlap of time then it is probably an update and the new data should be used instead of the old data.  The actual heuristic used could be quite "interesting" and it might be desirable to flag any updated items to request human confirmation.  If the heuristic is totally confused by the update (say it is in a different language) it should give up, use the old data, and request human intervention.  In the Dr. Who example above one possible response would be to record "unknown" from the earlier start time to the later end time, 7:30-8:18.
 
** There is a program that the tv_grab_au grabber sometimes calls the regular evening news "ABC News" and sometimes calls it "ABC News Update". They are on the same channel at the same time and it would be great to be able to use wild cards (or something) so that they are always recorded.
 
** There is a program that the tv_grab_au grabber sometimes calls the regular evening news "ABC News" and sometimes calls it "ABC News Update". They are on the same channel at the same time and it would be great to be able to use wild cards (or something) so that they are always recorded.
 +
** Wild cards/regex in general would be nice.  Often main titles are messed with:  "Revenge (new episode)", or "Revenge (* SNEAK PEAK Masterchef blah *)" or "Season Final: / Finale" prefixes/suffixes are added.  Oz TV is also fond of changing weekly times so you can't rely on it being close to the timeslot you expect.
 +
** Some channels (e.g. Finnish YLE), do minor time corrections to EIT data days/hours before the show starts. E.g. 21:00:00-21:50:00 is updated to 21:00:19-21:50:19. This causes a normal scheduled recording to break since the specified show title can't be found at exactly the same time anymore. Could there be a threshold of a few minutes to avoid this?
 +
::: Can be done with a Custom Record
 +
*** Are you sure that current behavior is not a bug?  Either accept the update and use those times or ignore the update and record original times.  Don't cancel the recording.
 
** I have occasionally seen misspellings of program names that would lead to schedules failing to record when the mistake is corrected.
 
** I have occasionally seen misspellings of program names that would lead to schedules failing to record when the mistake is corrected.
 
** If the start and end times remain the same (or even approximately the same?), should perhaps keep the recording scheduled regardless of changes in the title. Similarity match might not always work (there's also the case of e.g. title changing from one language to another), and recording something unnecessarily is usually much less harmful than failing to record something that the user wanted.
 
** If the start and end times remain the same (or even approximately the same?), should perhaps keep the recording scheduled regardless of changes in the title. Similarity match might not always work (there's also the case of e.g. title changing from one language to another), and recording something unnecessarily is usually much less harmful than failing to record something that the user wanted.
Line 116: Line 132:
 
* Have 2 scheduling profiles for 1 show. example one profile for new episodes of family guy and another profile for re-runs of family guy.  This could be accomplished by an option to increase the priority for new episodes, or decrease the priority of repeats, and by adding a "Number of Repeats to keep" option along with the "Number of episodes to keep".  
 
* Have 2 scheduling profiles for 1 show. example one profile for new episodes of family guy and another profile for re-runs of family guy.  This could be accomplished by an option to increase the priority for new episodes, or decrease the priority of repeats, and by adding a "Number of Repeats to keep" option along with the "Number of episodes to keep".  
 
* MythWelcome - will set the next wakeup time to be the lesser of the next scheduled recording and the next time to run mythfilldatabase as suggested by the grabber
 
* MythWelcome - will set the next wakeup time to be the lesser of the next scheduled recording and the next time to run mythfilldatabase as suggested by the grabber
* [http://gossamer-threads.com/lists/mythtv/dev/1850 Recording suggestions], [http://www.gossamer-threads.com/lists/mythtv/users/25779 2], [http://gossamer-threads.com/lists/mythtv/dev/gforum.cgi?do=post_view_flat;post=7175;list=mythtv#7178 3]}, á la TiVo
 
 
* More precise time offset for guide listings (My clock is spot on using NTP, but my provider's clock seems fast by 30-60 seconds). Or, allow "End Late" to be a negative value, could be used in combination with "Start Early" to accomplish same goal. This could also be used to compensate for any scheduler "lag".
 
* More precise time offset for guide listings (My clock is spot on using NTP, but my provider's clock seems fast by 30-60 seconds). Or, allow "End Late" to be a negative value, could be used in combination with "Start Early" to accomplish same goal. This could also be used to compensate for any scheduler "lag".
** In DVB systems, the system time is broadcast in the system time table (STT) (see http://www.interactivetvweb.org/tutorial/dtv-intro/atsc-si/mgt-stt.shtml) and this could be used to determine the offset. I would suggest that the MythTV system should have its time set using NTP, and then establish a time offset for each channel, scanned from the STT. In the ideal world, all of the offsets would turn out to be zero, however the stations seem to get this wrong sometimes.
+
:: 'Start Early' and 'End Late' can be negative values, with the expected behavior.
* Speculatively record shows that the user *might* want to watch, even though the user hasn't manually asked for them. (But, of course, never let these take priority over shows the user says he definitely *does* want to be recorded). See http://www.templetons.com/brad/myth/tvwish.html
+
:: In DVB systems, the system time is broadcast in the system time table (STT) (see http://www.interactivetvweb.org/tutorial/dtv-intro/atsc-si/mgt-stt.shtml) and this could be used to determine the offset. I would suggest that the MythTV system should have its time set using NTP, and then establish a time offset for each channel, scanned from the STT. In the ideal world, all of the offsets would turn out to be zero, however the stations seem to get this wrong sometimes.
* Use Bayesian prediction (just like SpamAssassin) to get better at predicting which shows the user *might* want to watch. See http://www.whynot.net/view_idea?id=1236  (Update: perhaps this could apply to Recording Suggestions above?) - This was already semi-implemented, see http://www.nexusuk.org/projects/mythtv/mythbayes/ (would need updating and a UI).  Note that this was only moderately successful - a last.fm style recommendations engine would be better.
 
* Have mythfilldatabase grab the additional "cast" data and insert it into the database, allowing searches for favorite actors or directors
 
 
* Allow selection on additional fields, e.g. only record a movie if it's being broadcast in widescreen.
 
* Allow selection on additional fields, e.g. only record a movie if it's being broadcast in widescreen.
* Conflict resolution: if two shows overlap a few minutes, don't NOT record one of them, but cut the minutes from the first or second show. (Here here!!!)
 
** If two shows on the same channel overlap a few minutes, stream to two files during the overlap period.  Then neither show will get cut off.  Really useful in regions where the broadcasters slip the schedule a lot.
 
* Ability to save the stream from a single capture card to more than one file, and awareness of this capability by the scheduler.  This would allow scheduling two "overlapping" recordings (because one or both had a preroll or postroll, and they aired consecutively on the same channel) to each have their prerolls and postrolls preserved, without requiring using a second tuner just because there was an overlap of a few minutes.  This potentially doubles traffic to the disk during that interval, but disk bandwidth is relatively cheap, and adding extra tuners to deal with this problem is not (and maybe even be impossible for machines with few PCI slots). [Consider especially the case of an episode marathon, all of which will eventually get saved to DVD.  Without prerolling/postrolling, any scheduling offset is guaranteed to chop off the beginning/end of each episode if there's the slightest clock skew, the missing pieces may wind up on different DVDs, and there may ''still'' be missing pieces due to the dropped seconds while the tuner reinitializes itself at the beginning of each capture.  Avoiding this with pre/postrolls currently doubles the number of tuners required, but writing the overlap intervals simultaneously would not.] This would be of significant benefit in Australia, where pretty much everything starts/ends many minutes early/late (5-10 minutes is quite common). (There is a basic implementation of this at Ticket: http://svn.mythtv.org/trac/ticket/1772) [[http://www.gossamer-threads.com/lists/mythtv/users/164427 1], [http://www.gossamer-threads.com/lists/mythtv/users/135511 2], [http://www.gossamer-threads.com/lists/mythtv/users/130207 3], [http://www.gossamer-threads.com/lists/mythtv/users/128968 4], [http://www.gossamer-threads.com/lists/mythtv/dev/12884 5]].
 
** I think the clean way to do this is to separate the concept of shows from disk files. There are various ways to do this, but deleting shows could get tricky. Instead of the database record for a show containing a file name, it should keep a list of filenames. The input stream needs to be split into seperate files whenever the shows referring to the stream changes. Consider shows A, B and C all overlapping on the same stream; this would produce 5 files containing A, (A^B), B, (B^C), and C. If B is very short you could even end up with files containing A, (A^B), (A^B^C), (B^C), and C. It might be best to keep a reference count to make it easier to know when a file can be deleted because there are no more shows referencing it.
 
* The last two points would really really really help Australians out!!!!!!!!!!!!!
 
* Those two points for conflict resolution are essential for any pvr.  Never owned a TiVo to tell, but SageTV has a simple solution for the issue, which is the base that MythTV should adopt.
 
** The resolution would help anyone interested in recording double header basketball games on TNTP or ESPN.  Or more generally any possible consecutive shows which have "sometimes slipping" ending time.  The first thing you'd do for slipping endings would be to end the recording later according to your needs.
 
** As for implementation, there is apparently no practical need to the suggested A^B^C or other logic.  If two such recordings are 17:00-19:30 and 19:30-22:00 for instance, all one need to do is define the end-later once as needed, say 1:30 hours.  Then the first one will end on time, since there is a consecutive show which already covers for the first one including the end late rule.  The second will end late as needed.  You can check SageTV, it works as expected and is natural and usable.  No need for two tuners.  Anything more than that would likely be more complex than needed from the usability perspective.
 
 
* Record/don't record on certain channels. Add the ability to have a channel include/exclude list that lets the scheduler consider certain channels or bars it from considering certain channels. This will allow me to record Lost on any FOX affiliate, but keep MythTV from mistaking the Lost reality show on FOX Reality for the drama series.
 
* Record/don't record on certain channels. Add the ability to have a channel include/exclude list that lets the scheduler consider certain channels or bars it from considering certain channels. This will allow me to record Lost on any FOX affiliate, but keep MythTV from mistaking the Lost reality show on FOX Reality for the drama series.
 
:Under ''mythtv-setup'' you can assign priorities for channels and out-right remove them. For example, I have two ABC affiliates and I prefer to record form WABC vs. the local, so I have WABC higher priority.
 
:Under ''mythtv-setup'' you can assign priorities for channels and out-right remove them. For example, I have two ABC affiliates and I prefer to record form WABC vs. the local, so I have WABC higher priority.
* Allow backend to change tuner selection for recording on the fly if a user is watching live TV. (I have three tuner cards, and while I'm watching live TV, the backend often takes over the tuner I'm using, despite two other tuners being available.) <This is available "Utilities/Setup -> Setup -> General -> Avoid conflicts between live TV and scheduled shows">
+
* Allow backend to change tuner selection for recording on the fly if a user is watching live TV. (I have three tuner cards, and while I'm watching live TV, the backend often takes over the tuner I'm using, despite two other tuners being available.)
 +
::This is available "Utilities/Setup -> Setup -> General -> Avoid conflicts between live TV and scheduled shows"
 
* ''Partial recordings'' flag &mdash; my gf loves American Idol, but I want to record a 30 min show during its two hour show. So, I want MythTV to record the first 60 min then stop and record the last 30 min (she just wants as much as possible). - This would be helpful during long televised events such as the olympics, when the TV schedule just has one long show that lasts 8 hours.
 
* ''Partial recordings'' flag &mdash; my gf loves American Idol, but I want to record a 30 min show during its two hour show. So, I want MythTV to record the first 60 min then stop and record the last 30 min (she just wants as much as possible). - This would be helpful during long televised events such as the olympics, when the TV schedule just has one long show that lasts 8 hours.
* email notification when Recording conflict (might as well include the option for AIM/Jabber notifications )
+
** Since it is well known that not all programs are of the all-or-nothing type, current behavior of not recording parts of a program when a tuner is idle is a bugIf a program is an all-or-nothing type you would give it a high priorityAs a real feature request, introduce a flag for all-or-nothing and mark partial programs as incomplete.
** This email may also contain a link to the web server where a page displaying a number of options is shown. It should from there be possible to solve the conflict by doing something smart like:
 
*** Removing one of the scheduled recordings
 
*** Shorten one of the scheduled recordings and accept that parts of one of the shows are missing
 
*** Rearrange the current list of priorities and save for future use (if the situation reoccurs next week or something)
 
* Add option to limit the time length or filesize of recordingsLong length MythTV recordings would automatically span multiple files similar to film rollsAllows TV marathons, sporting events, etc to be broken up into manageable pieces.
 
 
* Add support for "idle priority" recordings.  This is perhaps a way to minimize channel change time in LiveTV.  Unused cards in the BE could be tuned and recording preset channel(s) in case of a channel change.  These recordings can be overridden by any scheduled recording, unless the user presses "R" to record them.  Naturally, these recordings will be auto-expired preferentially.  The channels that are being recorded can be changed to follow the users channel surfing habit.  Combined with the multiple channels from single multiplex idea this could generate seamless channel surfing.
 
* Add support for "idle priority" recordings.  This is perhaps a way to minimize channel change time in LiveTV.  Unused cards in the BE could be tuned and recording preset channel(s) in case of a channel change.  These recordings can be overridden by any scheduled recording, unless the user presses "R" to record them.  Naturally, these recordings will be auto-expired preferentially.  The channels that are being recorded can be changed to follow the users channel surfing habit.  Combined with the multiple channels from single multiplex idea this could generate seamless channel surfing.
* Ability to use syndicatedepisodenumber to identify duplicates. The current "subtitle and description" method is only useful when the programmer provides adequately unique data for each episode. (Excellent example of failing to do so: X-Play.)
 
* Ability to subscribe to a program and capture each unique episode once. The current "find one showing daily/weekly" method doesn't always work when there are multiple time slots each day/week that show current and past episodes. The current "record in this timeslot each day/week" doesn't always work if the profgram tends to float around in the channel's schedule, it can also introduce conflicts that could be easily worked around if the scheduler recognized that it could get this episode tomorrow in the early morning instead of tonight. Combined with the above request for syndication episode number as a duplicate detection method this could be close to the "Season Pass" feature of other PVRs. (Excellent examples of where this would be useful: X-Play, Mythbusters, Good Eats)
 
** The feature you're describing seems to be the same as selecting "Record this program at any time on (this channel / any channel)" and setting it to not record duplicates. Could you clarify what you're looking for that this doesn't provide? (I watch MythBusters and Good Eats all the time, and it just records each episode once, so I don't see what the problem is.)
 
** Not Recording duplicates only works if the schedule is correct.  Often some shows just have a default or unspecified episode and the scheduler will record these.  I would like to see a modification of commercial flagging that would identify if the episode has been recorded before.  --[[User:Bryanc806|Bryanc806]] 03:58, 21 November 2007 (UTC) Incredibly difficult, I can't imagine anyone being able to do this. --[[User:Turpie|Turpie]] 01:36, 22 November 2007 (UTC)
 
* Auto overlap - allow a few minutes after the end of a recording to be recorded unless there is another recording scheduled (to prevent end of movies being missed if time is slightly off) -- '''Already in Mythtv''' --[[User:GBee|GBee]] 18:59, 28 January 2007 (UTC)
 
 
* Bring back some version of the "don't record if less that X MB free on drive" feature. I realize this has effects on LiveTV, but some people rarely use LiveTV and expiring one episode of a show in long-running syndication to record another seems unnecessary. Not recording already watched episodes solves this issue in the long run, but not until many many episodes have been watched. Could this be done in conjunction with some sort of limitation on LiveTV (a box that pops up telling you to restart your LiveTV watching to clear the buffer or something) to prevent the problems that caused this feature to be removed in the first place?
 
* Bring back some version of the "don't record if less that X MB free on drive" feature. I realize this has effects on LiveTV, but some people rarely use LiveTV and expiring one episode of a show in long-running syndication to record another seems unnecessary. Not recording already watched episodes solves this issue in the long run, but not until many many episodes have been watched. Could this be done in conjunction with some sort of limitation on LiveTV (a box that pops up telling you to restart your LiveTV watching to clear the buffer or something) to prevent the problems that caused this feature to be removed in the first place?
*Allow "save until next airing" for recordings.  Sometimes I record a show, and I'd like to keep a copy, but for some reason, the recording is sub-optimal (signal quality was bad, got truncated, etc.), so I'd like to re-record it next time it airs.
+
:: Don't allow auto-expiration, and your recordings will not be automatically deleted.
* Add the ability to download audio and video podcasts.  They should be then viewable in MythMusic and MythVideo.
+
:: LiveTV is chopped up at each show boundary. Just make sure you have enough free space for the longest show you may want to watch live.
* Add the ability to set a default number of minutes to record past the end of a show, per channel. In my region, the commercial channels regularly run their shows up to 20 minutes past the advertised time (even past the time broadcast in the EIT), while the non-commercial channels will have schedules that are accurate to the minute.
 
 
* Create "Channel Groups" - in the UK new episodes of shows are often shown with repeats on a set of channels (e.g. Sky One and Sky two) and episodes from old seasons are on other channels.  It would be good to be able to create channel groups like "Sky one, sky two, sky three" and say "record at any time in group "Sky".  This would also work for the "+1 hour" channels.  Currently I record programs like this through a manual schedule.
 
* Create "Channel Groups" - in the UK new episodes of shows are often shown with repeats on a set of channels (e.g. Sky One and Sky two) and episodes from old seasons are on other channels.  It would be good to be able to create channel groups like "Sky one, sky two, sky three" and say "record at any time in group "Sky".  This would also work for the "+1 hour" channels.  Currently I record programs like this through a manual schedule.
 
* Generic episodes that air at the same time should only record once.
 
* Generic episodes that air at the same time should only record once.
 
** I record The Simpsons which doesn't always have specific show information. I want to record even the generic episodes, but when they are generic, I always get 2 copies. One from my SD channel (44) and one on my HD channel (44.1). The scheduler should be smart enough to know that if the show is generic and on at the same time as another generic episode, then it's likely the same episode even though the xmltv id's aren't exactly the same.
 
** I record The Simpsons which doesn't always have specific show information. I want to record even the generic episodes, but when they are generic, I always get 2 copies. One from my SD channel (44) and one on my HD channel (44.1). The scheduler should be smart enough to know that if the show is generic and on at the same time as another generic episode, then it's likely the same episode even though the xmltv id's aren't exactly the same.
 
* 'Already in Progress'.  An option on the recording schedule to record a program already in progress if it has been pre-empted by a higher priority program.  For example, long sporting events (golf tournaments, endurance racing) where the broadcast might be several hours long.  A 30-minute program in the middle of the sporting event would be recorded and then recording of the longer program would resume.
 
* 'Already in Progress'.  An option on the recording schedule to record a program already in progress if it has been pre-empted by a higher priority program.  For example, long sporting events (golf tournaments, endurance racing) where the broadcast might be several hours long.  A 30-minute program in the middle of the sporting event would be recorded and then recording of the longer program would resume.
 +
** This is the same a "partial recordings" above.
 
* Record all parts of a split programme. Channel Five in the UK frequently show films with a short news programme in the middle, this splits the film into two parts with a short gap between the two. Currently I have to book both parts of the film in order to get the whole thing and it appears as two separate recordings in the recordings list. I have on occasion nearly missed the first or second half because I hadn't noticed it was split at the time I originally booked it. It would be useful if Myth recognised where programmes are split like this and all parts automatically recorded instead of just the part that was booked. It would also be good if programmes recorded like this were stitched back together into a single recording to watch back.
 
* Record all parts of a split programme. Channel Five in the UK frequently show films with a short news programme in the middle, this splits the film into two parts with a short gap between the two. Currently I have to book both parts of the film in order to get the whole thing and it appears as two separate recordings in the recordings list. I have on occasion nearly missed the first or second half because I hadn't noticed it was split at the time I originally booked it. It would be useful if Myth recognised where programmes are split like this and all parts automatically recorded instead of just the part that was booked. It would also be good if programmes recorded like this were stitched back together into a single recording to watch back.
 +
:: If the shows show up as repeats, your guide information is broken.
 +
* Allow scheduling of arbitrary applications. You might think I could do this with cron, but cron wont turn the computer on to run the application if it is currently off. I use my computer as a front end, back end, and a desktop. I have it set up to automatically power on & off for recordings, and can manually turn it on to use as a desktop (it checks for logged in users and won't shut down when someone is logged in) I'd like to be able to schedule automatic backups of my files, but to do that with cron would require leaving my computer on all the time.
 +
** See [http://anacron.sourceforge.net/ anacron].
 +
*** anacron will not do what I want. anacron guarantees that the backup would run at the most inconvenient time possible (when I turn on the computer to use it, or when the computer turns on to do a recording) I want the computer to turn on by itself at a time when I'm sure nothing else will be happening to execute a backup that is going to tie up my disk drives for a significant amount of time. There is only one wake timer in the system. It is being used by MythTV. There is currently no mechanism to allow other things to wake the computer.
 +
* Generalize and separate the shutdown and RTC alarm from MythTV backend, and merge it with cron. This is probably much more difficult to do than the above, but would solve the above problem, and allow automated power on & off for systems that don't run MythTV.
 +
** Already possible. Disable [[ACPI Wakeup#Integrate into mythTV|RTC alarm]] support in mythtv, and change the shutdown command in mythtv-setup to a script of your own design. Have this external script pull the time of next recording from mythtv, as well as the time of any other external scheduled items, and set the alarm accordingly before shutting down.
 +
*** A crude hack that works for one event once per day can be found at: [[Using ACPI & MythTV to run other applications]]
 +
* Ability to mark recording as previously recorded. This would be useful in a few situations. I.E. Recently i rebuilt my system from scratch not using any of my backups because the i was going from a distro that had a few major version jumps since my version. When i set up recordings for my favorite series, i usually use any/any. The problem with that, is that on some week nights, and weekends the cable provider will run marathons. Which will flood the upcoming recordings screen with episodes i have already seen.
 +
* Ability to automatically remove/disable recording schedules after a user-specified period of time. E.g. I want to record a mini-series in three parts, so I set a recurring schedule for that title. What usually ends up happening is that I forget about the schedule and end up having it in my recording schedule for many many years, which leaves me with a very cluttered schedule.
 +
* If all else is the same, give priority to the showing that runs longest. I'm noticing this with the upcoming State of the Union - I prefer to watch the news channel that has longer coverage.
 +
* Allow lead in and lead out times to have a lower priority than the main program.  Then consecutive programs can be recorded by the same tuner.
 +
* In the spanish DVB-T (probably in other countries too), now and then, some providers change their EPG data to "unknown" for untold reasons although they keep their previously set schedules. It would be nice the scheduler would keep its record schedule time (and program title and subtitle) when the timeslot EPG data is reset to "unknown" by the provider (and offer this behavior as an user option).
 +
 +
==== Suggested Recordings ====
 +
* [http://gossamer-threads.com/lists/mythtv/dev/1850 Recording suggestions], [http://www.gossamer-threads.com/lists/mythtv/users/25779 2], [http://gossamer-threads.com/lists/mythtv/dev/gforum.cgi?do=post_view_flat;post=7175;list=mythtv#7178 3]}, á la TiVo
 +
* Speculatively record shows that the user *might* want to watch, even though the user hasn't manually asked for them. (But, of course, never let these take priority over shows the user says he definitely *does* want to be recorded). See http://www.templetons.com/brad/myth/tvwish.html
 +
* Use Bayesian prediction (just like SpamAssassin) to get better at predicting which shows the user *might* want to watch. See http://www.whynot.net/view_idea?id=1236  (Update: perhaps this could apply to Recording Suggestions above?) - This was already semi-implemented, see http://www.nexusuk.org/projects/mythtv/mythbayes/ (would need updating and a UI).  Note that this was only moderately successful - a last.fm style recommendations engine would be better.
 +
* More robust recording: When MythTV failes to start a recording, it should retry a few times - instead of hanging. It's better to just lose 1% of a show then 100% !
 +
* Subscribe to someone's recommended settings for recordings: Someone else is interested in the same shows and programs as you are. Why not let her recommend them in a way that would let you import the settings manually or even automatically? A format for a blog/wiki would be handy and some way for the backend to poll for new entries would be needed.
  
 
===Commercial Detection===
 
===Commercial Detection===
Line 162: Line 177:
 
* Configurable "max_commercial_length", override recordedmarkup and skip max_commercial_length where appropriate. (sometimes I hit skip and jump 13 minutes, etc).
 
* Configurable "max_commercial_length", override recordedmarkup and skip max_commercial_length where appropriate. (sometimes I hit skip and jump 13 minutes, etc).
 
* Commercial flagging profiles:  A US broadcast TV show often uses the same basic commercial layout for all episodes.  Knowing that the show will have 5 commercial breaks, of durations "3min,3min,5min,3min,3min" with gaps of no less than 6 minutes between them, could be used to optimize flagging.
 
* Commercial flagging profiles:  A US broadcast TV show often uses the same basic commercial layout for all episodes.  Knowing that the show will have 5 commercial breaks, of durations "3min,3min,5min,3min,3min" with gaps of no less than 6 minutes between them, could be used to optimize flagging.
* Commercial flag sharing:  mythcommflag is replicating the same work on many devices.  If I'm scanning "Lost" for commercials, it would be nice if others could benefit from that and greatly decrease the work needed to be done on other systems recording the same show.
 
** One possible technique: calculate a hash value for every frame, or perhaps each block.  Trade these block hash value on a centralized server, or better yet, a distributed system with many, many "feeder nodes."
 
** The hard part: determine the hash value in a graceful way such that two frames, while not bit-wise identical due to noise and reception differences, nevertheless hash out to the same or very close values.  Use a scoring system to decide when the two hash values are actually identical.
 
** If the hash calculation technique is very quick, then low processing power clients will be able to process commercials.
 
** The feeder nodes concept is just a way of keeping something like this from being shutdown easily.  A feeder node would publish a webpage with a link to its IP address.  The feeder node would then give out the ip address of a dozen other nodes that the user could contact.  The feeder nodes could be found through a google search looking for a distinguishable word.
 
** I'd like to emphasize that these aren't done on a per-show basis, as the original poster suggested.  Rather, they're done on a block basis.  Reason: the same commercials are used over and over on different channels, different shows, different times.
 
* Separate the "engine" of mythcommflag from the part that interfaces to MythTV.  I'd like to be able to use mythcommflag as a completely stand-alone application, able to be run against any random video I happen to come across.  This engine should output a simple textual list of commercial boundaries.  A wrapper process should take that data and format it for MythTV's use.  (Ideally, the  textual output from the core engine should be pipe-able directly into ffmpeg, but I suppose I'll have to take that feature request up with the ffmpeg team...)
 
 
* Ability to specify that cuts should exclude N seconds of the commercial (so that the viewer can tell that that a commercial was cut correctly.)
 
* Ability to specify that cuts should exclude N seconds of the commercial (so that the viewer can tell that that a commercial was cut correctly.)
* Ability to block the crawls, bugs, and show promo pop-ups that interfere with viewing the show.
 
 
* For US user's, use the black/white TV rating in the corner of a recording to help detect when a show starts again.  (Often times an explosion about 20-120 seconds before/after the commercials is used as the skip point as the entire screen goes white.)
 
* For US user's, use the black/white TV rating in the corner of a recording to help detect when a show starts again.  (Often times an explosion about 20-120 seconds before/after the commercials is used as the skip point as the entire screen goes white.)
* If frontend & backend are on the same box, commflagging while watching may overpower some machines.  An option to stop background commflagging while watching any video would be nice.
 
 
* Using stream information for commercial flagging. There are often discontinuities in DVB streams when commercials begin or end - aspect ratio or audio channels may change, or (not sure about this) possibly different streams can be detected even when these remain the same. Commflagging could be much faster (and fast enough to do online flagging during LiveTV), and also more accurate, if this information could be made available to it. The same info could also be used to detect program start and end, and auto-shift or extend recordings accordingly.
 
* Using stream information for commercial flagging. There are often discontinuities in DVB streams when commercials begin or end - aspect ratio or audio channels may change, or (not sure about this) possibly different streams can be detected even when these remain the same. Commflagging could be much faster (and fast enough to do online flagging during LiveTV), and also more accurate, if this information could be made available to it. The same info could also be used to detect program start and end, and auto-shift or extend recordings accordingly.
  
===Transcode Audio Passthrough===
+
===Transcoding===
 +
* The ability to encode in DVR-MS format.  My logic behind this it for MCE and MythTV to coexist.  XBOX 360's could then be used as front ends for MythTV recordings.  Since DVR-MS is just wrapped MPEG2 this shouldn't be that hard, I would think.
 
* In addition to MP3 and uncompressed, there should be an option in the transcoding profile setup screen to allow for straight pass-through.  For AC3 audio streams this will preserve the 5.1 surround data while allowing very large HDTV streams to be substantially reduced in size by converting them to MPEG-4, and possibly lowering their resolution.
 
* In addition to MP3 and uncompressed, there should be an option in the transcoding profile setup screen to allow for straight pass-through.  For AC3 audio streams this will preserve the 5.1 surround data while allowing very large HDTV streams to be substantially reduced in size by converting them to MPEG-4, and possibly lowering their resolution.
 +
* allow a flag on NUVEXPORT or mythtranscode to delete the source recording in mythtv when the transcoding is finished if it is being transcoded to another location for ipod use or other use.  This eliminates the manual deletion of files and allows a family to set transcode functions for family members that watch on an ipod and not clutter up the screen with that persons recordings.
 +
:: Can be done with a script wrapper.
 +
* A crop filter that crops the image to the requested size would be useful. The current crop filter only blacks out the areas requested. This could be used during transcoding to crop 16:9 images back to 4:3 for older material, or to improve bitrates/image quality by removing black edges and their expensive transitions found on most digitally recorded footage. (workaround: a custom job using mencoder and its -vf crop filter.)
 +
::If the crop filter worked like this, I would put crop=1,1,1,1 on all my transcoders.
 +
::: Understand that due to macroblock limitations, you cannot actually crop videos at anything smaller than 8 or 16 pixels, depending on the codec.
 +
* Keep DVB subtitles, both when transcoding and when storing recordings to DVD with mytharchive. Can be done manually with projectX, ifoedit (windows only) and a lot of wasted time see [http://www.digitv-forum.co.uk/viewtopic.php?t=371 here] and [http://linvdr.org/mailinglists/vdr/2005/01/msg00263.html here].
 +
* 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.
 +
* Support for h264 (through libx264)
 +
* Support for handling multiple audio streams
 +
* Support for alternate container formats
 +
* Smarter transcoder profile selection.  Ability to specify the transcoder profile based on various parameters of the video file (resolution, rate, etc).  Similar to the new playback modes selection.  The idea here is that sometimes my system records a program in hi-def because the standard def tuner is in use.  I really don't care about that program being in hi-def and would like to transcode it to a smaller size (resolution and bit-rate), but when the same program is recorded in standard def, I don't want the size changed.
 +
:: Can be done using an external user job running a script to determine how to transcode.
 +
* Transcode MPEG2 to MPEG4 on the fly based on frontend request.  This would allow non-mpeg2/nuv capable devices (tablets, Raspberry Pi) to have a front-end and use their hw acceleration/scaling.  I know post-recording transcode is possible, but it would be nice to be able to watch before the recording is finished and allow searching/skipping.  Given that myth can deal with mpeg4 at the backend natively, it would be great to do this conversion while recording, before the data is written to disk, but I suspect that would be more difficult once you introduce multiplex channels where the number of recordings (workload) is not certain (not 1-to-1 with tuners).
 +
:: The HLS server can be used to transcode content on-the-fly for low capability devices, however this is more intended for external devices rather than internal usage.
 +
* A frontend-backend handshake saying what codecs can be used and if the frontend is fast enough to transcode on its own ("I'm a quad-core arm system, I prefer mpeg4 but I can transcode mpeg2 if the backend is busy")
  
===Transcode delete source recording when done===
+
==JobQueue Addons==
allow a flag on NUVEXPORT or mythtranscode to delete the source recording in mythtv when the transcoding is finished if it is being transcoded to another location for ipod use or other useThis eliminates the manual deletion of files and allows a family to set transcode functions for family members that watch on an ipod and not clutter up the screen with that persons recordings.
+
*More intelligent job queue system/ui for each recorded show, showing jobs as an actual queue instead of just started or stopped (similar to what the system status shows.)  This will make clear what order jobs will run in as well as allow a user to queue a single job twice.
 +
*Give Commerical Flagging jobs priority over Transcoding jobs.
 +
*Give the option to only process one (or some arbitrary number) HD job at a time - 3 HD transcoding jobs can clog up the queue and prevent commercial flagging jobs and faster SD transcoding from occurring for long periods of time.
 +
*Give separate options for number of jobs on a backend for each job type.  For example, I could say a backend can do 2 commercial flagging jobs, 1 transcoding job, and 2 User Job #1s at once.  Maybe replace the "Allow Transcoding Jobs" checkbox with a text field that sets the number allowed?  This would allow better processing distribution across several backends.
 +
*Allow for an arbitrary number of User Jobs (create a userjob table in the database?)
 +
* Jobs repository - A simple way to find and install job scripts - similar to boxee apps without the pretty icons.
 +
:: There is a crude version of this in the Python bindings in trunk, to be released in 0.24.  `mythwikiscripts` will parse specially formatted pages on this wiki, and provide a categorized list of scripts that it can download.  It currently does not support adding things directly as a user job.
 +
:: Doing this properly would require the above rework of the job queue to support an arbitrary number of user jobs.
 +
*Use Storage Groups and their balancing to decide where job output is written. For example a lossless transcode on a system with 2 HDDs would not cause thrashing, but read from one and write to the other.
 +
:OR give a choice of output Storage Group for each job type for some user control.
 +
*Differentiate between actual transcoding of formats and those jobs that will simply implement the cut list.
 +
* Per show transcoding delayRight now, transcoding of all shows can be delayed for a couple days, but it would be useful to prevent transcoding of certain shows for longer or shorter periods.  For example, shows that I know will be archived for a long period of time can be transcoded now, but shows that I don't want to keep could be transcoded in a week or two in hopes that I actually watched and deleted them before the transcode is scheduled.
  
===UPnP (Universal Plug and Play) server and client features===
+
==LCD Output Addons==
All [http://www.upnp.org UPnP AV] (UPnP = Universal Plug and Play Protocol, and AV = Audio/Video) connectivity and communication protocols to make MythTV be fully UPnP compliant on both the back-end (server) side and the front-end (client) side. So that both MythTV's back-end and front-end is intercooperative with other UPnP servers and clients, (then especially other HTPC applications, both open sourced ones and closed source commersial ones, thus the end-user can choose the best 'back-end' and the best 'front-end' which suits their needs, like a [http://forum.team-mediaportal.com/showthread.php?t=1037 MediaPortal] back-end, or a [http://www.xboxmediacenter.com/forum/showthread.php?t=4463 XBMC] front-end togther with MythTV). For more information see [[UPnP#Developers_notes_on_UPnP|MythTV developers notes on UPnP]].
+
*Display "Next Scheduled Recording" through LIRC VFD. It would be nice to have the next scheduled recording andif recording has aready started, a VFD display of program name and graphical status bar of recording. ie.. Heros - 0-------x----100%
:'''Note!''' UPnP could be implemented one or more native feature(s) or one or more plugin(s):
 
* UPnP AV MediaServer - which is the UPnP-server (a 'slave' device) that share/stream media-data (like audio/video/picture/files) to UPnP-clients on the network). Now a UPnP AV MediaServer has already been implemented into MythTV back-end but the code classes could be updated according to the [http://www.upnp.org/standardizeddcps/default.asp v2.0 specifications] to be UPnP v2 compliant.
 
* UPnP SSDP Discovery Service in both MythTV back-end and front-end to make the MythTV and MythTV auto-discover each other. If not into to both then at least into the MythTV front-end to let it (and other UPnP-clients) auto-detect the MythTV back-end over a local-network.
 
* [http://www.upnp.org/standardizeddcps/remoteui.asp UPnP Remote User Interface (RUI) server/client] (in MythTV back-end and front-end respectivly) - which recieves/sends control-commands beween the UPnP-server and UPnP-client over network, (like record, schedule, play, pause, stop, etc.). With UPnP RUI in both MythTV back-end and front-end, the front-end can control/command the back-end via UPnP, and since UPnP is a standard other 'front-ends' which also feature UPnP RUI can also control/command the MythTV back-end, and the MythTV front-end can control/command other 'back-ends' if they feature UPnP RUI.
 
* UPnP MediaServer ControlPoint - which is the UPnP-client (a 'master' device) that can auto-detect UPnP-servers on the network to browse and stream media/data-files from them. Should be implemented into
 
* UPnP MediaRenderer DCP - which is a 'slave' device that can render content.
 
* UPnP RenderingControl DCP - control MediaRenderer settings; volume, brightness, RGB, sharpness...).
 
* Build and serve chapter breakpoints to match commercial skipping endpoints, using byte offsets and the OFF= uPnP parameter.
 
* Instead of/in addition to the built-in uPnP, have the backend maintain a folder with softlinks (i.e., the recorded shownames), in the same directory structure as currently served up by the internal uPnP player. Then, users can choose which uPnP server they would like, such as uShare, Wizd, Kiss DP-1500 or Swisscenter, and serve the folder.  Ideally it should be a userfs filesystem, but it would be an easy hack to use softlinks, and with a userfs-fs it should be possible to even view live-tv via this. '''(mythrename.pl is designed for this. share over samba and the server will resolve symlinks locally. --wagnerrp, 11/11/08)'''
 
 
 
===Virtual Tuner===
 
 
 
Add the ability for Network Poling for the recording schedule of other Master  backends on the local network, and when the local backend runs out of tuners to record a program its scheduled programs looks at the non-local backends recording schedule to identify available pre-scheduled programs or with user approval scheduled use of the other non-local Master backend  tuners with low priority so that the normal local user of the backend will not be bothered if the tuner becomes unavailable ( ie the use of the tuner for live tv).  IE  the other Masters on the network for the missed recorded program and downloads that Program from the other Non-local Master-backend. This would be helpful in network structures such as  University Networks (MANs and Extensive LANs) and apartment building networks.
 
 
 
EX. 1
 
 
 
Master backend X has schedules Program A,Program B, Program C, Program D all four  air at the same time with only two tuners avalable on the backend, Master backend Y schedules Program A,  Program B, Program C, and D.  Master  X's backend records Programs A and B, Master  Y backend records Programs D and C. Master X backend pulls Programs C and D from Masters Y's backend, and  the same for  user Y's programs A and B are pulled from Master X's backend.
 
 
 
EX. 2
 
 
 
Master X schedules Programs A, B and C but only has two available tuners, Master Y does not have any scheduled recordings so it tentatively schedules to record Program C, this will not affect the use of the other users experience because live TV, and other schedule made by User Y will over ride the recording request of master X. The users of this system should opt in to this functionality as it will use disk space on their machine, until fetched by the other Master (Master X)
 
 
 
EX. 3
 
 
 
User X  forgets to record Program A Season-X Episode-ZY or decides to watch Program A after watching a Episode of it But wants to watch the previous episode showing.  The Master Backend X poles the network for other Backends with the recording of Program A Season-X Episode-ZY, and pulls that recording if available from the other masters.
 
*This could lead to legal issues regarding distribution of copyrighted materials. Yes it could be argued that you're paying for cable and so is someone else, but **AA may not like that and could possibly take legal action (IANAL btw). [Dolcraith]
 
  
[[Category:Developer Documentation]]
+
==MythUtil Addons==
 +
*Add ability to delete a recording, including all database entries and related files.
 +
[[Category:Wishlist]]

Latest revision as of 15:37, 8 November 2015

This articles represents a subsection of the Feature Wishlist.

Backend Addons

General

  • It is an excellent feature of MythTV that you can delete recordings and they are kept until they have to autoexpire (because the disk is getting full). The problem is that this all occurs within MythTV, so backup programs etc. don't know about it. It would be great if deleted-but-not-expired recordings could be put in a "Deleted" folder within the recordings folder. This should not take any disk I/O, as the folder will nearly always be on the same disk. It would allow me to schedule a backup that included my recordings folder, but excluded my "Deleted" folder. At the moment, the folder is too big to backup, so I just can't --Hooloovoo.
You could run mythrename.pl with the --link option, to add a bunch of symlinks to a separate folder. Deleted recordings will be marked with the 'Deleted' recgroup, which corresponds to the '%U' flag in the format string. Simply set your backup to filter based off that.
  • Have mythbackend back up the mythconverg database on a flexible schedule.
The Database Backup and Restore. wagnerrp can be run through cron or the backend init script, and is automatically called in the event of a schema update.
  • Identify hardware in the system by it's pci-id and/or the cardname-string instead of having it go via a "dumb" sourceid and devicefiles. This would make the system much more stable when doing software/hardware upgrades that messes up the order the drivers gets loaded in and should be quite easy to implement. sourceid 0 = "PVR-150" -> find the devicefile that identifies itself with this string.
    • Ideally the operating system would assure a stable device order, though we know this isn't the case on any Linux distro's since the introduction of udev. The information available to udev is visible to MythTV in recent kernels, but it would probably be best if time was spent on writing udev rules and providing them to distro's rather than incorporating udev functionality into MythTV.
  • Ability to give Myth a short video, channel and duration that whenever it is idle it watches the channel waiting for something that looks similar to the video and starts recording for the given duration. Maybe even keep the last x minutes on a ring buffer so that can be put on the start. Could be useful for example to record a generic show when guide data is unavailable, unreliable (which I've noticed is the case with certain channels (WIN) on their attitude towards filler programs (Farscape)), or subject to a last minute change (like when sport or an emergency news broadcast has been on beforehand).
  • option to create 'blacklist' of unwanted programs so that when zapping, mythTV will skip chanels on which these programs are running
  • keep statistics on DVB signal strength so you can see the effective quality of reception or aerial, and keep track of dropped packet counts for recordings, allowing people to know if a recording is good before trying to play it
  • Priority setting to select what EPG to use for a specific channel. If you have multiple capture cards (mix between analog and DVB-cards) you might want to use the EPG data from the DVB card also for the Analog channel.An option could also be, to reduce the size of the program table, to use the callsign and/or name and/or xmltvid instead of the chanid as the identifier for the program data that would then enable you to greatly reduce the amount of data needed in the program table and also enable you to use a DVB-EPG for a analog card that can receive the same channel.
  • When exiting LiveTV both the input and the channel number should be saved, so that when you re-enter LiveTV it will start at the last channel you were watching. As it is today it will always start at the first input when entering LiveTV. Ideally this should be handled by the frontend so that each frontend will automatically start at the channel it was last watching.
  • Additional setting to expiration of recordings that would enable automatic expiration of all recordings older than X days.
  • Converge the storage of videos from mythvideo and the recorded shows such that mythtv really doesn't care about what it's storing. This way you can set a new season of a show to record and be stored/accessed along side you're dvd backups of the previous season. Then allow the importing/overwriting of shows with a supplied video file. Each media item would have either a specified plugin or player for playback. Dolcraith
Partial merging of the database tables for recordings/videos/music/photos is planned, along with matching internal code structures, however there is no intention to merge this content into a single view. Such content is more logically kept separate.
  • If the backend attempts to record a showing and is unable to (cable box is turned off, cable disconnected, etc) and there is a spare tuner that is available and that can record the same show at the same time (possibly a tuner without a cable box, different connection) the backend should try to record the show on the unused tuner (possibly unless there is a tuner preference) instead of failing.
  • resume interrupted recordings also if later is available (record the later too of course if possible).
    • Reason: the whole thing is scheduled this way and changes are unexpected and (especially when reconfiguration has no gain) senseless and leave the recorder unused.
    • Also if interrupts happen at all then more interrupts are likely too and the later recording could easily suffer interrupting too.
    • Proposed behavior: once recording has started keep that schedule and resume it if interrupted. if later airing is available and does not interfere with the schedule also the later airing should be scheduled too. apparently NoBUG?
    • currently rerecording can override lower priority recordings , however generally rerecordings could have a general priority drop, when schedule changes for rerecordings would be required this way only very low priority recordings are overridden.
    • conclusion: in total the user only suffers a tiny loss of the recording
    • also often the user does not require the rerecording except of getting hold of the end at all --Sususu 09:08, 20 September 2011 (UTC)
  • Preferred EIT Grabber channel. Some cable providers in Europe send only now/next on every channel. All other EPG is send on a specific transponder/channel. A checkbox in mythtv-setup to set a special algorithm for EIT scan together with a preferred channel would be nice.
    • Example: Main EIT channel is on channel-number 1 (preferred channel). Special algorithm: EIT grabber jumps to channum 1, then 2, then 1, then 3, then 1, then 4, then 1, then 5
Follow-up Question: I don't understand the purpose of this 'special algorithm. Why not just ignore all the other channels and only pull data from channum 1?
Answer: You are right that is not really necessary (the reason i suggested this was, that now-next is updated too), but id would definitely be of great value if one could set 3 preferred channels or so ..
Doesn't MythTV currently scan through all channels marked for on-air data? Wouldn't this special channel already get polled to populate the other channels' long term data?
If you know of technical documentation describing ways to automatically find out about the "guide service" add it to #11809, please. --Dekarl 20:44, 29 January 2014 (UTC)
  • Multilingual EIT support. At least some networks in Finland broadcast program data in several languages, presented as multiple descriptors in the same event entry. The descriptors come in a changing and seemingly random order, and MythTV currently seems to take the first (or last?) of them. As a result, program titles may change back and forth between the languages, which can cause recordings to be missed. The solution to this would include:
    • Adding a 'language' column to all tables that contain program data
    • Having the EIT scanner insert program data in each language instead of just one
    • The frontend (and mythweb) should include a setting for preferred display language(s)
    • (Not sure if recording schedules should also include the language information, and only match against titles that the user would see in the UI)
    • As a simpler alternative to all of the above, could also keep database and frontend as is, and just add a preferred language(s) setting to the backend, to control which of the titles and descriptions the EIT scanner stores. Having all languages in the database and letting users select them in the frontend would seem like the better and more flexible solution, though.
  • Allow mythbackend to run a automatic minimal updates channel rescan. My cableco occasionally shifts around channels on QAM. When it fails to find the correct program id, check to see if that channel title exists under any other id, rather than reporting successful recording of a 0B file.
    • As such behavior would currently require a restart of all backends, running an abbreviated EIT scan that just makes sure all channels are tunable, and raising an error if not, would be a simpler solution. wagnerrp 20:59, 3 November 2009 (UTC)
  • Stop EIT update from preventing a backend box from going to sleep. Perhaps have a scheduled EIT update time per time period, so that EIT updates could still occur without preventing power saving.
    • As an alternative, allow users to select when and how an EIT update will occur. Constant EIT scans are not necessary when broadcasters provide 7 to 8 days information, as they now do in Australia. (As a work-around, turn EIT off and use the a script based on tv_grab_dvb to provide EPG data to mythfilldatabase.)
Your wish has been granted [e73015ba7f] --Dekarl 20:44, 29 January 2014 (UTC)
  • Add a panel application for MythTV back end that shows if it is recording or idle. Hovering the mouse should show next scheduled recording. This would be helpful for those who use their computer for front end, back end, and desktop. Currently, I must run mythweb, or myth front end to find out the state of myth back end. I must know the state of myth backend if I wish to do system maintenance, reboot the computer, or run a resource intensive application to prevent interrupting a recording. Myth welcome is nice, but it gets in the way when using the system as a desktop.
Preliminary version for Gnome: mythstatus.py
exists for Windows -- MythTV Sidebar Gadget
The Windows gadget is GPLd so it should be possible to port it to the widget engines used by X based desktops like KDE and GNOME for use on Linux and other FLOSS operating systems.
  • 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.
Could be handled by an external script pulling a list of expiring recordings over the backend protocol.
  • 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.
  • Support for several titles to same program.
Having localized titles improves WAF, but often breaks coverart scripts. Currently XML grabbers already know of different titles for same program - using the original title for covertart and localized title for display would be perfect.
Recorded content does not currently have real artwork support. The artwork displayed by some themes is merely where the frontend thinks images for that title might be stored in the MythVideo folders. Planned changes to the way videos are stored in the database would allow proper handling of artwork for recorded shows, and would make at least the stated reason for needing multiple titles unnecessary.
  • about MySQL Queries on example of duplicate show markings: i experience a great performance loss when "mythfilldatabase" is run and i traced it back to the mark first and last queries ... which are hard coded and the whole thing being glued together in "mythfilldatabse" ... so this is rather a general request uncouple the queries from the sourcecode ... maybe by scripts or maybe in a secondary file (PS: my approach speeds marking up by 900% explanation would be a bit longer so message me if you would like to know how )
if it would be a different script one could also employ a "softer" duplication finder
Why not force mythfilldatabase to occur during a time that it does not cause you problems? wagnerrp 12:19, 4 April 2012 (UTC)

Security/Multi-User Management

  • Password protection. Before being able to talk to the backend a frontend must send a password. This would make it more secure if a user wanted to open up their mythtv port to the outside. -- Is this really neccessary when you can port forward through ssh for security anyway? UKDude - Please point to howto instructions. --Turpie 00:42, 6 August 2007 (UTC)
  • Ability to have a required log-on for all frontends with a unique ID and pass after registering. Some features would include limmiting number of shows someone can record per week, giving users who are currently watching TV priority, aka locking the channel, to prevent other users from messing up the recording, most of the parental controls from above included, and the log of each user and their activity. Also the ablility to download the shows to the frontend to limit stress on server.
  • Channel lock,or just 'lock'. Users can receive a warning when attempting to change the channel while not caught up to real time, so the original purpose behind this is moot.. Might (still) be handy for parents with little kids.
  • Add ability for mythtv to log all shows watched (live or recorded) during a day and store in a unique log file per day to store tv watching history. Add ability to put parental controls on mythtv to only allow a given number of hours of tv watching during the day, only allow certain channels during certain times on certain days of the week.
  • How about a feature that would allow you to 'markup' DVD's to skip unwanted scenes for parental control or even look at the subtitles and mute when there are bad words? DVD subtitles are images, so that last part would require significant OCR'ing...
  • Add ClearPlay-like content filtering, not just identification, to MythTV.
  • The ability to lock out specific frontends from specific channels (still tuneable, just not watchable. 4-digit PIN code to override). Maybe you have one frontend in the living room, one in the bedroom and one in the kids' room. It would be nice to be able to only send Cartoon Network, etc. into the kids' room while sending Playboy TV, etc. only to the bedroom... I imagine setting up a "standard package" and then registering the frontends somehow and customizing their channels. I guess this sounds awfully broadcasterish, which is not the original intention, but apparently a positive side-effect ;-)

Hardware support

  • Per-card audio level controls, to compensate for potentially double-digit dB differences in capture levels across differing revisions, models, and even brands of capture cards. (Extra credit while working there: per-input and per-channel controls as well.) Discussion and potential design can be found at Why is my 350's audio so much l-l-louder! than the 250's? and No per-individual line-level adjust: bug or missing feature? and (inadvertently broken thread) here.
  • USB hard drive - have the ability to plug in a USB hard drive and transfer video files over to the hard drive with menus in the myth GUI
  • External script support for DVB-T tuner cards to control OTA antenna rotors. This is especially important for US users since the NTSC analog shutdown is about one year away. ATSC stations are difficult to tune in fringe areas, and there needs to be a linkage to allow an external IR rotor controler (such as the Channel Master 9537) to align the antenna. This is NOT the same as Diseqc, since that controls LNB's and Dish rotators. If there would be a flag and pointer to an external change script in the DVB-T tuning code, it may not be a major code overhaul. I am willing to test any implementation, since without it, my ATSC options are very limited. lbelan63
  • Support SAT>IP. These are DVB-S or DVB-C receivers which are connected to the ethernet instead of Plugin to PCI, PCIe oder USB. See http://www.satip.info/. Example Devices are the "Octopus Network TV-Tuners from DigitalDevices" (see http://shop.digital-devices.de/)
  • To use SAT>IP equipment for home use (like http://www.tbsdtv.com/products/iptv-streamer.html), which can not stream all TV channels simultaneously, I am dependant on the "Recording pending" system event in order to tune the box to the wanted channel. Would it be possible to add a system event "Tuning pending" which is triggered when MythTV want to tune to a channel? This would make the IPTV equipment also work for live TV and receiving EIT data.

Input Streams - TV/Radio/Other

  • Provide local channel rss feeds. (ie. cable station website gives rss feed for programming on a channel otherwise seen as "local programming" or similar)
    • Better implemented in MythWeb, which already offers some iCal/RSS support. wagnerrp 20:59, 3 November 2009 (UTC)
  • Provide some way for users with multiple available tv cards to switch channels, while keeping the ringbuffer for the previous channel until system runs out of tv cards. This would allow flipping between two shows and keeping the ringbuffer for both
  • Some stuff for channels with encryption to make it easier to manage channels that you have subscribed to. (especially with DVB-s since you can have multiple providers on the same sat)
  • Ability to read out the channel-name from teletext (useful when scanning channels). Maybe could be good to have this as a "script-plugin" where myth calls the script with the 2 top lines from the teletext and then the script should return the chan-name.
Already done for digital channels. With analog TV being slowly phased out worldwide, it's not likely anyone is going to invest much time in a new feature only usable with analog channels.
  • Audio Description support for blind and partially sighted folk, where this is available as a separate audio track. Could be merged into main soundtrack (may be issues with differing bit rates) or stored separately from the main programme stream for later re-assembly? On the DVB-T streams I'm capturing in the UK, something like this works as a post-processing job, but it would be much nicer to do within Myth rather than by unpacking, hacking around and then reassembling the MPEG stream...
 #!/bin/sh
 mplayer -dumpaudio -dumpfile audio-main.mp3 $1
 mplayer -dumpvideo -dumpfile video.m2v $1
 # note aid of Audio Description track may vary...  use "mplayer --identify --frames 0" to find it? ...
 mplayer -dumpaudio -dumpfile audio-adtrack.mp3 -aid 0x296 $1
 # note your distro version of sox may not have MP3 support ...
 sox -m audio-main.mp3 audio-adtrack.mp3 combined-audio.mp3
 mplex -f 3 -o $1.new video.m2v combined-audio.mp3 
 [ -s $1 ] && rename $1.new $1

--Martinh

  • HTTP support for IPTV. Currently the IPTV feature only supports UDP and RTP streams. I have an IPTV provider that uses HTTP. The streams are indeed MPEG-TS compliant as I can access them with TSReader and it displays the various tables and pids.
    • Can you verify it's a TS over HTTP and not TS over RTSP over HTTP? (I can't find a reference for that anywhere) If it's MPEG over HTTP take a peek at #5928 to see how to add a new protocol to the IPTV feeder. --Dekarl 16:12, 29 March 2010 (UTC)
      • I believe it's TS over HTTP as VLC and mplayer were unable to connect when I switched stream URL to RTSP. Is there any reccomended test to be 100% sure if it's one or the other? (i.e. running vlc or mplayer on verbose and looking for a specific message in the output) --kyl416 22:10, 30 March 2010 (UTC) Let me see if i can find their test server
      • Looking at that code in #5928, that's more for taking a regular MP3 stream from an icecast/shoutcast server and repackaging it into a MPEG-TS compliant stream with a PAT, PMT, etc. This doesn't apply to my situation as the IPTV provider is already delivering the streams with the MPEG-TS tables. I'm pretty much a novice when it comes to coding from scratch. I'll take a look at the existing iptvfeeder___ files to see if I can come up with something.--kyl416 00:07, 31 March 2010 (UTC)
  • Possible improvement to the IPTV function to also enable the ability to decode all internet based live streams so you can insert them into the EPG as if they were a regular channel, and not just limit it to available streams from your ISP's IPTV service. (i.e. Windows Media, Real, etc)
  • Allow a UPnP source to be an input. Needs to allow for quick download and live TV download. eg: file is being transcoded live and will transfer at live speed only. --TheRockApe 02:34, 23 July 2010 (UTC)
  • Add support for BestRussianTV IPTV <API Documentation>. Format appears to be RTSP, but requires 'priming' by talking to an HTTP server to enable the stream. Control server also provides EPG data, which could be used by an XMLTV grabber. If anyone will need authentication information, i might be able to provide it just e-mail me.--Krutoileshii 21:45, 24 December 2010 (UTC)
  • Add support for PPStream to enable watching chinese programs from www.ppstream.com. Possible check http://www.pps.tv/about/6/364.html, or http://code.google.com/p/totem-pps/, or http://code.google.com/p/gmlive/
  • provide arbitrary encapsulation of ANY UNIX application started fullscreen inside of a VNC session and assign to a Channel - I.E - start a vnc session with xterm in fullscreen, assign to channel 100, start xchat logging into #mythtv-users and assign to channel 101, etc.
    • VLC can be used to capture from a Screen input, and stream back over RTSP, which can then be captured by MythTV wagnerrp 20:05, 14 July 2009 (UTC)
  • Allow a single tuner to record multiple streams of a single channel, allowing for overlap. This is already possible for digital tuner through multirec, but not for analog or firewire capture.
  • Enable slave DVB card: This card "free rides" on the pass through satellite signal from a master DVB card. The slave is bound to the DiseqC (Band, polarity, position) of the master DVB card but is freely able (encouraged?) to use another frequency in that band. This will enable the backend to more fully utilize the signal from a single cable to the dish. I am not sure about the effects on the scheduler. Brennelv 16 November 2011 (UTC)

Output Streams - UPnP/Multicast/MythProto

  • Build and serve chapter breakpoints to match commercial skipping endpoints, using byte offsets and the OFF= uPnP parameter.
A solution is currently in the works to use m3u playlists to offer the same behavior.
  • Add recording date to upnpcdstv.cpp and change Title sort to recording date to provide a better indication of watching order of episodes (especially on the PS3).
I've submitted a pull request on Github that should fulfill this requirement (and a slight expansion) https://github.com/MythTV/mythtv/pull/19. This may or may not be accepted but it is a simple change to a single file if you are comfortable rebuilding yourself.
  • 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.
  • Not sure if it is a client (Sony TV) bug but at the moment if I start watching a program while it is still recording I cannot watch past the point that was being recorded when I started watching. It would be nice if chasing playback could be supported. If it is a client bug I suspect it may be a common one and it may be worth lying to the client in some way. The challenge may be proper handling of requests past the current recording point (fast forward or skip).
  • More music browsing options: I don't know if this is possible, but if you have a huge library, it can take ages to scroll to the item you want on a device. Perhaps they can be organized into sub-folders based on letters?
  • add support for the backend to indentify itself to Apple's FrontRow App as a computer on the network with media available (basically tricking FrontRow into thinking that the backend is another apple computer with shared media) -- Do you mean like Firefly [1]?
    • Does FrontRow not work with the existing UPnP server? wagnerrp 20:59, 3 November 2009 (UTC)

Intelligent Scheduling

  • Recognize subtle changes in the scheduled recording description so that they don't break the schedule. Some examples:
    • The tv_grab_au grabber found a program called "Doctor Who", episode "Smith And Jones" that runs 7:30pm - 8:15pm. The EIT scan updated this to a show called "Doctor Who: Smith And Jones", with no episode name, that runs 7:32pm - 8:18pm. A scheduled recording based on the first description should still record - however the recording actually does not happen.
      • At the risk of confusing bugs, feature requests and philosophical reflections; EIT updates should supersede old data. If there is a 90% overlap of time then it is probably an update and the new data should be used instead of the old data. The actual heuristic used could be quite "interesting" and it might be desirable to flag any updated items to request human confirmation. If the heuristic is totally confused by the update (say it is in a different language) it should give up, use the old data, and request human intervention. In the Dr. Who example above one possible response would be to record "unknown" from the earlier start time to the later end time, 7:30-8:18.
    • There is a program that the tv_grab_au grabber sometimes calls the regular evening news "ABC News" and sometimes calls it "ABC News Update". They are on the same channel at the same time and it would be great to be able to use wild cards (or something) so that they are always recorded.
    • Wild cards/regex in general would be nice. Often main titles are messed with: "Revenge (new episode)", or "Revenge (* SNEAK PEAK Masterchef blah *)" or "Season Final: / Finale" prefixes/suffixes are added. Oz TV is also fond of changing weekly times so you can't rely on it being close to the timeslot you expect.
    • Some channels (e.g. Finnish YLE), do minor time corrections to EIT data days/hours before the show starts. E.g. 21:00:00-21:50:00 is updated to 21:00:19-21:50:19. This causes a normal scheduled recording to break since the specified show title can't be found at exactly the same time anymore. Could there be a threshold of a few minutes to avoid this?
Can be done with a Custom Record
      • Are you sure that current behavior is not a bug? Either accept the update and use those times or ignore the update and record original times. Don't cancel the recording.
    • I have occasionally seen misspellings of program names that would lead to schedules failing to record when the mistake is corrected.
    • If the start and end times remain the same (or even approximately the same?), should perhaps keep the recording scheduled regardless of changes in the title. Similarity match might not always work (there's also the case of e.g. title changing from one language to another), and recording something unnecessarily is usually much less harmful than failing to record something that the user wanted.
  • Allow default "start early" / "end late" values per channel. This would allow us to use small (or zero) values for the channels that we can trust to be accurate (like the public broadcasters in Australia), while we allow recordings to run over by 20 minutes on channels that consistently publish incorrect program run time information even in their EIT streams, like the Australian commercial channels.
  • Have 2 scheduling profiles for 1 show. example one profile for new episodes of family guy and another profile for re-runs of family guy. This could be accomplished by an option to increase the priority for new episodes, or decrease the priority of repeats, and by adding a "Number of Repeats to keep" option along with the "Number of episodes to keep".
  • MythWelcome - will set the next wakeup time to be the lesser of the next scheduled recording and the next time to run mythfilldatabase as suggested by the grabber
  • More precise time offset for guide listings (My clock is spot on using NTP, but my provider's clock seems fast by 30-60 seconds). Or, allow "End Late" to be a negative value, could be used in combination with "Start Early" to accomplish same goal. This could also be used to compensate for any scheduler "lag".
'Start Early' and 'End Late' can be negative values, with the expected behavior.
In DVB systems, the system time is broadcast in the system time table (STT) (see http://www.interactivetvweb.org/tutorial/dtv-intro/atsc-si/mgt-stt.shtml) and this could be used to determine the offset. I would suggest that the MythTV system should have its time set using NTP, and then establish a time offset for each channel, scanned from the STT. In the ideal world, all of the offsets would turn out to be zero, however the stations seem to get this wrong sometimes.
  • Allow selection on additional fields, e.g. only record a movie if it's being broadcast in widescreen.
  • Record/don't record on certain channels. Add the ability to have a channel include/exclude list that lets the scheduler consider certain channels or bars it from considering certain channels. This will allow me to record Lost on any FOX affiliate, but keep MythTV from mistaking the Lost reality show on FOX Reality for the drama series.
Under mythtv-setup you can assign priorities for channels and out-right remove them. For example, I have two ABC affiliates and I prefer to record form WABC vs. the local, so I have WABC higher priority.
  • Allow backend to change tuner selection for recording on the fly if a user is watching live TV. (I have three tuner cards, and while I'm watching live TV, the backend often takes over the tuner I'm using, despite two other tuners being available.)
This is available "Utilities/Setup -> Setup -> General -> Avoid conflicts between live TV and scheduled shows"
  • Partial recordings flag — my gf loves American Idol, but I want to record a 30 min show during its two hour show. So, I want MythTV to record the first 60 min then stop and record the last 30 min (she just wants as much as possible). - This would be helpful during long televised events such as the olympics, when the TV schedule just has one long show that lasts 8 hours.
    • Since it is well known that not all programs are of the all-or-nothing type, current behavior of not recording parts of a program when a tuner is idle is a bug. If a program is an all-or-nothing type you would give it a high priority. As a real feature request, introduce a flag for all-or-nothing and mark partial programs as incomplete.
  • Add support for "idle priority" recordings. This is perhaps a way to minimize channel change time in LiveTV. Unused cards in the BE could be tuned and recording preset channel(s) in case of a channel change. These recordings can be overridden by any scheduled recording, unless the user presses "R" to record them. Naturally, these recordings will be auto-expired preferentially. The channels that are being recorded can be changed to follow the users channel surfing habit. Combined with the multiple channels from single multiplex idea this could generate seamless channel surfing.
  • Bring back some version of the "don't record if less that X MB free on drive" feature. I realize this has effects on LiveTV, but some people rarely use LiveTV and expiring one episode of a show in long-running syndication to record another seems unnecessary. Not recording already watched episodes solves this issue in the long run, but not until many many episodes have been watched. Could this be done in conjunction with some sort of limitation on LiveTV (a box that pops up telling you to restart your LiveTV watching to clear the buffer or something) to prevent the problems that caused this feature to be removed in the first place?
Don't allow auto-expiration, and your recordings will not be automatically deleted.
LiveTV is chopped up at each show boundary. Just make sure you have enough free space for the longest show you may want to watch live.
  • Create "Channel Groups" - in the UK new episodes of shows are often shown with repeats on a set of channels (e.g. Sky One and Sky two) and episodes from old seasons are on other channels. It would be good to be able to create channel groups like "Sky one, sky two, sky three" and say "record at any time in group "Sky". This would also work for the "+1 hour" channels. Currently I record programs like this through a manual schedule.
  • Generic episodes that air at the same time should only record once.
    • I record The Simpsons which doesn't always have specific show information. I want to record even the generic episodes, but when they are generic, I always get 2 copies. One from my SD channel (44) and one on my HD channel (44.1). The scheduler should be smart enough to know that if the show is generic and on at the same time as another generic episode, then it's likely the same episode even though the xmltv id's aren't exactly the same.
  • 'Already in Progress'. An option on the recording schedule to record a program already in progress if it has been pre-empted by a higher priority program. For example, long sporting events (golf tournaments, endurance racing) where the broadcast might be several hours long. A 30-minute program in the middle of the sporting event would be recorded and then recording of the longer program would resume.
    • This is the same a "partial recordings" above.
  • Record all parts of a split programme. Channel Five in the UK frequently show films with a short news programme in the middle, this splits the film into two parts with a short gap between the two. Currently I have to book both parts of the film in order to get the whole thing and it appears as two separate recordings in the recordings list. I have on occasion nearly missed the first or second half because I hadn't noticed it was split at the time I originally booked it. It would be useful if Myth recognised where programmes are split like this and all parts automatically recorded instead of just the part that was booked. It would also be good if programmes recorded like this were stitched back together into a single recording to watch back.
If the shows show up as repeats, your guide information is broken.
  • Allow scheduling of arbitrary applications. You might think I could do this with cron, but cron wont turn the computer on to run the application if it is currently off. I use my computer as a front end, back end, and a desktop. I have it set up to automatically power on & off for recordings, and can manually turn it on to use as a desktop (it checks for logged in users and won't shut down when someone is logged in) I'd like to be able to schedule automatic backups of my files, but to do that with cron would require leaving my computer on all the time.
    • See anacron.
      • anacron will not do what I want. anacron guarantees that the backup would run at the most inconvenient time possible (when I turn on the computer to use it, or when the computer turns on to do a recording) I want the computer to turn on by itself at a time when I'm sure nothing else will be happening to execute a backup that is going to tie up my disk drives for a significant amount of time. There is only one wake timer in the system. It is being used by MythTV. There is currently no mechanism to allow other things to wake the computer.
  • Generalize and separate the shutdown and RTC alarm from MythTV backend, and merge it with cron. This is probably much more difficult to do than the above, but would solve the above problem, and allow automated power on & off for systems that don't run MythTV.
    • Already possible. Disable RTC alarm support in mythtv, and change the shutdown command in mythtv-setup to a script of your own design. Have this external script pull the time of next recording from mythtv, as well as the time of any other external scheduled items, and set the alarm accordingly before shutting down.
  • Ability to mark recording as previously recorded. This would be useful in a few situations. I.E. Recently i rebuilt my system from scratch not using any of my backups because the i was going from a distro that had a few major version jumps since my version. When i set up recordings for my favorite series, i usually use any/any. The problem with that, is that on some week nights, and weekends the cable provider will run marathons. Which will flood the upcoming recordings screen with episodes i have already seen.
  • Ability to automatically remove/disable recording schedules after a user-specified period of time. E.g. I want to record a mini-series in three parts, so I set a recurring schedule for that title. What usually ends up happening is that I forget about the schedule and end up having it in my recording schedule for many many years, which leaves me with a very cluttered schedule.
  • If all else is the same, give priority to the showing that runs longest. I'm noticing this with the upcoming State of the Union - I prefer to watch the news channel that has longer coverage.
  • Allow lead in and lead out times to have a lower priority than the main program. Then consecutive programs can be recorded by the same tuner.
  • In the spanish DVB-T (probably in other countries too), now and then, some providers change their EPG data to "unknown" for untold reasons although they keep their previously set schedules. It would be nice the scheduler would keep its record schedule time (and program title and subtitle) when the timeslot EPG data is reset to "unknown" by the provider (and offer this behavior as an user option).

Suggested Recordings

  • Recording suggestions, 2, 3}, á la TiVo
  • Speculatively record shows that the user *might* want to watch, even though the user hasn't manually asked for them. (But, of course, never let these take priority over shows the user says he definitely *does* want to be recorded). See http://www.templetons.com/brad/myth/tvwish.html
  • Use Bayesian prediction (just like SpamAssassin) to get better at predicting which shows the user *might* want to watch. See http://www.whynot.net/view_idea?id=1236 (Update: perhaps this could apply to Recording Suggestions above?) - This was already semi-implemented, see http://www.nexusuk.org/projects/mythtv/mythbayes/ (would need updating and a UI). Note that this was only moderately successful - a last.fm style recommendations engine would be better.
  • More robust recording: When MythTV failes to start a recording, it should retry a few times - instead of hanging. It's better to just lose 1% of a show then 100% !
  • Subscribe to someone's recommended settings for recordings: Someone else is interested in the same shows and programs as you are. Why not let her recommend them in a way that would let you import the settings manually or even automatically? A format for a blog/wiki would be handy and some way for the backend to poll for new entries would be needed.

Commercial Detection

  • While commercial detection works pretty well in my area it sometimes mistakes the last part of the program as a commercial so I have to skip back a couple of minutes to watch the end of the show. It would be good if mythcommflag would desensitise itself near the scheduled end of the program. (Scheduled end not actual end as I usually extend my schedules by 10-15 mins.)--Turpie 00:05, 3 April 2008 (UTC)
  • Configurable "pad_frames_before_comm" and "pad_frames_after_comm" option. Or even an appropriate #define for this. Commercial detection works very well on most recordings I make -- the last frame of episode video before the commercial is selected. However, there is usually audio (station identification, etc) over the last two or three frames of episode. I currently have to manually move most break start-points back two keyframes.
  • Configurable "max_commercial_length", override recordedmarkup and skip max_commercial_length where appropriate. (sometimes I hit skip and jump 13 minutes, etc).
  • Commercial flagging profiles: A US broadcast TV show often uses the same basic commercial layout for all episodes. Knowing that the show will have 5 commercial breaks, of durations "3min,3min,5min,3min,3min" with gaps of no less than 6 minutes between them, could be used to optimize flagging.
  • Ability to specify that cuts should exclude N seconds of the commercial (so that the viewer can tell that that a commercial was cut correctly.)
  • For US user's, use the black/white TV rating in the corner of a recording to help detect when a show starts again. (Often times an explosion about 20-120 seconds before/after the commercials is used as the skip point as the entire screen goes white.)
  • Using stream information for commercial flagging. There are often discontinuities in DVB streams when commercials begin or end - aspect ratio or audio channels may change, or (not sure about this) possibly different streams can be detected even when these remain the same. Commflagging could be much faster (and fast enough to do online flagging during LiveTV), and also more accurate, if this information could be made available to it. The same info could also be used to detect program start and end, and auto-shift or extend recordings accordingly.

Transcoding

  • The ability to encode in DVR-MS format. My logic behind this it for MCE and MythTV to coexist. XBOX 360's could then be used as front ends for MythTV recordings. Since DVR-MS is just wrapped MPEG2 this shouldn't be that hard, I would think.
  • In addition to MP3 and uncompressed, there should be an option in the transcoding profile setup screen to allow for straight pass-through. For AC3 audio streams this will preserve the 5.1 surround data while allowing very large HDTV streams to be substantially reduced in size by converting them to MPEG-4, and possibly lowering their resolution.
  • allow a flag on NUVEXPORT or mythtranscode to delete the source recording in mythtv when the transcoding is finished if it is being transcoded to another location for ipod use or other use. This eliminates the manual deletion of files and allows a family to set transcode functions for family members that watch on an ipod and not clutter up the screen with that persons recordings.
Can be done with a script wrapper.
  • A crop filter that crops the image to the requested size would be useful. The current crop filter only blacks out the areas requested. This could be used during transcoding to crop 16:9 images back to 4:3 for older material, or to improve bitrates/image quality by removing black edges and their expensive transitions found on most digitally recorded footage. (workaround: a custom job using mencoder and its -vf crop filter.)
If the crop filter worked like this, I would put crop=1,1,1,1 on all my transcoders.
Understand that due to macroblock limitations, you cannot actually crop videos at anything smaller than 8 or 16 pixels, depending on the codec.
  • Keep DVB subtitles, both when transcoding and when storing recordings to DVD with mytharchive. Can be done manually with projectX, ifoedit (windows only) and a lot of wasted time see here and here.
  • 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.
  • Support for h264 (through libx264)
  • Support for handling multiple audio streams
  • Support for alternate container formats
  • Smarter transcoder profile selection. Ability to specify the transcoder profile based on various parameters of the video file (resolution, rate, etc). Similar to the new playback modes selection. The idea here is that sometimes my system records a program in hi-def because the standard def tuner is in use. I really don't care about that program being in hi-def and would like to transcode it to a smaller size (resolution and bit-rate), but when the same program is recorded in standard def, I don't want the size changed.
Can be done using an external user job running a script to determine how to transcode.
  • Transcode MPEG2 to MPEG4 on the fly based on frontend request. This would allow non-mpeg2/nuv capable devices (tablets, Raspberry Pi) to have a front-end and use their hw acceleration/scaling. I know post-recording transcode is possible, but it would be nice to be able to watch before the recording is finished and allow searching/skipping. Given that myth can deal with mpeg4 at the backend natively, it would be great to do this conversion while recording, before the data is written to disk, but I suspect that would be more difficult once you introduce multiplex channels where the number of recordings (workload) is not certain (not 1-to-1 with tuners).
The HLS server can be used to transcode content on-the-fly for low capability devices, however this is more intended for external devices rather than internal usage.
  • A frontend-backend handshake saying what codecs can be used and if the frontend is fast enough to transcode on its own ("I'm a quad-core arm system, I prefer mpeg4 but I can transcode mpeg2 if the backend is busy")

JobQueue Addons

  • More intelligent job queue system/ui for each recorded show, showing jobs as an actual queue instead of just started or stopped (similar to what the system status shows.) This will make clear what order jobs will run in as well as allow a user to queue a single job twice.
  • Give Commerical Flagging jobs priority over Transcoding jobs.
  • Give the option to only process one (or some arbitrary number) HD job at a time - 3 HD transcoding jobs can clog up the queue and prevent commercial flagging jobs and faster SD transcoding from occurring for long periods of time.
  • Give separate options for number of jobs on a backend for each job type. For example, I could say a backend can do 2 commercial flagging jobs, 1 transcoding job, and 2 User Job #1s at once. Maybe replace the "Allow Transcoding Jobs" checkbox with a text field that sets the number allowed? This would allow better processing distribution across several backends.
  • Allow for an arbitrary number of User Jobs (create a userjob table in the database?)
  • Jobs repository - A simple way to find and install job scripts - similar to boxee apps without the pretty icons.
There is a crude version of this in the Python bindings in trunk, to be released in 0.24. `mythwikiscripts` will parse specially formatted pages on this wiki, and provide a categorized list of scripts that it can download. It currently does not support adding things directly as a user job.
Doing this properly would require the above rework of the job queue to support an arbitrary number of user jobs.
  • Use Storage Groups and their balancing to decide where job output is written. For example a lossless transcode on a system with 2 HDDs would not cause thrashing, but read from one and write to the other.
OR give a choice of output Storage Group for each job type for some user control.
  • Differentiate between actual transcoding of formats and those jobs that will simply implement the cut list.
  • Per show transcoding delay. Right now, transcoding of all shows can be delayed for a couple days, but it would be useful to prevent transcoding of certain shows for longer or shorter periods. For example, shows that I know will be archived for a long period of time can be transcoded now, but shows that I don't want to keep could be transcoded in a week or two in hopes that I actually watched and deleted them before the transcode is scheduled.

LCD Output Addons

  • Display "Next Scheduled Recording" through LIRC VFD. It would be nice to have the next scheduled recording andif recording has aready started, a VFD display of program name and graphical status bar of recording. ie.. Heros - 0-------x----100%

MythUtil Addons

  • Add ability to delete a recording, including all database entries and related files.