[vdr] Not good behaviour from vdr
UseNet-Posting-Nospam-74308- at zocki.toppoint.de
Wed Oct 3 21:28:00 CEST 2007
ludwig.nussel at suse.de(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. Just delete the bad recordings,
>>> don't crash the system.
>> Well, let me just comment on the nomenclature here ;-)
>> When VDR does an "emergency exit" because there is no video data for
>> a while, this is a *controlled* action that shall allow the driver
>> to be reloaded.
>> Full featured cards sometimes have the problem that
>> they completely lock up,
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?)).
So it maybe only a problem for the unlucky owers of unmodded 1.3.
In a multi card system it would be possible to check if other cards
are are having a stream and not to reboot while they are successfully
In a single card system a check if other recordings (on the same transponder)
are working would be a strong indication that a reset would not solve the
problem and would make the problem worse my breaking the other recording too.
If no other recording is running a tuning attempt to a
"well known good working" transponder/programm would allow to determine
a broken driver/card from a missing antena oder broken hardware, where a
reboot will usally not help.
>> and reloading the driver fixes this.
>I wonder whether reloading modules is still an appropriate action.
That "hard way" has only historical reasons AFAIK.
Once there was a time, when the hardware(!) tends to hang.
(ARM bugs, bad power supply filtering, design errors of the card)
>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.
Maybe the PCI powermanagement can used to powerdown the one hanging card.
>Maybe it would even be possible to implement some kind of reset ioctl
>in the kernel drivers so vdr doesn't need to rely on external scripts at all.
It would be very help full.
The first big step would be if it would be possible to
suppress the restart process finally issued by VDR to reanimate
At least users of 2.0 cards will be made very happy on bad weather conditions!
(Which usually cause VDR to restart/reboot making replay implassinble too.
Too it is not possible to quickly dectivate the time for that recording:
60sec are too short to trigger that window (may i assume VDR blocks RC command
processing during detecting a broken stream?))
More information about the vdr