Bugfix for undetected start of recording

[safokkens]

The python script didn't detect the start of a recording. So the script stopped right after starting. I made a very little adjustment and now it works (I think). Greetings, SA Fokkens

[b-jesch]

No, current recordings are dedected here: https://github.com/b-jesch/service.pvr.manager/blob/master/service.py#L106-L110, and this function is called just before your adjustment (line 144). The purpose of line 145 is to prevent a switch-off when the next timer is closer than startup and shutdown margin time.

Increase your startup/shutdown margins in setup if the script stopped right after start and a record becomes in progress.

[safokkens]

Hmm, I wrote an explanation that doesn't make sense... The situation I'm describing is a powered off machine with a recording upcoming. When it's time, the machine powers up and the script runs.

The script detects an upcoming recording, but after the recording has started (currentTime > wakeRec) isRec becomes 0. When I look at the definition of isRec it says "Recording is or becomes active". So it should still be 1 I think,

Because isRec = 0, the script stops and will never shut down the machine. The way I fixed it makes the machine power off, but maybe my fix isn't right. Maybe you could try above scenario and find the real cause of the problem?

margin_start = 120 margin_stop = 60

I don't understand your suggestion of making the margins bigger: in that case I have to make the margin_start + margin_stop as long as my recording for the right effect.

[b-jesch]

No. I try to explain this. I use status flags which determines the different states of the system (pending recording, future recordings, epg grabbing, network activity and so on). This flags are combined with bitwise OR from several subroutines, they are not only logical states like true or false.

If the service starts after power up https://github.com/b-jesch/service.pvr.manager/blob/master/service.py#L314, it runs at first a system condition check (in this case mode is None). This check returns with _flags. Let's diving in:

https://github.com/b-jesch/service.pvr.manager/blob/master/service.py#L159-L163: At first we reset all _flags: 00000. Then we call the function get_pvr_events(_flags). Here we get the recording status of the pvr client via JSON-RPC. The client must support this RPC call, maybe there is the problem. I use hts pvr client (TVHeadend) and I get the correct result - recording flag is set to 1 (or not if there isn't a current running schedule): _flags |= isRec --> bitwise OR --> 00010 https://github.com/b-jesch/service.pvr.manager/blob/master/service.py#L159-L163. At next we check the time until next recording. Here we check the margins: If the sum of start margin + end margin (e.g. 90 secs) greater than the time until next schedule, we set also the _flags to isRec (bitwise OR). This is important to prevent a kickoff of the service or prevent a shutdown of the system (if a user initiates a poweroff).

• If this flag was not set before, we set it now from 00000 -> 00010.
• if this flag was already set (get_pvr_events), the state of this flag is unaltered then (always 00010

).

With a bitwise OR (|=) we set a flag (independent if it is already set or not), bitwise AND (&=) we reset a flag.

Understand now? ;)

[safokkens]

Thank you for your patience and explanation. I know how bitwise OR works, but my knowledge of this script is very poor. So please excuse me for making the wrong conclusions. :)

I'll explain what happens on my mediaplayer. I added lots of debug messages to service.py to be sure about the sequence of the script. I made a recording in TVHeadend starting 20:25, ending 20:27. In TVHeadend I use a margin (pre and post) of 4 minutes, so that gives me a start time of 20:21. In the PVR manager I use a start margin of 120 seconds, and a stop margin of 60 seconds. That gives me a boot time of 20:19, and that's exactly the moment my mediaplayer starts booting.

The script starts (mode=None) and fires getSysState() and then get_pvr_events(). The JSON response about "recording" returns a FALSE: because the current time is 20:19, and according to TVHeadend the recording has to start at 20:21. So isREC becomes 0 and I think that's correct. The logging shows a message: "No active timers yet, prepare timer@2018-03-22 19:19:24".

After that, I get a message "Status changed: 10000 (RES/NET/PRG/REC/EPG)", and then the service finishes. Because the service finishes, after the recording is finished the mediaplayer isn't powered down.

When I reduce the margins in PVR manager to 30 seconds, everything works. But with a big margin, TVHeadend hasn't started recording yet, and the script terminates. So, isREC is 0 and that's OK because recording hasn't started. But the next part is about upcoming recordings, and the first upcoming recording starts in 120 seconds. In my opinion, if the upcoming timer starts within the period defined in margin_start (120 seconds in my case), the script shouldn't stop but keep polling or set isREC to 1. That way the script will shut down my system after the recording has finished.

I can send you my service.py (with debug messages) alongside my log if you want.

[b-jesch]

Yes, sorry that was my mistake to tell you increasing the margin times instead of decreasing.

But the next part is about upcoming recordings, and the first upcoming recording starts in 120 seconds. In my opinion, if the upcoming timer starts within the period defined in margin_start (120 seconds in my case), the script shouldn't stop but keep polling or set isREC to 1. That way the script will shut down my system after the recording has finished.

Yes, that should be the behaviour. If now all things work as well I'll close the request.

[safokkens]

Okay I understand.

Maybe you could add the margin to the part in the script that's determining upcoming recordings like I suggested. That way users aren't dependent on the exact right margin. You'll still need the margins for slow booting machines. But if you pick a margin too big, everything still works.

For me the problem is indeed solved, so the request can be closed. If you're interested I can make a version of the script as I suggested above.

Thanks for all the help, S.A. Fokkens

Op zo 18 mrt. 2018 20:54 schreef Birger Jesch notifications@github.com:

No, current recordings are dedected here: https://github.com/b-jesch/service.pvr.manager/blob/master/service.py#L106-L110 http://url, and this function is called just before your adjustment (line 144). The purpose of line 145 is to prevent a switch-off when the next timer is closer than startup and shutdown margin time.

Increase your startup/shutdown margins in setup if the script stopped right after start and a record becomes in progress.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/b-jesch/service.pvr.manager/pull/2#issuecomment-374039131, or mute the thread https://github.com/notifications/unsubscribe-auth/AIUJa-RooYU5u4W6WIj8Bmf_FUAz95mvks5tfrtngaJpZM4Ss6up .