Hi all,
I've again a problem with the mysterious Errormessage "ERROR: video data stream broken".
First of all I try to explain the setup of the friend of mine, who has the Problem... He has one PC with linvdr and VDR version 1.3.34 with 3 Cards: 2x FF cards and 1x LBudget card There are 2 instances of vdr running, the first instance has one FF card and one LB card. The second instance has the remaining FF card.
Everything is doing well UNTIL a recording starts. After 30 seconds the vdr instance which is recording brings that VDSB ERROR: "ERROR: video data stream broken" and an emergency exit is done.
This Error appears 90% of the time.... the rest 10% all is doing well...
Can anyone explain why this error occurs? Or what to do to solve the Problem?
The logfile is attached.
Greets Patrick
On Thu, 29 Dec 2005 18:18:54 +0100 "Patrick Maier" maierp@informatik.tu-muenchen.de wrote:
Hi all,
I've again a problem with the mysterious Errormessage "ERROR: video data stream broken".
[...]
From the attached logs:
Dec 29 15:14:54 linvdr user.debug vdr[1142]: switching device 2 to channel 30 Dec 29 15:14:54 linvdr user.info vdr[1142]: timer 1 (30 1514-2114 '@TITLE EPISODE') start Dec 29 15:14:54 linvdr user.debug vdr[1142]: Title: 'Menschen 2005' Subtitle: '' Dec 29 15:14:54 linvdr user.info vdr[1142]: executing '/usr/bin/noadcall.sh before "/video0/ @Menschen_2005/2005-12-29.15.14.50.50.rec"'
[...]
Dec 29 15:14:54 linvdr user.info vdr[1142]: record /video0/@Menschen_2005/2005-12-29.15.14.50.50.rec Dec 29 15:14:54 linvdr user.debug vdr[1142]: creating directory /video0/@Menschen_2005 Dec 29 15:14:54 linvdr user.debug vdr[1142]: creating directory /video0/ @Menschen_2005/2005-12-29.15.14.50.50.rec Dec 29 15:14:54 linvdr user.debug vdr[1142]: recording to '/video0/ @Menschen_2005/2005-12-29.15.14.50.50.rec/001.vdr'
You seem to have Noad running on the recording _before_ it has even started! Are you sure this is wise?
Dec 29 15:15:01 linvdr cron.notice crond[1214]: USER root pid 2582 cmd convert.pl -q -s
What is this? Could it also interfere with the recording?
Dec 29 15:15:19 linvdr user.info vdr[1142]: timer 1 (30 1514-2114 '@Menschen 2005') set to event Don 29.12.2005 15:15-17:15 (VPS: 29.12 15:15) 'Menschen 2005' Dec 29 15:15:21 linvdr user.info vdr[1179]: channel 30 (ZDFdokukanal) event 15:15 'Menschen 2005' status 4 Dec 29 15:15:25 linvdr user.err vdr[2580]: ERROR: video data stream broken
-- Niko Mikkilä
From: "Niko Mikkila" nm@phnet.fi
"Patrick Maier" maierp@informatik.tu-muenchen.de wrote:
I've again a problem with the mysterious Errormessage "ERROR: video data stream broken".
You seem to have Noad running on the recording _before_ it has even started! Are you sure this is wise?
Yes, because of this: Dec 29 15:14:54 linvdr user.info noad[2579]: wait 60 secs for vdr creating directory After 60 Seconds noad starts to convert and then the recording exists.
Dec 29 15:15:01 linvdr cron.notice crond[1214]: USER root pid 2582 cmd convert.pl -q -s
What is this? Could it also interfere with the recording?
This should not interfere with the recording...
Dec 29 15:15:19 linvdr user.info vdr[1142]: timer 1 (30 1514-2114 '@Menschen 2005') set to event Don 29.12.2005 15:15-17:15 (VPS: 29.12 15:15) 'Menschen 2005' Dec 29 15:15:21 linvdr user.info vdr[1179]: channel 30 (ZDFdokukanal) event 15:15 'Menschen 2005' status 4 Dec 29 15:15:25 linvdr user.err vdr[2580]: ERROR: video data stream broken
Greetz Patrick
Patrick Maier wrote:
I've again a problem with the mysterious Errormessage "ERROR: video data stream broken".
First of all I try to explain the setup of the friend of mine, who has the Problem... He has one PC with linvdr and VDR version 1.3.34 with 3 Cards: 2x FF cards and 1x LBudget card
The typical base for the feared VDSB error...
The most common chain of trouble is this: VDR uses the budget card to do EPG scan as long as the second card is idle. Due to unknown reasons the frequent channel changes from one transponder to the next suddenly cause the budget card driver to hang, and no channel is tunable any more. This doesn't cause any error messages, because EPG scan is a low-priority task and mostly ignores errors. As soon as the next recording starts, this tuning trouble will become more critical, and VDR does an emergency exit to reload the DVB driver, that brings the card back to life (for most users at least).
Some hints: - Upgrade or downgrade driver and/or firmware - IRQ's may be part of the problem, so try to give an own irq to the budget card - Disabling EPG scan helps
The reasons behind VDSB are very complex, and not all aspects are known. Some people suffer massively from it, others not at all, with identical setups. Solutions that work for one case may not work for other cases, thats making it difficult to fix it. Do some searching on the list and at vdrportal to get more info.
Cheers,
Udo
Hi,
Udo Richter wrote:
I've again a problem with the mysterious Errormessage "ERROR: video data stream broken".
First of all I try to explain the setup of the friend of mine, who has the Problem... He has one PC with linvdr and VDR version 1.3.34 with 3 Cards: 2x FF cards and 1x LBudget card
The typical base for the feared VDSB error...
The most common chain of trouble is this: VDR uses the budget card to do EPG scan as long as the second card is idle. Due to unknown reasons the frequent channel changes from one transponder to the next suddenly cause the budget card driver to hang, and no channel is tunable any more. This doesn't cause any error messages, because EPG scan is a low-priority task and mostly ignores errors. As soon as the next recording starts, this tuning trouble will become more critical, and VDR does an emergency exit to reload the DVB driver, that brings the card back to life (for most users at least).
To prove this, would you please try the attached patch (it's a simplified approach regarding my earlier posts). In DiSEqC setup's it repeats the DiSEqC message and retunes, if the tuner doesn't get a lock within 1000 ms or after loosing the lock for 1000 ms.
In my setup with just two budget cards and a channels.conf with some outdated entries, I get log messages regarding tuning when EPG scan comes across such channels.
Some hints:
- Upgrade or downgrade driver and/or firmware
- IRQ's may be part of the problem, so try to give an own irq to the
budget card
- Disabling EPG scan helps
The reasons behind VDSB are very complex, and not all aspects are known. Some people suffer massively from it, others not at all, with identical setups. Solutions that work for one case may not work for other cases, thats making it difficult to fix it. Do some searching on the list and at vdrportal to get more info.
Bye.
Hi Reinhard,
Reinhard Nissl schrieb:
To prove this, would you please try the attached patch (it's a simplified approach regarding my earlier posts). In DiSEqC setup's it repeats the DiSEqC message and retunes, if the tuner doesn't get a lock within 1000 ms or after loosing the lock for 1000 ms.
I applied this patch on Dec. 30th. While I had UPT, VDSB and No-lock errors at least once a day before that, I had none after that.
It works. At least for me.
Martin
Martin Schoenbeck wrote:
Hi Reinhard,
Reinhard Nissl schrieb:
To prove this, would you please try the attached patch (it's a simplified approach regarding my earlier posts). In DiSEqC setup's it repeats the DiSEqC message and retunes, if the tuner doesn't get a lock within 1000 ms or after loosing the lock for 1000 ms.
I applied this patch on Dec. 30th. While I had UPT, VDSB and No-lock errors at least once a day before that, I had none after that.
It works. At least for me.
Martin
Can you please test with the modified patch I have posted here today? That's the version that will go into VDR 1.3.38.
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Can you please test with the modified patch I have posted here today? That's the version that will go into VDR 1.3.38.
I saw it after posting about Reinhard's patch and activated it yesterday night. Since then I have a huge amount of Jan 4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock Jan 4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
messages. About every 5 to 10 messages the same appears with frontend 2. I had no restarts up to now, even after starting a recording, which would have induced a restart for sure before.
I must admit, that I installed Reinhard's patch together with 1.3.37, so theoretically it's possible, that the restarts are cured by something else, changed in 1.3.37.
Martin
An addition:
Martin Schoenbeck schrieb:
I saw it after posting about Reinhard's patch and activated it yesterday night. Since then I have a huge amount of Jan 4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock Jan 4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
messages. About every 5 to 10 messages the same appears with frontend 2. I had no restarts up to now, even after starting a recording, which would have induced a restart for sure before.
Primary device is 1, there are three devices.
And I just found a restart on yesterday evening, after posting, that there were none and before installing your patch:
Jan 3 20:10:02 saturn vdr[4496]: ERROR: frontend 1 timed out while tuning - re-tuning Jan 3 20:10:05 saturn last message repeated 3 times Jan 3 20:10:06 saturn vdr[4403]: ERROR: device 2 has no lock, can't attach receiver! Jan 3 20:10:06 saturn vdr[4403]: initiating emergency exit
Martin
And a second addition:
Martin Schoenbeck schrieb:
Jan 3 20:10:02 saturn vdr[4496]: ERROR: frontend 1 timed out while tuning - re-tuning Jan 3 20:10:05 saturn last message repeated 3 times Jan 3 20:10:06 saturn vdr[4403]: ERROR: device 2 has no lock, can't attach receiver! Jan 3 20:10:06 saturn vdr[4403]: initiating emergency exit
I activated the 'WAIT_FOR_TUNER_LOCK' and also inserted an immediate emergency restart, as soon as there was no lock, because in former versions, this never was cured without driver reload. I now removed the emergency restart, to see, whether it is perhaps cured by the patch.
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Can you please test with the modified patch I have posted here today? That's the version that will go into VDR 1.3.38.
I saw it after posting about Reinhard's patch and activated it yesterday night. Since then I have a huge amount of Jan 4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock Jan 4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
messages. About every 5 to 10 messages the same appears with frontend 2. I had no restarts up to now, even after starting a recording, which would have induced a restart for sure before.
I must admit, that I installed Reinhard's patch together with 1.3.37, so theoretically it's possible, that the restarts are cured by something else, changed in 1.3.37.
Martin
Please test the new patch I've posted under "VDR-1.3.37: retuning -- possibly a fix for VDSB".
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Please test the new patch I've posted under "VDR-1.3.37: retuning -- possibly a fix for VDSB".
Now it only shows up numerous
Jan 4 22:27:25 saturn vdr[10765]: ERROR: frontend 2 timed out while tuning
with all three frontends. But no restarts.
Yes, I used the vdr.1.3.37-tunertimeout4.diff
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Please test the new patch I've posted under "VDR-1.3.37: retuning -- possibly a fix for VDSB".
Now it only shows up numerous
Jan 4 22:27:25 saturn vdr[10765]: ERROR: frontend 2 timed out while tuning
with all three frontends. But no restarts.
Strange - I haven't had a single error message since today afternoon with the latest version of the patch. And I did some heavy channel hopping with transfer modes, recordings and replaying.
Yes, I used the vdr.1.3.37-tunertimeout4.diff
What kind of devices do you have (DVB-S, -C or -T)?
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Strange - I haven't had a single error message since today afternoon with the latest version of the patch. And I did some heavy channel hopping with transfer modes, recordings and replaying.
It may be interesting, that any time only two frontends are reported. Normally frontend 1 and 2, also 1 and 2 if recording. As soon as a replay is started, it moves over to 0 and 2. If two recordings are running, the messages stop.
Primary DVB is 1.
Yes, I used the vdr.1.3.37-tunertimeout4.diff
What kind of devices do you have (DVB-S, -C or -T)?
Three dvb-s card, one of them a budget card (IIRC).
Dec 20 11:05:36 saturn kernel: DVB: registering new adapter (Siemens/Technotrend/Hauppauge PCI rev1.3). Dec 20 11:05:36 saturn kernel: DVB: registering frontend 0:0 (Grundig 29504-491, (TDA8083 based))...
Dec 20 11:05:38 saturn kernel: DVB: registering new adapter (Technotrend/Hauppauge PCI rev2.1). Dec 20 11:05:38 saturn kernel: probe_tuner: try to attach to Technotrend/Hauppauge PCI rev2.1 Dec 20 11:05:39 saturn kernel: /usr/local/src/linuxtv-dvb-1.1.1/build-2.6/stv0299.c: setup for tuner BSRU6, TDQB-S00x Dec 20 11:05:39 saturn kernel: DVB: registering frontend 1:0 (STV0299/TSA5059/SL1935 based)...
Dec 20 11:05:41 saturn kernel: DVB: registering new adapter (TT-Budget/WinTV-NOVA-CI PCI). Dec 20 11:05:41 saturn kernel: probe_tuner: try to attach to TT-Budget/WinTV-NOVA-CI PCI Dec 20 11:05:41 saturn kernel: /usr/local/src/linuxtv-dvb-1.1.1/build-2.6/stv0299.c: setup for tuner SU1278 (TSA5059 synth) on TechnoTrend hardware Dec 20 11:05:41 saturn kernel: DVB: registering frontend 2:0 (STV0299/TSA5059/SL1935 based)...
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Strange - I haven't had a single error message since today afternoon with the latest version of the patch. And I did some heavy channel hopping with transfer modes, recordings and replaying.
It may be interesting, that any time only two frontends are reported. Normally frontend 1 and 2, also 1 and 2 if recording. As soon as a replay is started, it moves over to 0 and 2. If two recordings are running, the messages stop.
Primary DVB is 1.
Yes, I used the vdr.1.3.37-tunertimeout4.diff
Are you absolutely, postitively, sure about that?
I'm just asking because I can't see where this problem might come from...
Is there a particular sequence of actions necessary to reproduce this?
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Martin Schoenbeck wrote:
Yes, I used the vdr.1.3.37-tunertimeout4.diff
Are you absolutely, postitively, sure about that?
Absolutely. Positively. I doublechecked, that I really used that patch, before sending my last posting and now also checked, that it made it into dvbdevice.c and that dvbdevice.o and vdr were made after that. ;-)
I'm just asking because I can't see where this problem might come from...
Is there a particular sequence of actions necessary to reproduce this?
May it possibly connected with my earlier mentioned activating of WAIT_FOR_TUNER_LOCK? Do I have to remove it now?
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Martin Schoenbeck wrote:
Yes, I used the vdr.1.3.37-tunertimeout4.diff
Are you absolutely, postitively, sure about that?
Absolutely. Positively. I doublechecked, that I really used that patch, before sending my last posting and now also checked, that it made it into dvbdevice.c and that dvbdevice.o and vdr were made after that. ;-)
I'm just asking because I can't see where this problem might come from...
Is there a particular sequence of actions necessary to reproduce this?
May it possibly connected with my earlier mentioned activating of WAIT_FOR_TUNER_LOCK? Do I have to remove it now?
Martin
Since this is not set by default (and so I don't have it set here) this might be worth testing.
Klaus
me again,
Martin Schoenbeck schrieb:
Hi Klaus,
Klaus Schmidinger schrieb:
Since this is not set by default (and so I don't have it set here) this might be worth testing.
Ok, I did it. But _you_ speak to my wife, if a recording of zero length files is created again. ;-)
It didn't change anything. At least the timeout reports remain.
Martin
Martin Schoenbeck wrote:
me again,
Martin Schoenbeck schrieb:
Hi Klaus,
Klaus Schmidinger schrieb:
Since this is not set by default (and so I don't have it set here) this might be worth testing.
Ok, I did it. But _you_ speak to my wife, if a recording of zero length files is created again. ;-)
It didn't change anything. At least the timeout reports remain.
Martin
Please replace the cDvbTuner::Action() function with the following version (add the lines marked with XXX), run VDR, and when it logs timeouts please send me the log excerpt.
Klaus
void cDvbTuner::Action(void) { cTimeMs Timer; bool LostLock = false; fe_status_t Status = (fe_status_t)0; while (Running()) { fe_status_t NewStatus; if (GetFrontendStatus(NewStatus, 10)) Status = NewStatus; cMutexLock MutexLock(&mutex); switch (tunerStatus) { case tsIdle: break; case tsSet: dsyslog("TUNER %d: tsSet", cardIndex);//XXX tunerStatus = SetFrontend() ? tsTuned : tsIdle; Timer.Set(tuneTimeout); continue; case tsTuned: dsyslog("TUNER %d: tsTuned", cardIndex);//XXX if (Timer.TimedOut()) { dsyslog("TUNER %d: tsTuned - timeout", cardIndex);//XXX tunerStatus = tsSet; diseqcCommands = NULL; if (time(NULL) - lastTimeoutReport > 60) { // let's not get too many of these esyslog("ERROR: frontend %d timed out while tuning", cardIndex); lastTimeoutReport = time(NULL); } continue; } case tsLocked: if (Status & FE_REINIT) { tunerStatus = tsSet; diseqcCommands = NULL; esyslog("ERROR: frontend %d was reinitialized", cardIndex); lastTimeoutReport = 0; continue; } else if (Status & FE_HAS_LOCK) { if (tunerStatus != tsLocked) dsyslog("TUNER %d: tsLocked", cardIndex);//XXX if (LostLock) { esyslog("frontend %d regained lock", cardIndex); LostLock = false; } tunerStatus = tsLocked; locked.Broadcast(); lastTimeoutReport = 0; } else if (tunerStatus == tsLocked) { LostLock = true; esyslog("ERROR: frontend %d lost lock", cardIndex); tunerStatus = tsTuned; Timer.Set(lockTimeout); lastTimeoutReport = 0; continue; } }
if (ciHandler) ciHandler->Process(); if (tunerStatus != tsTuned) newSet.TimedWait(mutex, 1000); } }
Hi Klaus,
Klaus Schmidinger schrieb:
Please replace the cDvbTuner::Action() function with the following version (add the lines marked with XXX), run VDR, and when it logs timeouts please send me the log excerpt.
Jan 5 23:09:28 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:09:28 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:28 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:09:29 saturn last message repeated 15 times Jan 5 23:09:29 saturn vdr[14257]: TUNER 1: tsLocked Jan 5 23:09:29 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:31 saturn last message repeated 180 times Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned - timeout Jan 5 23:09:31 saturn vdr[14260]: ERROR: frontend 2 timed out while tuning Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:09:49 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:09:49 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:09:50 saturn last message repeated 16 times Jan 5 23:09:50 saturn vdr[14257]: TUNER 1: tsLocked Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:10:10 saturn last message repeated 15 times Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsLocked
is that enough, or do you want more logging?
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Please replace the cDvbTuner::Action() function with the following version (add the lines marked with XXX), run VDR, and when it logs timeouts please send me the log excerpt.
Jan 5 23:09:28 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:09:28 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:28 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:09:29 saturn last message repeated 15 times Jan 5 23:09:29 saturn vdr[14257]: TUNER 1: tsLocked Jan 5 23:09:29 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:31 saturn last message repeated 180 times Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned - timeout Jan 5 23:09:31 saturn vdr[14260]: ERROR: frontend 2 timed out while tuning Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:31 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:09:49 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:09:49 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:09:49 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:09:50 saturn last message repeated 16 times Jan 5 23:09:50 saturn vdr[14257]: TUNER 1: tsLocked Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsSet Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsSet Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsTuned Jan 5 23:10:10 saturn vdr[14260]: TUNER 2: tsLocked Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsTuned Jan 5 23:10:10 saturn last message repeated 15 times Jan 5 23:10:10 saturn vdr[14257]: TUNER 1: tsLocked
is that enough, or do you want more logging?
Martin
Have you edited this log? I'm missing the "switching to channel ..." messages. How do you actually set both devices at the same time?
Anyway, apparently there just is no lock within the two seconds tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value. Let me know what's the smallest value that just doesn't give you the timeout messages any more.
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Have you edited this log? I'm missing the "switching to channel ..." messages. How do you actually set both devices at the same time?
Nobody is switching channels then. Perhaps the EPG-Scan is running, but AFAIK not on two cards. We see and hear under certain conditions (I assume, it happens, when then retuning is on the primary device) sort of glitches any several seconds. But these glitches are some milliseconds, not two seconds.
It seems to be retuning just for fun. ;-)
Anyway, apparently there just is no lock within the two seconds tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value. Let me know what's the smallest value that just doesn't give you the timeout messages any more.
I took 4 seconds and will report.
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Have you edited this log? I'm missing the "switching to channel ..." messages. How do you actually set both devices at the same time?
Nobody is switching channels then. Perhaps the EPG-Scan is running, but
Of course, that's what it is - I should have seen that by the 20 seconds interval.
AFAIK not on two cards. We see and hear under certain conditions (I assume, it happens, when then retuning is on the primary device) sort of glitches any several seconds. But these glitches are some milliseconds, not two seconds.
Is that a new effect, caused by the tuner timeout patch? If so, was it also there with Reinhard's original patch?
It seems to be retuning just for fun. ;-)
Anyway, apparently there just is no lock within the two seconds tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value. Let me know what's the smallest value that just doesn't give you the timeout messages any more.
I took 4 seconds and will report.
Ok.
Klaus
Klaus Schmidinger wrote:
Nobody is switching channels then. Perhaps the EPG-Scan is running, but
Of course, that's what it is - I should have seen that by the 20 seconds interval.
I've also tested the patch, and I'm getting lost/regained lock and timed out errors roughly every half hour for about 1min, unless a recording blocks the second device. Has been that way since Reinhard's first patch, however my second card has a known issue with low-band transponders.
Cheers,
Udo
Hi Klaus,
Klaus Schmidinger schrieb:
Of course, that's what it is - I should have seen that by the 20 seconds interval.
Ok, so the timeouts are OK, right?
AFAIK not on two cards. We see and hear under certain conditions (I assume, it happens, when then retuning is on the primary device) sort of glitches any several seconds. But these glitches are some milliseconds, not two seconds.
Is that a new effect, caused by the tuner timeout patch? If so, was it also there with Reinhard's original patch?
I didn't notice it with Reinhard's patch, but I'm not sure about that. I noticed a short distortion this morning at a time, where tuner 1 and tuner 2 announced timeouts, but AFAIK the primaryDVB 1 uses tuner 0, isn't it? And there were no entries at all with tuner 0 until we started a recording.
I took 4 seconds and will report.
Ok.
The timeouts didn't go, but I assume, that's normal, given the EPG scan scanning. Is the EPG scan running around the clock, if there is a free device other than the primary device?
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Of course, that's what it is - I should have seen that by the 20 seconds interval.
Ok, so the timeouts are OK, right?
AFAIK not on two cards. We see and hear under certain conditions (I assume, it happens, when then retuning is on the primary device) sort of glitches any several seconds. But these glitches are some milliseconds, not two seconds.
Is that a new effect, caused by the tuner timeout patch? If so, was it also there with Reinhard's original patch?
I didn't notice it with Reinhard's patch, but I'm not sure about that. I noticed a short distortion this morning at a time, where tuner 1 and tuner 2 announced timeouts, but AFAIK the primaryDVB 1 uses tuner 0, isn't it? And there were no entries at all with tuner 0 until we started a recording.
Maybe there's a problem with your multiswitch? When the second or third device changes the transponder, there shouldn't be any interference with the first device.
I took 4 seconds and will report.
Ok.
The timeouts didn't go, but I assume, that's normal, given the EPG scan scanning. Is the EPG scan running around the clock, if there is a free device other than the primary device?
Yes.
I have attached a slightly modified version of the patch, which avoids error messages like
ERROR (dvbdevice.c,157): Value too large for defined data type
when clearing the event queue. It also returns the current frontend status even if there was no event, and logs the channel number and transponder in case of a timeout. As far as I can see the timeouts always happen on transponders that are currently not broadcasting, or use very low symbol rates, which my full featured second device can't handle.
Klaus
I controlled for safety's sake still times dvbdevice.c against the original. I have still the Patch:
-------------------------------------------- //XXX workaround for addition live audio PIDs: if (ciHandler) { ciHandler->SetPid(Channel->Apid(1), true); ciHandler->SetPid(Channel->Dpid(0), true); } --------------------------------------------
in it.
Is still necessary?
Thomas
PS: I exchanged the Patch 4 against 5. But yesterday unfortunately not much time had. Today the long term test (with many recordings) comes back.
Thomas Rausch wrote:
I controlled for safety's sake still times dvbdevice.c against the original. I have still the Patch:
//XXX workaround for addition live audio PIDs: if (ciHandler) { ciHandler->SetPid(Channel->Apid(1), true); ciHandler->SetPid(Channel->Dpid(0), true); }
in it.
Is still necessary?
Yes, it is. Since there are still several problems to solve with multiple CAM recordings, it will stay this way for version 1.4.
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
Maybe there's a problem with your multiswitch? When the second or third device changes the transponder, there shouldn't be any interference with the first device.
I don't know. But the switching did occur before this patch, too, didn't it? I'll investigate further.
I have attached a slightly modified version of the patch, which avoids error messages like
ERROR (dvbdevice.c,157): Value too large for defined data type
when clearing the event queue. It also returns the current frontend status even if there was no event, and logs the channel number and transponder in case of a timeout. As far as I can see the timeouts always happen on transponders that are currently not broadcasting, or use very low symbol rates, which my full featured second device can't handle.
This additional output makes it clearer: what is channel 0? And 'Al Jazeera' or a program a channel 1673 indeed is nothing, I regularly need to receive. ;-)
At least this UPT and VDSB, which annoy me since 1.3.xx, have gone.
Martin
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Maybe there's a problem with your multiswitch? When the second or third device changes the transponder, there shouldn't be any interference with the first device.
I don't know. But the switching did occur before this patch, too, didn't it? I'll investigate further.
The EPG scan hasn't changed by this patch, so there shouldn't be a difference in that area with or without the patch.
I have attached a slightly modified version of the patch, which avoids error messages like
ERROR (dvbdevice.c,157): Value too large for defined data type
when clearing the event queue. It also returns the current frontend status even if there was no event, and logs the channel number and transponder in case of a timeout. As far as I can see the timeouts always happen on transponders that are currently not broadcasting, or use very low symbol rates, which my full featured second device can't handle.
This additional output makes it clearer: what is channel 0?
When a new transponder is found in the NIT data it doesn't have any channel numbers yet, therefore the 0.
And 'Al Jazeera' or a program a channel 1673 indeed is nothing, I regularly need to receive. ;-)
At least this UPT and VDSB, which annoy me since 1.3.xx, have gone.
Very good.
Klaus
Klaus Schmidinger schrieb:
Martin Schoenbeck wrote:
At least this UPT and VDSB, which annoy me since 1.3.xx, have gone.
Very good.
I had straight an ARM-Crash because of an GOB error in a recording. I want to leave long the VDR without errors continuous to 48 hours (with many recordings) before I can say that there is no more error also with my VDR.
Thomas
Hi Klaus,
Klaus Schmidinger schrieb:
Maybe there's a problem with your multiswitch? When the second or third device changes the transponder, there shouldn't be any interference with the first device.
I don't know. But the switching did occur before this patch, too, didn't it? I'll investigate further.
The EPG scan hasn't changed by this patch, so there shouldn't be a difference in that area with or without the patch.
The problem has gone with the latest patch. I'd guess, it was the massive logging, when retuning, but the card was not running in transfer mode.
So, whatever it was, vdr nearly runs as expected. But sometimes, probably when the audio format changed, there is a sort of ... sorry, it's difficult to describe even in german, so I don't try it in english.
Gurgeln, aber zwei Oktaven höher. Oder Rascheln. Irgendwas dazwischen.
It's about as loud as the normal tone. About one second long.
Martin
Klaus Schmidinger wrote:
I have attached a slightly modified version of the patch, which avoids error messages like
ERROR (dvbdevice.c,157): Value too large for defined data type
when clearing the event queue. It also returns the current frontend status even if there was no event, and logs the channel number and transponder in case of a timeout. As far as I can see the timeouts always happen on transponders that are currently not broadcasting, or use very low symbol rates, which my full featured second device can't handle.
For me, I'm currently getting errors for tp 10773h, 10832h, 10861h, 10920h, 11479v, 11914h, 12441v and 12522v. The four low-band transponders are known PITA of my card, and the four high-band transponders are empty according to lyngsat.
One case looks like the lost lock state needs additional resetting on transponder change:
18:22:09 vdr[]: ERROR: frontend 1 lost lock on channel 705, tp 110920 18:22:11 vdr[]: frontend 1 regained lock on channel 347, tp 111720
There were no other messages between these two.
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
I have attached a slightly modified version of the patch, which avoids error messages like
ERROR (dvbdevice.c,157): Value too large for defined data type
when clearing the event queue. It also returns the current frontend status even if there was no event, and logs the channel number and transponder in case of a timeout. As far as I can see the timeouts always happen on transponders that are currently not broadcasting, or use very low symbol rates, which my full featured second device can't handle.
For me, I'm currently getting errors for tp 10773h, 10832h, 10861h, 10920h, 11479v, 11914h, 12441v and 12522v. The four low-band transponders are known PITA of my card, and the four high-band transponders are empty according to lyngsat.
One case looks like the lost lock state needs additional resetting on transponder change:
18:22:09 vdr[]: ERROR: frontend 1 lost lock on channel 705, tp 110920 18:22:11 vdr[]: frontend 1 regained lock on channel 347, tp 111720
There were no other messages between these two.
Cheers,
Udo
Incidently I had already added the necessary source line, but then I thought it might not be that bad to have that "regained" message, because otherwise there would be a "lost lock" message in the log without any "regained lock", even if in fact the lock was actually regained.
Klaus
Martin Schoenbeck wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
Have you edited this log? I'm missing the "switching to channel ..." messages. How do you actually set both devices at the same time?
Nobody is switching channels then. Perhaps the EPG-Scan is running, but
I just realized that I had turned off the EPG scan here for some tests and hadn't turned it on again.
I have now turned it on and get the timeouts, too, once the EPG scan kicks in.
Maybe these are transponders that (currently) don't broadcast. I'll check this tomorrow.
Klaus
Martin Schoenbeck ms.usenet.nospam@schoenbeck.de wrote:
Jan 4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock Jan 4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
I had similar problems until I re-made my cables (loose F plugs) and reattached them to the receiver cards.
-
Harald Milz -
Klaus Schmidinger -
Martin Schoenbeck -
Niko Mikkila -
Patrick Maier -
Reinhard Nissl -
Thomas Rausch -
Udo Richter