Bernd Juraschek wrote:

Hello,

I want to create a plugin which informs other applications about vdr status changes. This is no problem for start/stop of recording and replaying. But I want also detect other status changes without "polling" the vdr structures.

Now my questions/wishes:

• It would be nice to extend the cStatus class with some more events (such as adding, removing or changing timers or channels,

This could be detected by watching the timestamps of channels.conf and timers.conf.

change of the next active timer,

Just use SVDRP NEXT.

disk full warnings,

Any application can check the disk usage directly.

deletion of recordings).

Why would an external application need to know that?

• Plugins can iterate on timer and channel lists. But I think, this lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.

You're right, they're not thread safe. But since you wrote that you want to inform "other applications" about these things, and I have shown you ways how to do that (see above), I don't think these things are actually necessary in cStatus.

Klaus

Sascha Volkenandt wrote:

On Wednesday 14 September 2005 18:09, Klaus Schmidinger wrote:

...

...

change of the next active timer,

Just use SVDRP NEXT.

Not very nice to have to connect to VDR via SVDRP within a plugin :)

I thought he wrote that he wanted to make that info available to _external_ programs. Inside VDR he can always call cTimers::GetNextActiveTimer().

...

...

• Plugins can iterate on timer and channel lists. But I think, this

lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.

You're right, they're not thread safe. But since you wrote that you want to inform "other applications" about these things, and I have shown you ways how to do that (see above), I don't think these things are actually necessary in cStatus.

I've been stumbling over this recently, too. AFAIK the channels list is thread safe already, if the plugin calls Lock() and Unlock() on the Channels object properly. It would be nice if the other lists could receive these capabilities too :)

Let's think about this after version 1.4.

I just _have_ to be increasingly restrictive with changes, or we'll never get anywhere near a stable 1.4 ;-)

Klaus