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.
And if there is audio pid added when program starts (ie. AC3 or second mp2) couldn't vdr add it to stream "on the fly" and not cutting recording?
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.
And if there is audio pid added when program starts (ie. AC3 or second mp2) couldn't vdr add it to stream "on the fly" and not cutting recording?
I've said it before, and I'll repeat it: it's the broadcasters' fault! The PIDs must be set correctly _before_ a broadcast starts!
Of course you could change cChannel::SetPids() so that it doesn't set the CHANNELMOD_PIDS flag in case only the language codes are changed. However, this won't help in case of a change in PIDs during a broadcast, but then again this is a sign of bad broadcaster quality, and that they don't care about their viewers.
Klaus
Klaus Schmidinger wrote:
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.
And if there is audio pid added when program starts (ie. AC3 or second mp2) couldn't vdr add it to stream "on the fly" and not cutting recording?
I've said it before, and I'll repeat it: it's the broadcasters' fault! The PIDs must be set correctly _before_ a broadcast starts!
Of course you could change cChannel::SetPids() so that it doesn't set the CHANNELMOD_PIDS flag in case only the language codes are changed. However, this won't help in case of a change in PIDs during a broadcast, but then again this is a sign of bad broadcaster quality, and that they don't care about their viewers.
I believe YLE sends the change of pids correctly but as the recording has been usually started something like 2 minutes before the actual start, the break is inevitable.
Lauri Tischler wrote:
I believe YLE sends the change of pids correctly but as the recording has been usually started something like 2 minutes before the actual start, the break is inevitable.
Seems that I was wrong, according to log the change of pids appears 5 seconds after the change of running status, some examples... --- Apr 3 19:51:22 vdr2 vdr[11265]: channel 1 (YLE TV1) event 19:45 'Arto Nyberg' status 4 Apr 3 19:51:27 vdr2 vdr[11265]: changing pids of channel 1 from 512+128:650=eng:2321 to 512+128:650=fin:2321 --- Apr 3 20:10:25 vdr2 vdr[11265]: channel 2 (YLE TV2) event 20:05 'Oikeuden puolesta' status 4 Apr 3 20:10:30 vdr2 vdr[11265]: changing pids of channel 2 from 513+129:660=fin:2321 to 513+129:660=eng:2321 ---
On Sun, 3 Apr 2005, Klaus Schmidinger wrote:
I've said it before, and I'll repeat it: it's the broadcasters' fault! The PIDs must be set correctly _before_ a broadcast starts!
Well, the pids remain the same, but their descriptions change:
changing pids of channel 1 from 512+128:650=fin:2321 to 512+128:650=fra:2321
Of course you could change cChannel::SetPids() so that it doesn't set the CHANNELMOD_PIDS flag in case only the language codes are changed.
Could this be added into next VDR release?
-- rofa
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
--- channels.h 2005/05/06 13:47:06 1.27 +++ channels.h 2005/05/07 13:07:09 @@ -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 --- channels.c 2005/05/06 13:46:57 1.37 +++ channels.c 2005/05/07 13:07:27 @@ -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(); } }
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 ------------
-
Antti Hartikainen -
Klaus Schmidinger -
Lauri Tischler -
Markku Virtanen -
Rainer Zocholl -
Rolf Ahrenberg