2014-05-11, 08:28
What you are saying makes sense and points to an issue of vdr. Recording is done by vdr only. I try to give some background information for you to get a notion of what's happening here.
The data is broadcasted as mpegts. Video, audio, subs, text is sent in small packets of 188bytes identified by a PID (packet identifier). On a given frequency there may be many PIDs of different channels. In order to know what PIDs belong to a channel there is PAT/PMT. Those tables define what PIDs belong to a service id of a program. Take a look into channels.conf (http://www.vdr-wiki.de/wiki/index.php/Vd...9#CHANNELS). vdr parses PAT/PMT and writes the PIDs into channels.conf. If UpdateChannels (setup.conf) is > 3, vdr updates those PIDs.
When watching live tv VNSI handles this. You tune to a channels, vnsi waits for a valid PAT/PMT, parses PIDs, and tells vdr what PIDs it wants to receive. Now the tricky part: PIDs may change. Suppose a movie starts and the broadcaster adds an additional audio and subtitle stream. vnsi detects this but there is a weakness in design of vdr. It does not allow to dynamically add or remove PIDs once the receiver is attached to the dvb device. VNSI needs to detach/attach, then signal XBMC a change of streams so XBMC can open required decoders.
When it comes to recordings all is handled by vdr. We only set a timer which tells vdr what to start recording of the desired channel. When the time comes vdr will start recording the PIDs associated to a channels (without teletext) at this time. I have not looked into vdr code but I think it misses any PID added later. Means if you start your recording too early or you don't allow update of PIDs, your recoding does not contain those streams.
The data is broadcasted as mpegts. Video, audio, subs, text is sent in small packets of 188bytes identified by a PID (packet identifier). On a given frequency there may be many PIDs of different channels. In order to know what PIDs belong to a channel there is PAT/PMT. Those tables define what PIDs belong to a service id of a program. Take a look into channels.conf (http://www.vdr-wiki.de/wiki/index.php/Vd...9#CHANNELS). vdr parses PAT/PMT and writes the PIDs into channels.conf. If UpdateChannels (setup.conf) is > 3, vdr updates those PIDs.
When watching live tv VNSI handles this. You tune to a channels, vnsi waits for a valid PAT/PMT, parses PIDs, and tells vdr what PIDs it wants to receive. Now the tricky part: PIDs may change. Suppose a movie starts and the broadcaster adds an additional audio and subtitle stream. vnsi detects this but there is a weakness in design of vdr. It does not allow to dynamically add or remove PIDs once the receiver is attached to the dvb device. VNSI needs to detach/attach, then signal XBMC a change of streams so XBMC can open required decoders.
When it comes to recordings all is handled by vdr. We only set a timer which tells vdr what to start recording of the desired channel. When the time comes vdr will start recording the PIDs associated to a channels (without teletext) at this time. I have not looked into vdr code but I think it misses any PID added later. Means if you start your recording too early or you don't allow update of PIDs, your recoding does not contain those streams.