Slumbermode confusion ?

[gibman]

I am a bit confused about what the slubermode is.

 

1) CMDline -C ?

I usually startup my dvbV with the -C cmdline param. Is this slumbermode ?

No channel is tuned. CPU usage is 0. really nice since I need DVBViewer resident in memory to be able to use the HTTPserver service. I run this on a 24-7 multi-purpose server.

 

2) Timer after event.

I can set a specific timer event to slumbermode when done recording. What happens is this - after the recording has ended the AV is being deactivated (no DS filters active) - but the channel is still tuned in with slightly lower CPU usage

This gives me several disadvantages which are;

a) CPU usage is swaying between 20-30% - it should ideally be 0%, like the -C cmdline param. Wasting CPU cycles is not a good idea

when using the DVBserver as a source to all my 3-4 DVBViewer enabled PCs, I have the scheduling PC holding the channel on the DVBserver - effectively preventing other clients to tune into other channels on other transponders. If only I could make the after-timerschedule-event do something like the -C cmdline, then other clients could tune into other channels, without limitations. Would be nice if slumbermode really did a un-tune of the channel with 0 CPU usage.

 

3) Custom Keyboard Input

If I add my own custom shortcut key to slumbermode done through dvbV options. ex. F11 triggers slumbermode - 12325. When I hit F11 my XP PC does a full shutdown ? This must be a bug or what ?

 

In other words I though slumbermode was what the -c cmdline param gave me ?

 

/Elo

[Guest Lars_MQ]

Well it's a typo in the actions.ini it should read:

 

PowerOff=12325

 

There are two missing:

SHUTDOWNCARD=12327

SHUTDOWNMONITOR=12328

 

The shutdown card should be used careful with the current DVBViewer Pro beta. There is a little unsolved issue, but it should work.

[gibman]

Yeah If I Use SHUTDOWNCARD=12327 with a shortcut key it does what I want.

0 CPU usage.

 

My problem is still present - I want the scheduling DVBViewer to call SHUTDOWNCARD when it is finished recording. But it seems like the 7 available options to choose from are hardcoded into the application.

 

I have the following to choose from;

 

1) do nothing after recording

2) force shutdown after recording

3) force standby after recording

4) force hibernation after recording

5) close DVBViewer

6) start playlist

7) slumbermode

 

I really need the 8th option being SHUTDOWNCARD.

Why not make this list customizable ? Making the user call any command in the actions.ini file or even call a script file ?

 

As it is now we users that take use of the DVBserver is a bit screwed when it comes to scheduling, simply b/c it's important to release a tuned channel as soon as a client possible can - simply to make the channel/transponder available to others.

 

I guess I cant script my way out of this huh???

 

/Elo

Edited February 5, 2006 by gibman

[Guest Lars_MQ]

a) CPU usage is swaying between 20-30% - it should ideally be 0%,

What kind of PC do you use? On a 500er it's about 5 % if disableAV. On a Athlon XP 2000 it's between 0-1%. I think something is fishy with your configuration.

[gibman]

About CPU usage. I did a fresh install and CPU usage is now lower, as u say about 1-5% on a amd64@2000mhz.

 

CPU usage is not the real showstopper for me here. It is the fact that the workstation that just did a scheduled recording STILL has a solid lock on the current channel, preventing other dvbserver clients to watch TV after the recording has ended.

 

Why not just make it so that DVBViewer un-tunes (=SHUTDOWNCARD) a channel, thus succesfully unlocking the transponder for other clients to use.

 

Hope I make myself clear.

Am I the only one using client server DVB stream sharing and at the same time using scheduling recordings ?

 

/Elo

[Guest Lars_MQ]

Ok from the bedinning:

 

You use DVBServer. You connect locally to the dvbserver and via network.

 

The local DVBViewer is the master.

 

Did I understand you correctly?

[gibman]

Ok from the bedinning:

 

You use DVBServer. You connect locally to the dvbserver and via network.

 

The local DVBViewer is the master.

 

Did I understand you correctly?

<{POST_SNAPBACK}>

 

Hi Lars !

Yes. You got me spot on

My server PC is running dvbserver for all clients. And it is also running DVBViewer using unicast localhost (loopback) as dvbsource. I primarily use the server instance of DVBViewer to record my serious stuff. Ofcourse I do som casual test/fun recordings on my other clients as well - but they are not as important.

 

/Elo

[Guest Lars_MQ]

There is no solution for your problem. -c won't help you.

 

The DVBServer needs one masterclient which defines the transponder. In your case this must be the local DVBViewer, cause otherwise your recordings can go down the drain.

 

