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

From MythTV Official Wiki
Jump to: navigation, search
(General)
(General)
Line 23: Line 23:
 
* 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)
 
* 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.
 
* 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 (able to specify during what time and a lenght of the job). 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.
+
* 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.
  
 
=== Hardware support ===
 
=== Hardware support ===

Revision as of 22:40, 29 October 2006

This articles represents a subsection of the Feature Wishlist.

Backend Addons

General

  • 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.
  • 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 job's 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.
  • Allow for an arbitrary number of User Jobs (create a userjob table in the database?)
  • Be able to change channels in the program guide. When selecting a channel you are only able to set the recording priorities (I know of the option to just change the channel). There should also be a "Turn to this channel immediately" menu item in the record menu. This way you can use both features in one, without having to switch the guide behavior in the setup.
  • A better Plugin interface, so that Plugins are not only Extra Applications, they should also be able to interact directly with backend functions...
  • Have mythbackend back up the mythconverg database on a flexible schedule.
  • support for secondary storage via NFS - when primary storage is full on a backend, go to secondary storage -- like a storage heirarchy
  • 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.
  • Allow manual setting of DVB video/audio PIDs rather than always using on-air information - this would allow watching BBC Parliament / News Multiscreen video in UK
  • including support for SQLite (or PostgresSQL) might make configuration simpler for machines that are only running MySQL for MythTV anyways - MySQL configuration is a common source of problems for new users
  • add support for the backend to indentify itself to Apple's FrontRow App as a computer on the network with media available (basicly tricking FrontRow into thinking that the backend is another apple computer with shared media)
  • Have additional separate settings for transcoding and flagging jobs regarding max. simultanous jobs. Flagging jobs are (if not running in realtime) CPU intensive, not IO intensive. If they are running in realtime, they are neither CPU nor IO intensive. So there's no problem running 2 simultanously. Transcoding jobs are, if they are doing MPEG2 transcoding, very IO intensive, so it is usually a lot faster running them one at a time, instead of 2 simultanously. So, it would make sense to be able to set max. simultanous jobs for flagging to 2 and for transcoding to 1. This should be an additional setting to the current max. jobs setting, because otherwise people would lose the possibility to allow only 1 job globally.
  • collect program data from more than one xmltv grabber. The xmltv grabber to be used should be definable per channel.
  • 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.

Hardware support

Input Streams - TV/Radio/Other

  • Add Support to view multiple Channels from one Transponder with DVB. So that you can use more recordings, PIP as if you have two cards if you only have one. Handle multiple DVB channels simultaneously from a single multiplex. Also have a look at this Ticket: http://svn.mythtv.org/trac/ticket/1772
  • 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 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, ...) --Anaerin Also known as IPTV
  • I second the iptv vote, and am willing to provide some rtsp streams for testing via darwin streaming server. --brandon at dacrib.net.
  • IPTV can be "made" using VLC as an IPTV server, using it's streaming and SAP/SDP announcement capabilities. --Anaerin
  • I would like to start a project to get the ball rolling on this, I will immediately provide server / bandwidth / mpeg streams, and later provide dvb hardware + nps account. I am totally willing to spend the time and some of the money creating an iptv provider that can do this. Anyone interested contact me brandon at dacrib.net.
  • I am working to make this a reality. Even when a generic iptv tuner is written then it is useless without content. Therefore I am working to license content from somewhere to be delivered first to my organization via dvb, then to my end users via multicasts and/or rtsp streams. I am working on how/if I could multicast over the internet (vpn?) and looking in to the viability of vlc as a streaming/vod server over commercial offerings from minerva networks. So here is what I see as needing to be done.
  • 1) Prove the viability of the concept by getting the backend components working, rtsp streming (done), multicasting (over vpn?).
  • 2) Get content licensed, encoded (mpeg4,h264?) and procedures for adding content to our lineup done.
  • 3) I'll have to come up with or have written some serious management code that will keep track of purchased vod's, as well as "plans" for each user.
  • 4) My primary goal is great content delivered over ip to mythtv users, but I will probably also have to offer some type of stb to make it all worth it, I have looked @ pace, aminocom, and rolling my own but I want hardware mpeg4 decoding... anyone?
  • 5) DRM??
  • 6) Profit...!!!??

--bprice20

  • 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)

1. During the EIT scan or if you try to switch to a specific channel it would be nice if it would (re-)detect encrypted/decrypted channels, and also see if you are able to decrypt it via a subscription, and set it as encrypted/subscribed-decrypted/FTA in the database. Not shure how encrypted channels will be managed in the future, but atleast for the FTA users this would be quite nice. And at the same time eliminate the need for scanning for FTA-only channels and having to keep all that up to date. Just do a rescan when a new channel appears but never when they switch on/off the encryption on a specific channel.

2. Add an option so it will never display an encrypted channel to either the chan-list in the mythfrontend or in mythweb. These 2 options would be nice since then you would still have the full chan-list with all the epg-data and at the same time you would be able to see if a channel has gone "free-to-air" or got included in your current subscription without having to do a rescan of FTA channels and or edit the channel so it becomes visible.

  • If a encrypted stream is selected to be played the backend crashes, atleast for me, due to an invalid mpeg stream. This could be fixed by having the backend check the DVB stream and detect that it's encrypted and then just send a "No subscription" image instead of trying to send the encrypted data. This is somewhere in between a bugfix/request.
  • Ability to read out the channel-name from teletext (useful when scanning channels)
  • Ability to have mythtv call a script for EPG updates via teletext. Ie mythtv calls the script, the script returns one or more pages, mythtv waits for the input-source to become free and then get those pages and returns them to the script. This would be perfect for a system not connected to the internet or for late changes in the EPG.

Output Streams - DivX/MPEG/Other

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

  • Recording suggestions, 2, 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".
  • 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.
  • 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.
  • 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.
    • 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 reininitalizes 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)
  • The last two points would really really really help Australians out!!!!!!!!!!!!!

[1, 2, 3, 4, 5].

  • 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).
  • email notification when Recording conflict (might as well include the option for AIM/Jabber notifications )
    • 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 sheduled 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 recordings. Long length MythTV recordings would automatically span multiple files similar to film rolls. Allows TV marathons, sporting events, etc to be broken up into manageable pieces.
  • Add support for "idle priority" recordings. This is perhaps a way to minimise 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 usefull 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 tommorow 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 usefull: 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.)
  • 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)
  • 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?

Commercial Detection

  • 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 expisodes. 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.
  • 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...)

Transcode Audio Passthrough

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

UPnP (Universal Plug and Play) server and client features

All 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 MediaPortal back-end, or a XBMC front-end togther with MythTV). For more information see MythTV developers notes on UPnP.

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


  • Not shure where this should be placed, but since it's mainly for media-clients i'll place it here... The feature that i would like to see is either that the backend could maintain a folder with softlinks (ie, the recorded shownames) to be used with media-players that dont support uPnP, like atleast the Kiss DP-1500 network player. Ideally it should be a userfs filesystem, but an easy hack should be to use softlinks, and with a userfs-fs it should be possible to even view live-tv via this.