diff options
| -rw-r--r-- | CONTRIBUTORS | 2 | ||||
| -rw-r--r-- | HISTORY | 2 | ||||
| -rw-r--r-- | README.developer | 82 | ||||
| -rw-r--r-- | README.vps | 137 | ||||
| -rw-r--r-- | menuitems.c | 10 |
5 files changed, 9 insertions, 224 deletions
diff --git a/CONTRIBUTORS b/CONTRIBUTORS index cda2ec5e..b798ebc8 100644 --- a/CONTRIBUTORS +++ b/CONTRIBUTORS @@ -1665,6 +1665,8 @@ Harald Milz <hm@seneca.muc.de> Marko Mäkelä <marko.makela@hut.fi> for making repeat keys be ignored when waiting for a keypress to cancel an operation for reporting that a menu was automatically closed when a replay ends + for suggesting to ignore k_Repeat when deciding whether the same key has been + pressed in string input fields Patrick Rother <krd-vdr@gulu.net> for reporting a bug in defining timers that only differ in the day of week @@ -4646,3 +4646,5 @@ Video Disk Recorder Revision History - Fixed a format string in recording.c to avoid a compiler warning on 64bit systems (thanks to Christian Wieninger for reporting, and Werner Schweer for pointing out that the 'z' modifier should be used here). +- Ignoring k_Repeat when deciding whether the same key has been pressed in string + input fields (based on a patch from Marko Mäkelä). diff --git a/README.developer b/README.developer deleted file mode 100644 index 4fe75c81..00000000 --- a/README.developer +++ /dev/null @@ -1,82 +0,0 @@ -Version 1.3.0 marks the beginning of a new developer version -of VDR, in which I am going to integrate functionality from -patches that have been written by various people for previous -versions of VDR. - -IMPORTANT NOTE: Beginning with version 1.3.0, VDR will automatically -=============== modify the 'channels.conf' file. Please run this version - of VDR in a controlled environment only, and work with - copies of all your config files! - -This version of VDR focuses on some improvements regarding -CAM support and, most important, the first step towards automatic -PID handling. Some things are still in a raw state, but at least -the program should now dynamically react on any changes in the -channel settings. - -Here's a list of the highlights - and what _not_ to expect yet -(but don't worry, these things will come soon ;-): - -- Automatic switching when PIDs are changed (e.g. for regional - programmes). -- There is no explicit transponder list yet, so you just - have to define one channel for a new transponder and VDR - will automatically detect all other channels on that transponder. -- New channels are added to the end of the channel list, so - it might be a good idea to add a line like - - :@1000 New channels - - to have them start at some high number. -- Improved CAM support. Channels with conditional access now automatically - use the device that contains the proper CAM. -- No NVOD support yet. - -Note that this is currently work in progress, so there may be some -areas that don't work as smooth as expected, yet. - -Known issues: -============= - -- The Setup/CICAM menu is currently without much meaning. - CA detection is done automatically. -- The channel "EURO1080" on Astra 19.2E currently broadcasts HDTV - test signals. Unfortunately, the full featured DVB cards crash - pretty ugly when tuned to that channel, so it might be a good idea - to have the channel definition - - EURO1080:12168:v:S19.2E:27500:308:256:0:FF:21100:1:1088:0 - - in your 'channels.conf' file. Note the Ca parameter 'FF' (255 in hex), - which gives this channel a non-existent Ca mode, so that it won't - be tuned to at all. If you really want to tune to this channel for - tests, do it on your own risk. -- The 'sky' plugin now temporarily uses Ca value 30 (this will be changed - later). -- Since the CA detection is now done automatically, a timer that starts - immediately after VDR has been launched and wants to record a CA channel - may not work. This will be changed later to make this work safely. - -What to test: -============= - -Apart from the usual general functionality, special attention should -be given to the following matters: - -- Does the automatic PID switching really work in all cases, especially - in conjunction with conditional access channels? -- Does CAM support work for all kinds of CAMs? - -Known bugs: -=========== - -- Sometimes a new channel is created with the wrong 'source' - parameter. This presumably happens when the transponder and source - are switched, and there is still an SDT data packet being processed. - The call to device->HasLock() in sections.c should fix this (and it - apparently does for most cases), but there must still be soemthing - wrong in that area. This may be fixed in 1.3.1 - please report if - it does still happen there. -- Sometimes the current channel gets re-tuned even though the channel - data of this channel didn't change (but that of an other channel did - change). diff --git a/README.vps b/README.vps deleted file mode 100644 index ee8909e6..00000000 --- a/README.vps +++ /dev/null @@ -1,137 +0,0 @@ -VPS (Video Programming Service) -=============================== - -Beginning with version 1.3.5 VDR supports the VPS method -of identifying programmes to record, and making sure they -are recorded in full length, even if they run longer than -initially specified or are shifted in time. - -Of course, the main prerequisite for this to work is that -the broadcasters actually provide the necessary data. In -particular these are - -- EPG data (well, obviously) -- the data for each event must contain the "Programme Identification Label" - descriptor, which contains the VPS timestamp for this programme -- the event data must provide and maintain the "Running Status" flag, - which indicates whether this programme is currently running or not. - -Currently only the German "Öffentlich Rechtliche" tv stations provide -the necessary VPS data, so this will work only for stations like "Das Erste", -"ZDF" and the like. - -Following is a step by step description of what happens for a VPS controlled -timer recording. First let's take a look at what the VDR user needs to do. - -VPS as seen by the VDR user: ----------------------------- - -When the VDR user sets up a timer that shall be under VPS control, there -are only two things that need to be done: - -1. Set the "Start" time to the actual VPS time as published in tv magazines. - Typically the VPS time is the same as the printed start time, unless - expliciltly specified otherwise. For instance, a tv magazine might print - - 20:15 Wetten, dass...? - (VPS = 20:14) - - In this case the timer would need to be set to 20:14. - -2. Set the "VPS" flag in the timer definition to "yes" in order to tell VDR - that this timer is to be handled under VPS control. This is no different - to old analog video recorders, where each timer has also had a separate - VPS flag. - -If the user sets up a timer from the "Schedule" menu, things are even simpler. -If the setup option "Recording/Use VPS" is set to "yes", any timer that is -programmed from an event that has VPS information will automatically be set -up as a VPS timer. - -IMPORTANT: In order for a recording to work under VPS control it is of -========== paramount importance that the start time is set to the actual - VPS time of that event, NOT some time a few minutes before the - event starts! If a timer is set to use VPS, and the time doesn't - match any event's VPS time, nothing will be recorded! - -VPS as seen by VDR: -------------------- - -The following things happen when VDR processes timers: - -- VDR regularly scans the EPG data and assigns events to the timers (see - cTimers::SetEvents() in VDR/timers.c). - This can be seen in the log file as - - timer 1 (15 1830-1900 'Neues') set to event 28.02.2004 18:30-18:59 (VPS: 28.02 18:30) 'neues' - -- When a VPS timer is asked whether it matches (i.e. whether a recording shall - be started), it checks whether it has an event assigned to it, and whether - that event has a running status of "starts in a few seconds" or "running" - (see cTimer::Matches(time_t t, bool Directly) in VDR/timers.c). This allows - the recording process to catch the entire programme, even if it runs longer - than initially advertised. It also works if it runs shorter or gets shifted. - -- When a VPS timer event is coming up (i.e. there are only a few minutes until - it starts, according to the related event data's start time - which may be - different than the VPS time!), VDR tunes a free DVB device to that transponder - (unless there is already a device tuned to that one) in order to make sure - that the event data (especially the "Running Status") will be up to date and - a change in the "Running status" flag will be seen immediately. This may - lead to the primary device being switched to a different channel if there - is no other free DVB device available. See the main program loop in VDR/vdr.c, - "Make sure VPS timers "see" their channel early enough:". - -Problems: ---------- - -- In order for a VPS controlled timer to function properly, it needs to "see" - any changes in the running status of its event. This means that one of the - DVB devices needs to be tuned to the proper transponder some time before - the actual start time of the event. However, this may result in an other - timer (with lower priority) to be stopped, because it occupies the DVB device - and has it tuned to a different transponder. - See "// Make sure VPS timers "see" their channel early enough:" in VDR/vdr.c. -TODO: - Something needs to be done to prevent two timers from repeatedly switching - the device between channels in such a situation. - -- If, for some reason, the driver doesn't deliver any more section data, a - VPS controlled timer will never see that the programme has started (or ended). -TODO: - Therefore some mechanism needs to be implemented that makes absolutely sure - we continuously receive at least the event data for the present event. - -Caveats: --------- - -Apparently VPS in digital broadcasting is still in an early state. Only few -tv stations actually support it, and other tv stations don't even handle the -"Running Status" correctly (which, by itself, would already be helpful, even -without VPS). - -Here's a list of things that are apparently done wrong by the individual -stations: - -- The German "Öffentlich Rechtliche" tv stations, although supporting VPS, - don't switch the "Running Status" of an upcoming broadcast to "starts in - a few seconds", but rather go directly from "unknown" or "not running" to - "running". This may result in a recording that misses the first few seconds - of the programme. -- The RTL group handles EPG events in a rather random way. They change event - IDs randomly, and switch the "Running Status" flag at times that are only - losely related to the actual events. For instance, if the "RTL aktuell" - programme starts at 18:45, they switch that event to "running" at about - 18:43. Or, even worse, if "Wer wird Millionär?" runs until 21:15, they - switch the _next_ programme to running (which implicitly set "Wer wird - Millionär?" to "not running) at around 21:11 - so anybody using that - information to control recording would not see the end of that programme. - -... more following as it comes up... - -Contact: --------- - -ARD Digital: http://www.ard-digital.de/home/index.php?id=16&languageid=1 -ZDF vision: http://www.zdf.de/ZDFde/inhalt/1/0,1872,1021601,00.html (select "zdfvision") - phone: 06131/706754 diff --git a/menuitems.c b/menuitems.c index e756e8df..ef7cccc3 100644 --- a/menuitems.c +++ b/menuitems.c @@ -4,7 +4,7 @@ * See the main source file 'vdr.c' for copyright information and * how to reach the author. * - * $Id: menuitems.c 1.42 2006/04/14 10:41:28 kls Exp $ + * $Id: menuitems.c 1.43 2006/04/23 11:39:48 kls Exp $ */ #include "menuitems.h" @@ -351,10 +351,10 @@ char cMenuEditStrItem::Inc(char c, bool Up) eOSState cMenuEditStrItem::ProcessKey(eKeys Key) { - bool SameKey = Key == lastKey; + bool SameKey = NORMALKEY(Key) == lastKey; if (Key != kNone) - lastKey = Key; - else if (!newchar && k0 <= NORMALKEY(lastKey) && NORMALKEY(lastKey) <= k9 && autoAdvanceTimeout.TimedOut()) { + lastKey = NORMALKEY(Key); + else if (!newchar && k0 <= lastKey && lastKey <= k9 && autoAdvanceTimeout.TimedOut()) { AdvancePos(); newchar = true; currentChar = NULL; @@ -460,7 +460,7 @@ eOSState cMenuEditStrItem::ProcessKey(eKeys Key) } if (!currentChar || !*currentChar || *currentChar == '\t') { // find the beginning of the character map entry for Key - int n = Key - k0; + int n = NORMALKEY(Key) - k0; currentChar = charMap; while (n > 0 && *currentChar) { if (*currentChar++ == '\t') |