VDR automatic channel update and recording annoyance.
Commit Message
Antti Hartikainen wrote:
> Hi.
>
> VDR:s automatic channel update while recording is very annoying and it's
> breaking few seconds of the recording.
>
> Some channels (like YLE in Finland) changes audio language for example
> from "fin" to "eng" when program starts. VDR detects there is change in
> channel information, stops recording, retunes to channel and starts
> recording again.
>
> This way there is always missing few seconds from the start of the
> recording. But on the other hand, this feature is a must. I like new
> channels to be added and information changed.
>
> But retuning on such minor issue (and breaking recording) is bad.
Please try the attached patch. With this it should no longer retune
if only the language code changes.
Klaus
Comments
Hello Klaus.
Can we have an indication in timer recording list if recordings
are conflicting i.e. not possible to record properly due to
different mux used for recordings and there is not
enough receiver cards present to do that?
The reason for this is that you can happily put any amount of
timed recordings without knowing if those overlapping recordings
can be done propery or not. Have lost some recordings when
I though those were in same mux but actually were not.
I'm using one single DVB-card and lost again more recordings when
channels were rearranged.
It would be very good feature to see from timers list that
when recordings are incorrectly timed.
VDR knows this so it should tell it to user as well!
Markku
Hello Klaus.
Another feature request.
Can we have acceptance in timers when pressing remote key BLUE
for recording on /off? Same as for yellow key when deleting recordings.
The reason for this is that I have lost several recordings when I have
incorrectly set first recording on list to OFF but not noticed it.
The use case is that you press remote key blue to activate
timers menu, The next pressing of same blue key changes the status
of timer at forst row and ther is only a small indication mark that tells this
status on or off.
Why you get too many pressings of blue key easily? Bad IR remote
receiving function, low batteries, bad orientation of receiver etc.
it happens very easily.
Putting a simple confirmation when changing
timer status on or off would solve this problem as said same functionality
than for yellow key already present.
Markku
markku.virtanen@phpoint.fi(Markku Virtanen) 07.05.05 21:36
>Hello Klaus.
>Another feature request.
>Can we have acceptance in timers when pressing remote key BLUE
>for recording on /off? Same as for yellow key when deleting
>recordings.
>The reason for this is that I have lost several recordings when I have
>incorrectly set first recording on list to OFF but not noticed it.
ACk.
I too hack" on blue, and then i don't know if the timer already was
activated or not.
>The use case is that you press remote key blue to activate
>timers menu, The next pressing of same blue key changes the status
>of timer at forst row and ther is only a small indication mark that
>tells this status on or off.
>Why you get too many pressings of blue key easily? Bad IR remote
>receiving function, low batteries, bad orientation of receiver etc.
>it happens very easily.
Too the blue key is not working while replay.
Sometimes VDR is not processing RC keys for 10seconds or more,
but LIRC(?) ques all key pressed...
>Putting a simple confirmation when changing
>timer status on or off would solve this problem as said same
>functionality than for yellow key already present.
Or give every key stroke a time code and discard all keystrokes
which where given in an other context...or are simply too old.
Rainer---<=====> Vertraulich
//
//
<=====>--------------ocholl, Kiel, Germany ------------
@@ -24,6 +24,7 @@
#define CHANNELMOD_ID 0x04
#define CHANNELMOD_CA 0x10
#define CHANNELMOD_TRANSP 0x20
+#define CHANNELMOD_LANGS 0x40
#define CHANNELMOD_RETUNE (CHANNELMOD_PIDS | CHANNELMOD_CA | CHANNELMOD_TRANSP)
#define CHANNELSMOD_NONE 0
@@ -389,15 +389,22 @@
}
}
-static bool IntArraysDiffer(const int *a, const int *b, const char na[][4] = NULL, const char nb[][4] = NULL)
+#define STRDIFF 0x01
+#define VALDIFF 0x02
+
+static int IntArraysDiffer(const int *a, const int *b, const char na[][4] = NULL, const char nb[][4] = NULL)
{
- int i = 0;
- while (a[i] && b[i]) {
- if (a[i] != b[i] || na && nb && strcmp(na[i], nb[i]) != 0)
- return true;
- i++;
- }
- return a[i] != b[i] || a[i] && na && nb && strcmp(na[i], nb[i]) != 0;
+ int result = 0;
+ for (int i = 0; a[i] || b[i]; i++) {
+ if (a[i] && na && nb && strcmp(na[i], nb[i]) != 0)
+ result |= STRDIFF;
+ if (a[i] != b[i])
+ result |= VALDIFF;
+ if (na && nb) fprintf(stderr, "%2d %5d %5d %-3s %-3s %d\n", i, a[i], b[i], na[i], nb[i], result);//XXX
+ if (!a[i] || !b[i])
+ break;
+ }
+ return result;
}
static int IntArrayToString(char *s, const int *a, int Base = 10, const char n[][4] = NULL)
@@ -418,10 +425,15 @@
void cChannel::SetPids(int Vpid, int Ppid, int *Apids, char ALangs[][4], int *Dpids, char DLangs[][4], int Tpid)
{
- bool modified = vpid != Vpid || ppid != Ppid || tpid != Tpid;
- if (!modified)
- modified = IntArraysDiffer(apids, Apids, alangs, ALangs) || IntArraysDiffer(dpids, Dpids, dlangs, DLangs);
- if (modified) {
+ int mod = CHANNELMOD_NONE;
+ if (vpid != Vpid || ppid != Ppid || tpid != Tpid)
+ mod |= CHANNELMOD_PIDS;
+ int m = IntArraysDiffer(apids, Apids, alangs, ALangs) | IntArraysDiffer(dpids, Dpids, dlangs, DLangs);
+ if (m & STRDIFF)
+ mod |= CHANNELMOD_LANGS;
+ if (m & VALDIFF)
+ mod |= CHANNELMOD_PIDS;
+ if (mod) {
char OldApidsBuf[(MAXAPIDS + MAXDPIDS) * 10 + 10]; // 10: 5 digits plus delimiting ',' or ';' plus optional '=cod', +10: paranoia
char NewApidsBuf[(MAXAPIDS + MAXDPIDS) * 10 + 10];
char *q = OldApidsBuf;
@@ -450,7 +462,7 @@
strn0cpy(dlangs[i], DLangs[i], 4);
}
tpid = Tpid;
- modification |= CHANNELMOD_PIDS;
+ modification |= mod;
Channels.SetModified();
}
}