Hi,
the attached patch introduces some timeouts while the device is tuning and when it looses the lock:
DISEQC_REPEAT_TIMEOUT (500 ms) is used to repeat the DiSEqC signalling in case the where a multiswitch receives at first a malformed message and therefore doesn't switch.
TUNE_TO_RETUNE_TIMEOUT (3000 ms) is used to instruct the device to start the tuning operation once again in case the above DiSEqC signalling doesn't work.
LOST_LOCK_TO_RETUNE_TIMEOUT (500 ms) lets the device retune after a LOCKED to NOT LOCKED transition, probably under bad reception conditions.
Please give the patch a try and report success or failure.
Tests of special interest: - bad reception conditions (DVB-T) - steering dishes
Bye.
Reinhard Nissl wrote:
the attached patch introduces some timeouts while the device is tuning and when it looses the lock:
Applied. I'll see if I can spot any VDSB's or one of the introduced log messages, but since the only two VDSB's I ever had were last week, I may not see anything at all.
Cheers,
Udo
Udo Richter wrote:
Reinhard Nissl wrote:
the attached patch introduces some timeouts while the device is tuning and when it looses the lock:
Some early results: I'm seeing lots of 'lost lock' and 'timed out while tuning' messages for my secondary budget card, so the patch seems to do his work. So far this is nothing unexpected, as all these messages are epg scan related (no timer running), and I have a known problem with my multiswitch that makes my budget card blind for many low-band transponders. By now there were no errors while the budget card was busy recording.
Cheers,
Udo
Udo Richter wrote:
Udo Richter wrote:
Reinhard Nissl wrote:
the attached patch introduces some timeouts while the device is tuning and when it looses the lock:
Some early results: I'm seeing lots of 'lost lock' and 'timed out while tuning' messages for my secondary budget card, so the patch seems to do his work.
Today VDSB striked again, with the original patch still applied:
14:59:35 vdr[2376]: ERROR: frontend 1 timed out while tuning - re-tuning 14:59:59 last message repeated 7 times 15:00:00 vdr[2376]: timer 3 (***************) start 15:00:00 vdr[2376]: record **************** 15:00:03 vdr[2376]: ERROR: frontend 1 timed out while tuning - re-tuning 15:00:30 last message repeated 9 times 15:00:31 vdr[2376]: ERROR: video data stream broken 15:00:31 vdr[2376]: initiating emergency exit
If I remember correctly, then in all cases a replay was running, while the budget card was switching from EPG scan to timer recording. Does anyone know whether the tuner of the primary card goes offline while a playback is running? With only one tuner, running an EPG scan, my multiswitch may be failing and simply doesnt get up again until the primary tuner helps out.
Cheers,
Udo
Sorry, this Patch is not unfortunately the solution for my problem. :((
Dec 7 05:37:14 cat vdr[12894]: ERROR: frontend 0 timed out while tuning - re-tuning Dec 7 05:37:17 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:37:17 cat vdr[12894]: ERROR: frontend 0 timed out while tuning - re-tuning Dec 7 05:38:25 cat vdr[12899]: channel 10 (WDR Köln) event 05:30 'Lokalzeit OWL aktuell' status 4 Dec 7 05:38:25 cat vdr[12899]: channel 5 (Das Erste) event 05:30 'ZDF-Morgenmagazin' status 4 Dec 7 05:38:27 cat vdr[12899]: channel 12 (SÜDWEST Ferns. BW) event 05:30 'Landesschau Rheinland-Pfalz' status 4 Dec 7 05:38:46 cat vdr[12898]: ERROR: frontend 1 lost lock - re-tuning Dec 7 05:38:49 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:39:01 cat last message repeated 4 times Dec 7 05:41:30 cat vdr[12902]: channel 24 (KABEL1) event 05:42 'Bill Cosby Show' status 2 Dec 7 05:41:58 cat vdr[12902]: channel 24 (KABEL1) event 05:42 'Bill Cosby Show' status 4 Dec 7 05:44:23 cat vdr[12894]: ERROR: frontend 0 lost lock - re-tuning Dec 7 05:44:26 cat vdr[12894]: ERROR: frontend 0 timed out while tuning - re-tuning Dec 7 05:44:39 cat last message repeated 4 times Dec 7 05:48:14 cat vdr[12898]: ERROR: frontend 1 lost lock - re-tuning Dec 7 05:48:17 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:49:58 cat last message repeated 5 times Dec 7 05:49:59 cat vdr[12894]: ERROR: frontend 0 timed out while tuning - re-tuning Dec 7 05:50:00 cat vdr[12890]: switching device 1 to channel 16 Dec 7 05:50:00 cat vdr[12890]: DEBUG-TOM: TurnOnLivePIDs = 0, Karte/Kanal: 1/16 Dec 7 05:50:00 cat vdr[12890]: timer 6 (16 0550-0620 'Serien~Bernd~Tolle Sachen~Keksveredler') start Dec 7 05:50:00 cat vdr[12890]: Title: 'logo!' Subtitle: 'Nachrichten für Kinder' Dec 7 05:50:00 cat vdr[12890]: record /video/Serien/Bernd/Tolle_Sachen/Keksveredler/2005-12-07.05.50.45.99.rec Dec 7 05:50:00 cat vdr[12890]: creating directory /video/Serien/Bernd/Tolle_Sachen/Keksveredler Dec 7 05:50:00 cat vdr[12890]: creating directory /video/Serien/Bernd/Tolle_Sachen/Keksveredler/2005-12-07.05.50.45.99.rec Dec 7 05:50:00 cat vdr[12890]: recording to '/video/Serien/Bernd/Tolle_Sachen/Keksveredler/2005-12-07.05.50.45.99.rec/001.vdr' Dec 7 05:50:00 cat vdr[14181]: file writer thread started (pid=14181, tid=15024138) Dec 7 05:50:00 cat vdr[14182]: recording thread started (pid=14182, tid=15040526) Dec 7 05:50:00 cat vdr[14183]: receiver on device 1 thread started (pid=14183, tid=15056911) Dec 7 05:50:00 cat vdr[14184]: TS buffer on device 1 thread started (pid=14184, tid=15073296) Dec 7 05:50:01 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:50:29 cat last message repeated 8 times Dec 7 05:50:31 cat vdr[14181]: ERROR: video data stream broken Dec 7 05:50:31 cat vdr[14181]: initiating emergency exit Dec 7 05:50:31 cat vdr[12890]: emergency exit requested - shutting down
Here still the listing of the photograph listing (001.vdr has normal data).
-rw-r--r-- 1 root root 36399135 7. Dez 06:00 001.vdr -rw-r--r-- 1 root root 528503583 7. Dez 06:20 002.vdr -rw-r--r-- 1 root root 341048 7. Dez 06:20 index.vdr -rw-r--r-- 1 root root 580 7. Dez 06:00 info.vdr
Thomas Rausch schrieb:
Dec 7 05:37:17 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:38:46 cat vdr[12898]: ERROR: frontend 1 lost lock - re-tuning Dec 7 05:38:49 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning
..........
Dec 7 05:50:00 cat vdr[14181]: file writer thread started (pid=14181, tid=15024138) Dec 7 05:50:01 cat vdr[12898]: ERROR: frontend 1 timed out while tuning - re-tuning Dec 7 05:50:29 cat last message repeated 8 times Dec 7 05:50:31 cat vdr[14181]: ERROR: video data stream broken Dec 7 05:50:31 cat vdr[14181]: initiating emergency exit
It has the appearance, as if the scanner (12898) the Filewriter (14181) the map to take away wants (or the data be missing).
Hi,
Thomas Rausch wrote:
Sorry, this Patch is not unfortunately the solution for my problem. :((
If I still possibly which at data supply can, ask. Possibly a Patch, which perhaps supplies all internal Stati?
Damn, it was quite hard to understand what you wanted to tell me ;-)
From the log output I see that you don't use DiSEqC. But I now think that my patch only addresses some issues within DiSEqC setups. In any other setup the driver retunes the card automatically (actually, it does that for a DiSEqC setup too, but it doesn't repeat the DiSEqC message which might be the key factor for beeing successful with retuning).
So for now, I've no further requirements concerning any test. Maybe I'll modify and post my patch later with a new invitation for testing ;-)
Bye.
Reinhard Nissl schrieb:
Hi,
Thomas Rausch wrote:
Sorry, this Patch is not unfortunately the solution for my problem. :((
If I still possibly which at data supply can, ask. Possibly a Patch, which perhaps supplies all internal Stati?
Damn, it was quite hard to understand what you wanted to tell me ;-)
Perhaps a Patch for an extended expenditure, as it Klaus makes?
So for now, I've no further requirements concerning any test. Maybe I'll modify and post my patch later with a new invitation for testing ;-)
I wait completely longingly for it. :-)
Bye.
Hi,
Thomas Rausch wrote:
So for now, I've no further requirements concerning any test. Maybe I'll modify and post my patch later with a new invitation for testing ;-)
I wait completely longingly for it. :-)
Attached you'll find the updated patch: - retunes now only in DiSEqC setups. - just a single timeout (1000 ms) for retuning/resending DiSEqC message. - lost lock timeout increased (1000 ms).
As resending the DiSEqC message requires to retune afterwards, it is now possible, that you cannot tune to channels where tuning takes longer than 1000 ms. In such a (rare) case, please increase the DISEQC_TUNE_TO_RETUNE_TIMEOUT e. g. to 1500, 2000 or an even larger value.
Bye.
Reinhard Nissl rnissl@gmx.de wrote:Attached you'll find the updated patch: - retunes now only in DiSEqC setups. - just a single timeout (1000 ms) for retuning/resending DiSEqC message. - lost lock timeout increased (1000 ms).
As resending the DiSEqC message requires to retune afterwards, it is now possible, that you cannot tune to channels where tuning takes longer than 1000 ms. In such a (rare) case, please increase the DISEQC_TUNE_TO_RETUNE_TIMEOUT e. g. to 1500, 2000 or an even larger value. Hi,
Finally with this patch my motorized dish is working well. I had to increase DISEQC_TUNE_TO_RETUNE_TIMEOUT to 2000, because with 1000 dish didn't move at all until vdr is killed.
thanx, cedo
--------------------------------- Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping
Hi,
cedo n wrote:
As resending the DiSEqC message requires to retune afterwards, it is now possible, that you cannot tune to channels where tuning takes longer than 1000 ms. In such a (rare) case, please increase the DISEQC_TUNE_TO_RETUNE_TIMEOUT e. g. to 1500, 2000 or an even larger value.
Finally with this patch my motorized dish is working well. I had to increase DISEQC_TUNE_TO_RETUNE_TIMEOUT to 2000, because with 1000 dish didn't move at all until vdr is killed.
Please clearify: dish is "still"/"now" working well.
Was 2000 the smallest value that worked with your dish?
Bye.
Attached is a modified version of Reinhard's patch for retuning after a timeout.
It has several macros for the various timeouts, depending on what kind of DVB card is used:
#define DVBS_TUNE_TIMEOUT 2000 //ms #define DVBS_LOCK_TIMEOUT 2000 //ms #define DVBC_TUNE_TIMEOUT 5000 //ms #define DVBC_LOCK_TIMEOUT 2000 //ms #define DVBT_TUNE_TIMEOUT 9000 //ms #define DVBT_LOCK_TIMEOUT 2000 //ms
Users with DVB-C and DVB-T cards should please test whether the given values are ok (they are just guesses, since I don't have such cards) and report in case they need other values.
Retuning is now done for all device types, not only if DiSEqC commands are used.
Klaus
After 6 hours I must say that my VDR did not bring yet back the error. So far otherwise always. I want to hope that it functions now. :)
In the LOG comes however repeatedly:
Jan 3 18:15:43 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:15:43 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:03 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:03 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:25 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:26 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:45 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:45 cat vdr[16675]: frontend 0 regained lock Jan 3 18:17:06 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:17:06 cat vdr[16675]: frontend 0 regained lock
My primary frontend is device 3.
Thomas Rausch wrote:
After 6 hours I must say that my VDR did not bring yet back the error. So far otherwise always. I want to hope that it functions now. :)
In the LOG comes however repeatedly:
Jan 3 18:15:43 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:15:43 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:03 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:03 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:25 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:26 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:45 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:45 cat vdr[16675]: frontend 0 regained lock Jan 3 18:17:06 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:17:06 cat vdr[16675]: frontend 0 regained lock
Apparently the FE_GET_EVENT ioctl() sometimes delivers a different status value than FE_READ_STATUS. I ran some tests, comparing both values and whenever VDR reported a lost lock, the current FE_READ_STATUS value still had the FE_HAS_LOCK set correctly.
Following an old recommendation of Holger Wächtler I finally changed the frontend status handling so that it polls the frontend and reads any pending event (but simply discards it), and then reads the actual status via FE_READ_STATUS.
With the attached patch (which is again a complete patch against dvbdevice.c of version 1.3.37) I don't get these spurious "lost lock" messages any more.
I've also increased the timeout for polling the event queue to 10ms, because 1ms seemed a little hard to me. This had no effect on the "lost lock" problem, however, so the change in status handling really is what fixed it.
Please try whether this also helps in your case.
Klaus
Klaus Schmidinger wrote:
Thomas Rausch wrote:
After 6 hours I must say that my VDR did not bring yet back the error. So far otherwise always. I want to hope that it functions now. :)
In the LOG comes however repeatedly:
Jan 3 18:15:43 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:15:43 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:03 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:03 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:25 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:26 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:45 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:45 cat vdr[16675]: frontend 0 regained lock Jan 3 18:17:06 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:17:06 cat vdr[16675]: frontend 0 regained lock
Apparently the FE_GET_EVENT ioctl() sometimes delivers a different status value than FE_READ_STATUS. I ran some tests, comparing both values and whenever VDR reported a lost lock, the current FE_READ_STATUS value still had the FE_HAS_LOCK set correctly.
Following an old recommendation of Holger Wächtler I finally changed the frontend status handling so that it polls the frontend and reads any pending event (but simply discards it), and then reads the actual status via FE_READ_STATUS.
With the attached patch (which is again a complete patch against dvbdevice.c of version 1.3.37) I don't get these spurious "lost lock" messages any more.
I've also increased the timeout for polling the event queue to 10ms, because 1ms seemed a little hard to me. This had no effect on the "lost lock" problem, however, so the change in status handling really is what fixed it.
Please try whether this also helps in your case.
Unfortunately this broke the CAM menu handling, so here's a slightly different version.
Sorry about that...
Klaus
Klaus Schmidinger wrote:
Klaus Schmidinger wrote:
Thomas Rausch wrote:
After 6 hours I must say that my VDR did not bring yet back the error. So far otherwise always. I want to hope that it functions now. :)
In the LOG comes however repeatedly:
Jan 3 18:15:43 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:15:43 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:03 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:03 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:25 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:26 cat vdr[16675]: frontend 0 regained lock Jan 3 18:16:45 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:16:45 cat vdr[16675]: frontend 0 regained lock Jan 3 18:17:06 cat vdr[16675]: ERROR: frontend 0 lost lock Jan 3 18:17:06 cat vdr[16675]: frontend 0 regained lock
Apparently the FE_GET_EVENT ioctl() sometimes delivers a different status value than FE_READ_STATUS. I ran some tests, comparing both values and whenever VDR reported a lost lock, the current FE_READ_STATUS value still had the FE_HAS_LOCK set correctly.
Following an old recommendation of Holger Wächtler I finally changed the frontend status handling so that it polls the frontend and reads any pending event (but simply discards it), and then reads the actual status via FE_READ_STATUS.
With the attached patch (which is again a complete patch against dvbdevice.c of version 1.3.37) I don't get these spurious "lost lock" messages any more.
I've also increased the timeout for polling the event queue to 10ms, because 1ms seemed a little hard to me. This had no effect on the "lost lock" problem, however, so the change in status handling really is what fixed it.
Please try whether this also helps in your case.
Unfortunately this broke the CAM menu handling, so here's a slightly different version.
Sorry about that...
And sorry again...
Looks like the only thing that was really wrong was the 'continue' in the (Status & FE_HAS_LOCK) branch.
So here's yet another version, hopefully this will be the last one.
Klaus
Klaus Schmidinger schrieb:
Unfortunately this broke the CAM menu handling, so here's a slightly different version.
I bring this Patch in only today after 22 o'clock, since up to then still some recordings are activated and I want to see whether it up to then run.
I had yesterday unfortunately still #define WAIT_FOR_TUNER_LOCK there then unfortunately after 8 hours (EPGScanTimeout = 1) nothing more was recording.
Jan 3 23:15:05 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') start Jan 3 23:15:05 cat vdr[16671]: Title: 'Die Kuckelkorns - Ein Leben für den Tod' Subtitle: '' Jan 3 23:15:05 cat vdr[16671]: record /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec Jan 3 23:15:05 cat vdr[16671]: creating directory /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer Jan 3 23:15:05 cat vdr[16671]: creating directory /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_ Jan 3 23:15:05 cat vdr[16671]: creating directory /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec Jan 3 23:15:05 cat vdr[16671]: recording to '/video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec/001.vdr' Jan 3 23:15:10 cat vdr[16671]: ERROR: device 1 has no lock, can't attach receiver (WAIT_FOR_TUNER_LOCK)! Jan 3 23:15:10 cat vdr[16671]: buffer stats: 0 (0%) used Jan 3 23:15:11 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') stop Jan 3 23:15:11 cat vdr[16671]: switching device 1 to channel 23 Jan 3 23:15:11 cat vdr[16671]: DEBUG-TOM: Frage: 0, Karte/Kanal: 1/23 Jan 3 23:15:11 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') start Jan 3 23:15:11 cat vdr[16671]: record /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec Jan 3 23:15:11 cat vdr[16671]: cFileName::SetOffset: removing zero-sized file /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec/001.vdr Jan 3 23:15:11 cat vdr[16671]: recording to '/video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec/001.vdr' Jan 3 23:15:16 cat vdr[16671]: ERROR: device 1 has no lock, can't attach receiver (WAIT_FOR_TUNER_LOCK)! Jan 3 23:15:16 cat vdr[16671]: buffer stats: 0 (0%) used Jan 3 23:15:17 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') stop Jan 3 23:15:17 cat vdr[16671]: switching device 1 to channel 23 Jan 3 23:15:17 cat vdr[16671]: DEBUG-TOM: Frage: 0, Karte/Kanal: 1/23 Jan 3 23:15:17 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') start Jan 3 23:15:17 cat vdr[16671]: record /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec Jan 3 23:15:17 cat vdr[16671]: cFileName::SetOffset: removing zero-sized file /video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec/001.vdr Jan 3 23:15:17 cat vdr[16671]: recording to '/video/Serien/Six_Feet_Under/Six_Feet_Under_-_Gestorben_wird_immer/_/2006-01-03.22.55.50.99.rec/001.vdr' Jan 3 23:15:23 cat vdr[16671]: ERROR: device 1 has no lock, can't attach receiver (WAIT_FOR_TUNER_LOCK)! Jan 3 23:15:23 cat vdr[16671]: buffer stats: 0 (0%) used Jan 3 23:15:24 cat vdr[16671]: timer 25 (23 2255-0020 'Serien~Six Feet Under~Six Feet Under - Gestorben wird immer') stop Jan 3 23:15:24 cat vdr[16671]: switching device 1 to channel 23 Jan 3 23:15:24 cat vdr[16671]: DEBUG-TOM: Frage: 0, Karte/Kanal: 1/23
Thomas Rausch wrote:
Klaus Schmidinger schrieb:
Unfortunately this broke the CAM menu handling, so here's a slightly different version.
I bring this Patch in only today after 22 o'clock, since up to then still some recordings are activated and I want to see whether it up to then run.
Please be sure to test the very latest one (vdr.1.3.37-tunertimeout4.diff).
Klaus
Klaus Schmidinger schrieb:
Please be sure to test the very latest one (vdr.1.3.37-tunertimeout4.diff).
Yes. ;)
The preceding Patch (from yesterday) had unfortunately again :(
Jan 4 20:45:00 cat vdr[18309]: switching device 1 to channel 16 Jan 4 20:45:00 cat vdr[18309]: DEBUG-TOM: Frage: 0, Karte/Kanal: 1/16 Jan 4 20:45:00 cat vdr[18309]: timer 6 (16 2045-2115 'Serien~Bernd~BRAVO BERND~der etwas andere Sandmann') start Jan 4 20:45:00 cat vdr[18309]: Title: 'BRAVO BERND' Subtitle: 'der etwas andere Sandmann' Jan 4 20:45:00 cat vdr[18309]: record /video/Serien/Bernd/BRAVO_BERND/der_etwas_andere_Sandmann/2006-01-04.20.45.99.99.rec Jan 4 20:45:00 cat vdr[18309]: creating directory /video/Serien/Bernd/BRAVO_BERND/der_etwas_andere_Sandmann/2006-01-04.20.45.99.99.rec Jan 4 20:45:01 cat vdr[18309]: recording to '/video/Serien/Bernd/BRAVO_BERND/der_etwas_andere_Sandmann/2006-01-04.20.45.99.99.rec/001.vdr' Jan 4 20:45:01 cat vdr[18387]: file writer thread started (pid=18387, tid=835598) Jan 4 20:45:01 cat vdr[18388]: recording thread started (pid=18388, tid=851983) Jan 4 20:45:01 cat vdr[18389]: receiver on device 1 thread started (pid=18389, tid=868368) Jan 4 20:45:01 cat vdr[18390]: TS buffer on device 1 thread started (pid=18390, tid=884753) Jan 4 20:45:04 cat vdr[18316]: ERROR: frontend 1 lost lock Jan 4 20:45:04 cat vdr[18316]: frontend 1 regained lock Jan 4 20:45:25 cat vdr[18316]: ERROR: frontend 1 lost lock Jan 4 20:45:25 cat vdr[18316]: frontend 1 regained lock Jan 4 20:45:32 cat vdr[18387]: ERROR: video data stream broken Jan 4 20:45:32 cat vdr[18387]: initiating emergency exit Jan 4 20:45:32 cat vdr[18309]: emergency exit requested - shutting down
That was the 1. failed recording within 15 hours (5 other recordings ok).
Thomas
-
cedo n -
Klaus Schmidinger -
Reinhard Nissl -
Thomas Rausch -
Udo Richter