frodovdr/vdr
1
0
Fork 0
mirror of https://github.com/VDR4Arch/vdr.git synced 2023-10-10 13:36:52 +02:00
Code Issues Releases Wiki Activity

Ignoring k_Repeat when deciding whether the same key has been pressed in string input fields

Browse Source
This commit is contained in:
Klaus Schmidinger 2006-04-23 11:43:54 +02:00
parent 42b2676d82
commit b37a4d3c7a
5 changed files with 9 additions and 224 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTORS
View File

@ -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

2
HISTORY
View File

@ -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ä).

82
README.developer
View File

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

137
README.vps
View File

@ -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

10
menuitems.c
View File

@ -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')