On 10/9/07, VDR User <[EMAIL PROTECTED]> wrote:
I was hoping some of these ideas would have made it into the next release.
But, since it didnt, does anyone have a patch put together?
Best Regards.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.
Yesturday I had the same problem where a very bad but short storm
caused my signal to drop and vdr again performed an emergency exit
when it wasn't wanted. I already commented out the EmergencyExit
request in recorder.c but this time it was generated in remux.c by:
if (!synced && skipped >= 0)
Rainer Zocholl:
> That's long time ago and IMHO only a problem on unmodded v1.3 cards or
> "not perfect" ARM firmware at that time, 3 or more years ago
> (At least i got rid of the problem by -expensive- upgrading to 2.0 cards.
> (Someone interessted in 1.3 cards, 220E each?)).
> (see http://vdr-w
[EMAIL PROTECTED](Ludwig Nussel) 01.10.07 14:28
>Klaus Schmidinger wrote:
>> On 09/29/07 09:30, Timothy D. Lenz wrote:
>>> I don't know about it restarting. The crashing with loss of signal
>>> is suposed to be a safe guard against creating blank recordings.
>>> Seems like a bad idea to me to. J
[EMAIL PROTECTED](VDR User) 30.09.07 13:37
>On 9/30/07, Jouni Karvo <[EMAIL PROTECTED]> wrote:
>> VDR User wrote:
>>> I like these ideas... NO SIGNAL image in recording during no
>>> signal. Or that if no signal then no writing to disk. And a
>>> warning in the log about a possible incomplete r
There are some great suggestions in the beginning of this thread,
please let's not create a complicated solution where it's unnecessary
to have one. Let the user decide the behavior he wants and leave it
at that. No need/want for vdr to try auto-tuning this channel or that
transponder, or emergen
>
> >
>
> Maybe a solution for all the ideas in here ? Let vdr call a command and
> decide based on exit status ? This could be simply set to /bin/false for
> never restart or any sophisticated logic for everything else ?
The main problem for me is that my reception is not that great. During ba
Walter Koch schrieb:
> Moin,
>
>
>> The solution with three options sounds best: restart always, if no other
>> (working) recordings, never.
>>
>
> But this doesn't stop the "VDR started to restart itself every minute"-
> problem completely. If there was already one emergency exit shortly
>
Moin,
> The solution with three options sounds best: restart always, if no other
> (working) recordings, never.
But this doesn't stop the "VDR started to restart itself every minute"-
problem completely. If there was already one emergency exit shortly
before and the stream didn't come back, it do
[EMAIL PROTECTED] wrote:
>>> How does that sound?
>
>> Complicated. And you did not even consider cases such as:
...
> Because I've seen this restart cycle many times, and only way
> out of it is editing via [your favorite editor] the timers.conf
> file.
I have seen the problem too. Just remov
>> How does that sound?
> Complicated. And you did not even consider cases such as:
> The card is receiving perfectly another channel on the same mux,
> so tuning to another mux would not be an option.
This was the FIX1. Transponder = mux = 'kanavanippu'. The tests
was for VDR to better und
[EMAIL PROTECTED] wrote:
> How does that sound?
Complicated. And you did not even consider cases such as: The card is
receiving perfectly another channel on the same mux, so tuning to
another mux would not be an option. Although it is easy to add
conditions like this to the code, it would mean
> What is point to that, that VDR do restart IF there is no
> stream what it should record.. That affected to all other
> recordings too because vdr was restarting itself constantly.
> Not good!
> Is there "setting" somewhere where you can say that "do not"
> restart if there is no stream.
This
Ludwig Nussel <[EMAIL PROTECTED]> writes:
>> [...]
> I wonder whether reloading modules is still an appropriate action.
> Nowadays it's possible for example to bind/unbind drivers to/from
> specific devices. Ie if you have multiple dvb-ttpci cards it should
> be possible to reset a specific one.
Klaus Schmidinger wrote:
> On 09/29/07 09:30, Timothy D. Lenz wrote:
> > I don't know about it restarting. The crashing with loss of signal is
> > suposed to be a safe guard against creating blank recordings. Seems like a
> > bad idea to me to. Just delete the bad recordings, don't crash the system
On 9/30/07, Jouni Karvo <[EMAIL PROTECTED]> wrote:
> VDR User wrote:
> > I like these ideas... NO SIGNAL image in recording during no signal.
> > Or that if no signal then no writing to disk. And a warning in the
> > log about a possible incomplete recording cuz of lost signal +
> > identified in
VDR User wrote:
> I like these ideas... NO SIGNAL image in recording during no signal.
> Or that if no signal then no writing to disk. And a warning in the
> log about a possible incomplete recording cuz of lost signal +
> identified in recordings menu by a special char like ? maybe.
>
I do no
] Not good behaviour from vdr
I like the idea of appending the "?" symbol to every recording that triggers
the "no signal" flag.
Best Regards.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 9/30/07, VDR User <[EMAIL PROTECTED]> wrote:
>
> I like these ideas... NO SIGNAL image in recording during no signal.
> Or that if no signal then no writing to disk. And a warning in the
> log about a possible incomplete recording cuz of lost signal +
> identified in recordings menu by a speci
JJussi wrote:
> How about, when there is no stream - no writing to HD.. OK, if there is 15
> minutes break middle of stream, then recording "jump" those 15 minutes during
> playback.
To clear things up: Of course, if there's no stream for whatever
reasons, VDR already does NOT write anything to
I like these ideas... NO SIGNAL image in recording during no signal.
Or that if no signal then no writing to disk. And a warning in the
log about a possible incomplete recording cuz of lost signal +
identified in recordings menu by a special char like ? maybe.
These are all good options and woul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Klaus Schmidinger schrieb:
> On 09/29/07 09:30, Timothy D. Lenz wrote:
>> Locate the line in recorder.c and comment it out.
>>
>>esyslog("ERROR: video data stream broken");
>> - ShutdownHandler.RequestEmergencyExit();
>> + //
On 9/30/07, JJussi <[EMAIL PROTECTED]> wrote:
>
> On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
> > Since the recording is scheduled, I would assume the user has room on
> the
> > disk (so disk space usage is not really the problem). The only problem
> I
> > can see is that you might get a
JJussi wrote:
> On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
>> Since the recording is scheduled, I would assume the user has room on the
>> disk (so disk space usage is not really the problem). The only problem I
>> can see is that you might get a blank recording if the signal goes out (
On Sunday, 30. Septemberta 2007 10:35:07 Stone wrote:
> Since the recording is scheduled, I would assume the user has room on the
> disk (so disk space usage is not really the problem). The only problem I
> can see is that you might get a blank recording if the signal goes out (and
> you think its
Since the recording is scheduled, I would assume the user has room on the
disk (so disk space usage is not really the problem). The only problem I
can see is that you might get a blank recording if the signal goes out (and
you think its recorded but its not). So, perhaps vdr should NOT do a
emerg
Coincidently, I just had this "broken video stream" emergency exit the
other day because of bad weather that came & went. I don't run some
kind of auto-restart script so vdr stayed unloaded and coincidently
caused several other timers to be missed.
For those who would say 'just add auto-restart',
dom.plu wrote:
> It can be interresting to use the emergency shutdown only when there are no
> other records running at the same time
Sounds like a good idea:
Emergency exit on failing to record:
* Never
* Only if this doesn't break other recordings
* Always
Maybe this could even be based on reco
Hi
thanks for this future option, I have the same problem not caused directly by
card or drivers but in a multiple frontend system (dvb-s + dvb-t) if at least
one provider did not send signal , you loose all other concurrent records
It can be interresting to use the emergency shutdown only when t
On 09/29/07 09:30, Timothy D. Lenz wrote:
> I don't know about it restarting. The crashing with loss of signal is
> suposed to be a safe guard against creating blank recordings. Seems like a
> bad idea to me to. Just delete the bad recordings, don't crash the system.
Well, let me just comment on t
st"
Sent: Friday, September 28, 2007 11:49 PM
Subject: [vdr] Not good behaviour from vdr
> Hi!
>
> Yesterday, here at Southern Finland one of the TV channels had "cut out"
at
> DVB stream (like half hour). And because that stream disapeared little
after
> than recoding
Hi!
Yesterday, here at Southern Finland one of the TV channels had "cut out" at
DVB stream (like half hour). And because that stream disapeared little after
than recoding has started, VDR started to restart itself every minute because
there was no stream...
What is point to that, that VDR do re
32 matches
Mail list logo
