[CiNcH]

Hey guys,

I am using the DVBViewer Recording Service (later referred to as RS) as PVR backend to KODI under Windows. I investigated a bit on the suspend (later referred to as Sleep) behavior when both are running on the same PC.

The RS prevents Sleep on Windows by setting the ES_AWAYMODE_REQUIRED flag as soon as a streaming (UPnP) client is connected. This means that whenever you use Live TV inside KODI on the same PC, Sleep is always prevented unless you manually execute a Stop (playback) before.

The way I think KODI works is that it waits for the PBT_APMSUSPEND event and stops all playback there. In this way you equally handle an externally triggered Sleep. This is too late for Live TV though. In fact you shouldn't even get this event with the ES_AWAYMODE_REQUIRED flag being set by the RS.

I would suggest to execute another Stop when the user triggers Suspend from within KODI right before the PC is put to the Sleep state. When a user tries to trigger Suspend from within KODI, he sure does not want to consume any media any longer, even if another program prevents Sleep (maybe due to a pending recording) and you never receive the PBT_APMSUSPEND event.

Or do you think that the RS should not prevent Sleep when a streaming client is connected? What if remote network clients are connected? You usually don't want the RS PC to go to sleep then. Or should local and remote clients be handled differently within the RS?

I would love to hear your opinions.

[scarecrow420]

I guess this is why my preference is to run a dedicated backend machine rather than trying to combine the duties of backend (that may be performing recordings or have remote clients connected to it) and front end (where users are consuming media). That said, I dont even have my backend machine go to sleep at all, since it's in a cupboard out of the way anyway. But certainly my front end clients all get suspended or powered off when nobody is using them

[CiNcH]

Indeed, there are quite some complications when running frontend and backend on the same machine. But I think it can properly be done.

I would suggest to execute another Stop when the user triggers Suspend from within KODI right before the PC is put to the Sleep state. When a user tries to trigger Suspend from within KODI, he sure does not want to consume any media any longer, even if another program prevents Sleep (maybe due to a pending recording) and you never receive the PBT_APMSUSPEND event.

Also USB-CEC shutdown should be executed before the actual Suspend/Sleep as the user declares not to need the display anymore. A pending recording or a remote streaming client, which might prevent the PBT_APMSUSPEND event, does not need the display.

USB-CEC shutdown is currently also done on the PBT_APMSUSPEND event according to the KODI log, which does not work properly at all. KODI freezes here. Seems like it does not manage to execute the USB-CEC shutdown in time:

Code:

15:21:21 T:2136   DEBUG: WM_POWERBROADCAST: PBT_APMSUSPEND event was sent
15:21:21 T:2136   DEBUG: CAnnouncementManager - Announcement: OnSleep from xbmc
15:21:21 T:2136   DEBUG: GOT ANNOUNCEMENT, type: 8, from xbmc, message OnSleep
15:21:21 T:4760   DEBUG: PERIPHERALS::CPeripherals::GetMappingForDevice - device (2548:1002) mapped to Pulse-Eight CEC Adapter (type = cec)
15:21:21 T:4812   DEBUG: Thread CECAdapterUpdate 4812 terminating
15:21:21 T:524   DEBUG: PERIPHERALS::CPeripheralCecAdapter::Process - sending standby commands
15:21:21 T:6008   DEBUG: PERIPHERALS::CPeripheralCecAdapter::CecLogMessage - << Recorder 1 (1) -> TV (0): POLL
15:21:21 T:6008   DEBUG: PERIPHERALS::CPeripheralCecAdapter::CecLogMessage - << 10
15:21:21 T:6008   DEBUG: PERIPHERALS::CPeripheralCecAdapter::CecLogMessage - error writing command 'CEC transmission' to serial port 'COM6': unable to get default config: Falscher Parameter.
15:21:21 T:6008   ERROR: PERIPHERALS::CPeripheralCecAdapter::CecLogMessage - error reading from serial port: unable to get default config: Falscher Parameter.
15:21:38 T:4760   DEBUG: PERIPHERALS::CPeripherals::GetMappingForDevice - device (2548:1002) mapped to Pulse-Eight CEC Adapter (type = cec)
15:21:39 T:524   DEBUG: PERIPHERALS::CPeripheralCecAdapter::Process - CEC adapter processor thread ended
15:21:41 T:3240   DEBUG: Thread JobWorker 3240 terminating (autodelete)
15:21:41 T:4644   DEBUG: Thread JobWorker 4644 terminating (autodelete)
15:21:43 T:4760   DEBUG: PERIPHERALS::CPeripherals::GetMappingForDevice - device (2548:1002) mapped to Pulse-Eight CEC Adapter (type = cec)

For an externally triggered Suspend/Sleep (e.g. via Windows Start-Menu), KODI can try to execute the USB-CEC shutdown on the PBT_APMSUSPEND event. But if it fails, KODI should not freeze like it currently does.

I just think that it is a bad idea to do everything on the PBT_APMSUSPEND event.