Hi,
I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels.
vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans.
I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here.
The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out.
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Best Regards, Thomas
Thomas Bartschies wrote:
Hi,
I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels.
vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans.
I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here.
The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out.
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of
If VDR is currently replaying (or receiving in transfer mode from an other card) the primary card is available for recording as well as EPG scanning.
the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Edit cEITScanner::Process() so that it doesn't use the primary device.
Klaus
Am Mittwoch, 24. Januar 2007 22:38 schrieb Klaus Schmidinger:
Thomas Bartschies wrote:
Hi,
[snip]
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of
If VDR is currently replaying (or receiving in transfer mode from an other card) the primary card is available for recording as well as EPG scanning.
I forget to mention, that the problem only occurs when replaying a recording. Watching LiveTV by using LiveAC3 and even AC3 in transfer mode on encrypted channels works perfectly. So if the problem would be in the FW or driver, the problem would occur in LiveTV too, wouldn't it?
Is it possible that there are thread locking issues between the tuner and the replay thread, when a timeout occurs?
I had a nasty NTPL thread locking problem with the tuner routine for a long time, until a patch on this mailing list fixed it. It was called dvbtuner-one-mutex.diff and was applied by you somewhere around vdr 1.3.28. Without this vdr doesn't even start.
the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Edit cEITScanner::Process() so that it doesn't use the primary device.
How? Little hlp pls. ;-)
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 24 Jan 2007, at 22:01, Thomas Bartschies wrote:
Am Mittwoch, 24. Januar 2007 22:38 schrieb Klaus Schmidinger:
Thomas Bartschies wrote:
Hi,
[snip]
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of
If VDR is currently replaying (or receiving in transfer mode from an other card) the primary card is available for recording as well as EPG scanning.
I forget to mention, that the problem only occurs when replaying a recording. Watching LiveTV by using LiveAC3 and even AC3 in transfer mode on encrypted channels works perfectly. So if the problem would be in the FW or driver, the problem would occur in LiveTV too, wouldn't it?
I see similar problems here, caused by the DVB driver using too much kernel time when a card cannot tune a station.
My primary DVB device can tune all channels. My secondary cannot tune all, for some unknown reason. Thus I have set up the secondary DVB device as the main device used for normal TV viewing, since I don't want VDR to try to tune to get EPG data on that card. But when playing recordings, VDR uses the first available card, so the problem reappear.
There is a similar problem, if I try to record a channel on a card that cannot tune to the channel, VDR segfaults.
During the Storm Kyrill last week, my Sat dish got turned a bit, so DVB signal was down to 40%, which made the tuner (i have 2 cards) not to receive. In the logfile I saw that VDR tried to get a signal on both cards, as my VDR just started to do some recording stuff.
As I was tired from work, I didn't care about it, so I just wanted to watch, what's on my disk stored, but this turned out to be impossible. Got VDR segfaults, with restarts of VDR. So I killed my runvdr, edited by hand my timers, so no more recording occurred. After this, I was able to watch hard disk recordings.
Regards, Martin
___________ There is a similar problem, if I try to record a channel on a card that cannot tune to the channel, VDR segfaults.
Thomas Bartschies wrote:
Am Mittwoch, 24. Januar 2007 22:38 schrieb Klaus Schmidinger:
Thomas Bartschies wrote:
Hi,
[snip]
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of
If VDR is currently replaying (or receiving in transfer mode from an other card) the primary card is available for recording as well as EPG scanning.
I forget to mention, that the problem only occurs when replaying a recording. Watching LiveTV by using LiveAC3 and even AC3 in transfer mode on encrypted channels works perfectly. So if the problem would be in the FW or driver, the problem would occur in LiveTV too, wouldn't it?
Is it possible that there are thread locking issues between the tuner and the replay thread, when a timeout occurs?
I had a nasty NTPL thread locking problem with the tuner routine for a long time, until a patch on this mailing list fixed it. It was called dvbtuner-one-mutex.diff and was applied by you somewhere around vdr 1.3.28. Without this vdr doesn't even start.
the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Edit cEITScanner::Process() so that it doesn't use the primary device.
How? Little hlp pls. ;-)
Locate the lines
for (int i = 0; i < cDevice::NumDevices(); i++) { cDevice *Device = cDevice::GetDevice(i); if (Device) {
and change the last one to
if (Device && !Device->IsPrimaryDevice()) {
Klaus
I just want to add that I am experiencing the same problems here: short DD AC3 stream breaks during playback and a frontend tuning timeout message in the log at the same time. There is no problem with PCM audio or live TV.
I am using a single card system with TT 1.6 DVB-s, VDR 1.4.5 and latest Firmware F12623.
So I guess that my VDR does an EPG scan only during playback and that's when I get the problem. I will try to disable the EPG scan and see if anything changes.
Ondrej ...
Thomas Bartschies wrote:
Hi,
I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels.
vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans.
I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here.
The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out.
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Best Regards, Thomas
I tried to disable the EPG scan (EPG scan timeout set to 0) and couldn't actually see any audio disruptions any more in AC3. So the culprit really seems to be the EPG scan. But why does this problem only occur with AC3 audio? Any ideas?
Ondrej ...
Ondrej Wisniewski wrote:
I just want to add that I am experiencing the same problems here: short DD AC3 stream breaks during playback and a frontend tuning timeout message in the log at the same time. There is no problem with PCM audio or live TV.
I am using a single card system with TT 1.6 DVB-s, VDR 1.4.5 and latest Firmware F12623.
So I guess that my VDR does an EPG scan only during playback and that's when I get the problem. I will try to disable the EPG scan and see if anything changes.
Ondrej ...
Thomas Bartschies wrote:
Hi,
I'm experiencing the usual DD A3 stream breaks here. Now I have discovered that the epg scan seems to trigger them, by tuning to some channels.
vdr logs frontend tuning timeouts synchronously to the stream breaks my AV Receiver displays. They can only be caused by a background job like the epg scan. Also the timeouts occur on the primary card, which seem to be sometimes used to make scans.
I'm not sure if the tuning timeouts were caused because the channels are encrypted, or by invalid data in the channels.conf. But that should have no meaning here.
The timeouts can be caused by the firmware or driver, or in vdr by tuner thread locking issues. I need help to sort this out.
I have a three FF card system. Why does vdr use the Primary Card for scans anyway? Shouldn't all of this occur on a non-primary card all of the time? How can I force vdr to not use the primary device for PID,EPG and all other scans? At least for further testing.
Best Regards, Thomas
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Klaus Schmidinger -
martin -
Ondrej Wisniewski -
Thomas Bartschies -
Torgeir Veimo