Klaus Schmidinger wrote:
I asked once already, but you gave no answer.
Sorry, I had only very little time lately to go through the VDR ML
messages.
No prob
Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts. After all, they're not likely to change right in the middle of a movie, are
they?
I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages. I haven't yet recorded any that actually change languages in the middle of a show, but just wondering if there is a limit what you can and what you cannot change...
But then again, most broadcasters don't even get the running status in sync with the actual broadcasts, so how can we expect the PIDs to be set at the right time. Seems to me like there are a few monkeys sitting at a switchboard, plugging in cables randomly and every once in a while hitting the right spot ;-) I always thought that in today's digital playout centers things would be completely
computerized...
Yep, we have those here too :-)
But, this particular broadcaster seems to be top of the line. It's e.g. the only one I know of that is using DVB subtitles... Also with a little bit of syslog examination it looks like the event state is changed when the program start (even after the programme introduction), at most a second or two before (impossible to say more precisely as the data is buffered inside vdr and dvb drivers).
When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed.
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog). My next recording from that broadcaster is only next Saturday (that I know of having a gap every time), but based on the syslog now and before I guess this would help.
And it doesn't seem to be taking any more CPU than before on my really slow P2-350, but I only have a fraction of the number of channels you may have in satellite (around 130 here in cable).
Teemu
On Mon, 04 Apr 2005 02:03:09 +0300 Rantanen Teemu teemu.rantanen@tekla.com wrote:
Klaus Schmidinger wrote:
Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts. After all, they're not likely to change right in the middle of a movie, are
they?
I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages. I haven't yet recorded any that actually change languages in the middle of a show, but just wondering if there is a limit what you can and what you cannot change...
I sent a question about this to Digita (the company responsible for digitv-stuff in Finland) info address two weeks ago, but no response so far. They did forward it to "Digita Antenni-info" (antenna info), so I'm not holding my breath...
When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed.
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog). My next recording from that broadcaster is only next Saturday (that I know of having a gap every time), but based on the syslog now and before I guess this would help.
Thanks for the tip, I'll try that too! BTW, I get the gap during every YLE language change (IIRC), even during live-tv... so at least testing is simple :-)
Timo
On Mon, Apr 04, 2005 at 02:03:09AM +0300, Rantanen Teemu wrote:
Klaus Schmidinger wrote:
Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts.
I wonder whether this excerpt from iso13818-1 is of any significance to this discussion:
Annex C.5 What is a program?
The concept of a program has a precise definition within this standard. For a Transport stream the time base is defined by the PCR. This effectively creates a virtual channel within the Transport Stream.
Note that this is not the same definition as is commonly used in broadcasting, where a "program" is a collection of elementary streams not only with a common time base, but also with a common start and end time. A series of "broadcaster programs" (referred to in this annex as events) can be transmitted sequentially in a transport stream using the same program_number to create a "broadcasting conventional" TV channel (sometimes called a service).
While this excerpt creates even more confusion (it can be interpreted either way), it seems that 13818-1 tries to clarify this topic. Since I have only a copy of an old (1994) draft, I can not check what the wording in the final paper is. Can anyone check the final spec (or even better: post a URL where the final spec can be downloaded ;)
After all, they're not likely to change right in the middle of a movie, are they?
Oh, I would not be very surprised. Lots of movies use multiple languages.
I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages.
About two weeks ago there was a report about Einstein where repeatedly the reporter started a sentence in german and interviewed persons fullfilled the sentence in english. I have no clue whether the PIDs changed for that specific report.
But then again, most broadcasters don't even get the running status in sync with the actual broadcasts, so how can we expect the PIDs to be set at the right time. Seems to me like there are a few monkeys sitting at a switchboard, plugging in cables randomly and every once in a while hitting the right spot ;-) I always thought that in today's digital playout centers things would be completely computerized...
Klaus, are you that much convinced that the broadcasters are the problem that you start blaming on them?
See, there might be zillions of other reasons that could lead to the described effect. Just to name one (possible) reason: the code that constructs tables from sections might loose sections now-and-then. Such a bug would lead to the effect described here:
When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed.
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog).
BTW: Why is PMT_SCAN_TIMEOUT needed at all? I have not looked at the actual code, but the existence of such a timeout looks to me as if someone once noticed a problem with table reconstruction code and decided to cure the symptomps (construct table even when sections are still missing, based on a timeout) instead of curing the real cause (find the reason why sections get lost). Such a "cure" would be very consistent with the effect described above.
Just my 0.02eur. No pun intended.
On Mon, 04 Apr 2005 13:53:58 +0300 Timo Laitinen timolai@utu.fi wrote:
On Mon, 04 Apr 2005 02:03:09 +0300 Rantanen Teemu teemu.rantanen@tekla.com wrote:
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog). My next recording from that broadcaster is only next Saturday (that I know of having a gap every time), but based on the syslog now and before I guess this would help.
Thanks for the tip, I'll try that too! BTW, I get the gap during every YLE language change (IIRC), even during live-tv... so at least testing is simple :-)
I've tried this now, but not very successfully. The live-tv has still a gap, and the syslog gap is there too. In the recording, there is no gap (or a very short gap), but a bit of the stream is clearly missing. I didn't try with the timeout set to 0, though.
Then, as Klaus suggested, I started to play with cChannels::SetPids(), and removed the ALang and DLang comparisons from the "modified" definition, i.e.,
modified = IntArraysDiffer(apids, Apids) || IntArraysDiffer(dpids,Dpids);
This works fine, at least for the few tests I did. For programs with multiple languages (e.g., Euronews, some sports programs), and after such programs, the pid modify still stands, and a gap appears.
Now, the question is: is there any harm in making it this way? And what would happen to multi-language program recordings, if the test was removed completely? I also have no idea what the dpid stands for...
Timo
On Mon, 04 Apr 2005 13:53:58 +0300 Timo Laitinen timolai@utu.fi wrote:
Klaus Schmidinger wrote:
Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts. After all, they're not likely to change right in the middle of a movie, are
they?
I sent a question about this to Digita (the company responsible for digitv-stuff in Finland) info address two weeks ago, but no response so far. They did forward it to "Digita Antenni-info" (antenna info), so I'm not holding my breath...
Well lo and behold, they answered! They looked into it, and say that the PID changes "exactly at the program change", also when only the language code is changed. They also tested it with 3 set-top-boxes, with no problems.
So, if they are right, there's something wrong with vdr (although they called it a "feature" ;-) ). Any tips for debugging the problem (not sure if I have the time, at least until May, but maybe someone else?)?
BTW, I may also have found another problem. I tried to disable the pid scan by setting the updatechannels to 1, as it seems to bypass the setpids. An hour after a boot (which was due to other reasons), the computer crashed (vdr start 20:23:17, last log message before crash at 21:23:46, the plugin EPGSearch: search timer update finished)). After reboot, channels.conf was filled with zeros (and timers.conf and epgsearch.conf were empty). It may have been due to other issues and can also be EPGsearch problem (although... should it be able to cause a crash?), but I won't be able to re-test it before the weekend.
Timo
Josef Wolf wrote:
...
After all, they're not likely to change right in the middle of a movie, are they?
Oh, I would not be very surprised. Lots of movies use multiple languages.
Yes, but I don't think it would make any sense to toggle the APID's language code every time a sentence in a different language is spoken ;-)
I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages.
About two weeks ago there was a report about Einstein where repeatedly the reporter started a sentence in german and interviewed persons fullfilled the sentence in english. I have no clue whether the PIDs changed for that specific report.
As I said, I don't think this would make any sense.
But then again, most broadcasters don't even get the running status in sync with the actual broadcasts, so how can we expect the PIDs to be set at the right time. Seems to me like there are a few monkeys sitting at a switchboard, plugging in cables randomly and every once in a while hitting the right spot ;-) I always thought that in today's digital playout centers things would be completely computerized...
Klaus, are you that much convinced that the broadcasters are the problem that you start blaming on them?
Well, based on past experience I tend to ;-)
See, there might be zillions of other reasons that could lead to the described effect. Just to name one (possible) reason: the code that constructs tables from sections might loose sections now-and-then. Such a bug would lead to the effect described here:
When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed.
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog).
BTW: Why is PMT_SCAN_TIMEOUT needed at all? I have not looked at the actual code, but the existence of such a timeout looks to me as if someone once noticed a problem with table reconstruction code and decided to cure the symptomps (construct table even when sections are still missing, based on a timeout) instead of curing the real cause (find the reason why sections get lost). Such a "cure" would be very consistent with the effect described above.
The problem is that cPatFilter::Process() processes a table of PMT PIDs and in order to do so needs to set a filter for each of the PIDs in the table. After the filter has been set, it needs to wait until the data is received. Ok, this works fine as long as it is _guaranteed_ that for every entry in the table there will be actual data broadcast. As a matter of fact, my first implementation of this stuff didn't have this timeout, and promptly got stuck on a channel that had PMT PID entries, but didn't send data for at least one of them.
So I've added the PMT_SCAN_TIMEOUT, assuming that there won't be too many such broken channels, and that 10 seconds should be long enough for any data to arrive, but not too long so that things keep on running.
I assume that in Teemu's case there actually is such a broken table entry, which triggers the timeout (proven by him setting PMT_SCAN_TIMEOUT to 1 and observing that the problem was gone). So I'd still guess that it's the broadcaster's fault.
Maybe 10 seconds is a little long, but then again we would need to know the official repeat intervalls of this kind of data. I'm sure it's somewhere in the DVB standards, but I don't have it at hand right now. If somebody can come up with this number, I'd gladly set PMT_SCAN_TIMEOUT to a smaller value.
Nevertheless, somebody should either find out why (if at all) VDR hits PMT_SCAN_TIMEOUT unjustified - or tell that broadcaster not to send broken data.
Klaus
-
Josef Wolf -
Klaus Schmidinger -
Rantanen Teemu -
Timo Laitinen