Imagine a network client is the master client (that's what you ask for) and you want to record on a other transponder with the local client. you have no way to switch the transponder cause the network client is the boss...

[gibman]

I think you misunderstood me - if I am not mistaken there is a CLEAR fix for my problem.

 

(Maybe you are confusing this thread with the other thread about priority that I also created @ http://www.DVBViewer.com/forum/index.php?showtopic=11126)

 

I'm not talking about clients fighting eachother over who has control over what transponders and who has not.

 

What I'm talking is...

When you setup a timer on any dvbV client on your DVB network, then you have 7 events to choose from.

 

1) do nothing after recording

2) force shutdown after recording

3) force standby after recording

4) force hibernation after recording

5) close DVBViewer

6) start playlist

7) slumbermode

 

Events that are executed after a timer has finished. Fine so far, but nut quite enuff for dvbserver users:)

 

*** If I could select "shutdown card" as an event then my problem is fixed. Simple as that. ***

 

I have verified that a "shutdown card" command issued on a client removes the client from the DVBserver clients list - thus unlocking the transponder, now the next client ex. a laptop can login to the dvbserver and watch TV without limits.

 

The "shutdown card" event on a timer is not that useful on a normal "skystar2" dvb-sourced client, since there is no sharing of channels - thus no transponder locking. The "shutdown card" event is in other words very useful for DVBserver freaks like myself..hehe.

 

/Elo

Edited February 6, 2006 by gibman

[Guest Lars_MQ]

No you don't understand the workings

 

We're talking recordings. We're talking Network. there is NO transponderlocking on network. What happens if your local client shuts down giving the control over which transponder to choose to the next networked client.

 

Imagine the local client goes on "Standby" means giving the mastercontrol over the server away (That's what you want -c). Now the new Master goes to transponder B. Your local client awakes and want to record Transponder A. But it can't switch cause it's not the master. Ergo recording does not happen.

 

Just test it. Use close DVBViewer after recording and the schedule plugin.

[gibman]

We're talking recordings. We're talking Network. there is NO transponderlocking on network.

 

There is no hard-lock on the transponder ? Then what do you call that hardware limitation that is inherited in all DVB-s cards with one tuner (atleast the skystar2) ?

If multiple clients are connected simultaniously to the DVBserver, then the transponder is locked to the transponder chosen by the first client connected - you call this the master client - the boss. Is this not a transponder lock ?

 

What happens if your local client shuts down giving the control over which transponder to choose to the next networked client.

As it is now this would be my headache.

This could be a small or big disadvantage for you maybe. But this again could be fixed by implementing some kind of IP client priority on the DVBserver.exe.

Telling the DVBserver that connections made from client with ip 192.168.1.2 should override all other clients, specially when it comes to recordings made from 192.168.1.2. Although I don't think that DVBserver can distinquish between a recording client and a passive viewing client.

Again have u taken a look at my other thread about this ?

http://www.DVBViewer.com/forum/index.php?showtopic=11126

 

Imagine the local client goes on "Standby" means giving the mastercontrol over the server away (That's what you want -c). Now the new Master goes to transponder B. Your local client awakes and want to record Transponder A. But it can't switch cause it's not the master. Ergo recording does not happen.

 

Just test it. Use close DVBViewer after recording and the schedule plugin.

I don't need to, I know what you mean and I have known this problem all along.

It's just that the side-effect is already present.

 

********* client A / server ************

 

ClientA's dvbV is loaded on the DVBSERVER host PC.

2 timer jobs are assigned.

Job1 on ch1 @ 10.00 to 11.00.

Job2 on ch2 @ 11.30 to 12.00.

(The after-timer event is set to "close DVBViewer" on both Job1 and Job2.)

 

Now the clock is 10.00 and it starts recording timer-event "Job1".

The clock is now 11.00 and the recording stops, DVBViewer is issued a close command. DVBViewer is now out of RAM.

DVBtaskscheduler which is sitting happily in my systray is now inserting "Job2" in the microsoft tasksheduler list starting at 11.30.

 

 

******* client B / laptop ****************

note; The clock is 11.01 and the dvbserver client list is empty - no clients attached.

ClientB's dvbV is loaded on.

Here I am watching TV for two hours, now the time is 13.01.

Ups, now the server instance of DVBViewer must be in trouble ?

*************************************

 

I go to the server, and yes no recording, microsoft taskscheduler did run DVBViewer, but DVBViewer was not able to access the channel b/c I was sitting at clientB/laptop forgetting all about the recording.

So you see, the problem is already present - so it doesn't matter if u add "shutdown card" as the 8th event to choose from when doing recordings.

Although I would be pleased.

 

Again look at my other thread about priorities based on IP adresses. This would prevent me from ruining a recording on the server, which I have forgotten all about.

At 11.00 o'clock when I sat infront of ClientB/Laptop, then the screen should go blank, giving the DVBViewer instance on the server full control.

 

Interesting thread indeed heh.

 

/Elo

Edited February 6, 2006 by gibman