After recording task RecService status issue

[majstang]

There is a problem with applying After recording tasks to recording timers. There is a synchronization problem between when the recording stops and when the After recording task should be executed.

Recording does not stop before the After recording task executes. The After recording task instead prolongs the recording and Recording Services status changes to 0 (No recording going on) when the After recording task finishes at first.

 

If everything would work as intended it would be synchronized like this:

1.Recording stops

2.RS status changes from 1 (one recording going on) to 0 (No recording going on)

3.After Recording task should now be executed

 

This synchronization problem messes bad with the possibility to use After recording scripts which uses Recording Service status as a variable what to do next. Script fails every time because of the above described issue.

Edited July 4, 2010 by majstang

[Lars_MQ]

The After recording task instead prolongs the recording and Recording Services status changes to 0 (No recording going on) when the After recording task finishes at first.

That's correct and is supposed to be that way, cause as explained in the changelog the after recording action is itself a TIMER.

[majstang]

That's correct and is supposed to be that way, cause as explained in the changelog the after recording action is itself a TIMER.

You told me earlier it was a difference between After recording task and a After recording action. I have been under the assumption i have been using an After recording task the whole time and now you are saying im not?

 

I wont read 30 changelogs, but if the After recording task (Not After recording action) was treated earlier as NO timer, that was a far better choice

[majstang]

Additionaly, there is no sence in adding a timer (After recording action or task dont know the difference anymore) to an already existing timer (Recording timer).

Or is there?

Edited July 4, 2010 by majstang

[Lars_MQ]

sorry meant task not action.

 

Or is there?

Of course there is. the after recording task is a process timer.

[majstang]

Of course there is. the after recording task is a process timer.

Yes, that is true and this is the problem, Lars! Having process timers changing recordingcount status is not good. Running a process timer should not be treated as if a recording is going on...far from it. Shouldnt it be possible to have the process timers to get the RS tray icon red, but still have recordingcount at 0? You could maybe add a new line in the status api for processtimers and keep them separated from recording timers/recording count (both timertypes will still get RS tray icon red though when executed)

Edited July 4, 2010 by majstang

[Lars_MQ]

Running a process timer should not be treated as if a recording is going on...far from it

Of course they should.

 

The recording service is working on a timer. That's all the recording status says. Nothing more, nothing less

[majstang]

Of course they should.

 

The recording service is working on a timer. That's all the recording status says. Nothing more, nothing less

Yes, but you dont record a TV show with a process timer! What is the point in having a process timer change recordingcount value (as if a recording is going on) in status api when it actually does not do any recording? Recordingcount value in status api IS the Recording Service status and it should be reserved to recording timers only. I think you know what i mean, but dont wanna change things. You could at least think about it when developing this great project further. This would make RS more scriptable, which is not an easy task to accomplish today.

Thanks for your time!

 

Regards

Majstang

Edited July 4, 2010 by majstang

[majstang]

Wanna bump this one. It is still problematic having all sorts of timers unrelated to the the actual recording process interfering with the recordcount value in RS Status API. It would be a dream if the recordcount variable could be reserved to recording timers only and having an another variable named for example "timercount" collecting the Process Task Timers, the Internal Task Timers and the Autosearch Timer values under it. In this way it should be no problem to allow "timercount" changing colors on RS trayicon when ever one of these three timers are executed. Most important this would NOT alter the "recordcount" value. Then it would at last be possible to hibernate HTPC with the intelligent hibernation script, if two recordings with same starttime finishes at the exact same time. Now this is impossible cuz the two after recording tasks executed (process timers) simultaneously when the recordings finishes increases the recordcount value by 2 and the hibernation fails.

 

Hoping for change

 

Regards

majstang

[majstang]

I know it's annoying when bumping threads too frequently, but this time i'll do it for a new reason.

 

Change: Service Control Program: Heavily reworked and extended. Recording starts and endings (of all timers together) can be displayed with a Balloon tooltip (-> Show notifications in the popup menu).

The tooltip of the systemtray icon displays how many recordings are active or if none are active when the next timer is due. The version number of the recording service is also displayed.

I must say i love this new feature and it's a great addition to an already awesome application. It's a joy having easy access to "next timer start" information and get a ballon tooltip when recordings starts and finishes. Even if it had been better to have the ballon tooltip optional "always on top", cuz now it doesn't show if watching fullscreen TV/Video.

 

However it's not a joy when all process, autosearch and internal task timers starts flashing the ballon tooltip as well, since they have nothing to do with recordings. This makes my old suggestion of current interest again. Hopefully the Web API change could be carried out sometime soon, so the recordcount variable gets used for recordings only

[Lars_MQ]

balloon tooltips in the systemtray are always on top. It's by design.

[majstang]

balloon tooltips in the systemtray are always on top. It's by design.

Yes, as long as the Windows taskbar is "always on top" the balloon tooltip works as designed, but when covering the taskbar with fullscreen DVBViewer or MPC-HC the taskbar "always on top" gets overridden and the balloon tooltip with it, at least in my case. Either DVBViewer nor MPC-HC are forced as "always on top". To get the balloon tooltip showing when watching fullscreen tv/video the whole taskbar has to get forced on top just before the balloon tooltip triggers. In fact such a feature could be perceived as quite annoying by some, hence the suggestion to have it optional. No worries though...this is not so big of a deal The WEB API change however would take care of several, by design less desirable consequences in one sweep

Edited August 7, 2011 by majstang