summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--CONTRIBUTORS2
-rw-r--r--HISTORY2
-rw-r--r--README.developer82
-rw-r--r--README.vps137
-rw-r--r--menuitems.c10
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
diff --git a/HISTORY b/HISTORY
index 0271131f..026fe79a 100644
--- a/HISTORY
+++ b/HISTORY
@@ -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')