Recording metadata - TPeterson

[TPeterson]

Thanks for the additional info. I have to apologize for misleading folks about the progress bar's mis tracking. It turns out that is only an issue on the LG TV-hosted app, which is a shame since that's the one that does AC4 audio!

[Ken.F]

Suggest not changing the EndTime as EndTime is the scheduled EndTime and not related to the length of the recording. In practice we only use StartTime in the UI.

Good to know, thanks. My OCD dictates everything must match so I'll keep doing it my way even if it's wrong.

[nickk]

Suggest not changing the EndTime as EndTime is the scheduled EndTime and not related to the length of the recording. In practice we only use StartTime in the UI.

Good to know, thanks. My OCD dictates everything must match so I'll keep doing it my way even if it's wrong.

RecordStartTime and RecordEndTime should be different to StartTime and EndTime anyway due to padding.

StartTime and EndTime is the TV guide... if you change the EndTime it will no longer match the TV guide and won't make sense.

If you are editing the length of the file set RecordStartTime to StartTime (the original start padding is no longer relevant) and set the RecordEndTime to StartTime + edited length. Think of the recording as having negative end padding.

[Ken.F]

RecordStartTime and RecordEndTime should be different to StartTime and EndTime anyway due to padding.

StartTime and EndTime is the TV guide... if you change the EndTime it will no longer match the TV guide and won't make sense.

If you are editing the length of the file set RecordStartTime to StartTime (the original start padding is no longer relevant) and set the RecordEndTime to StartTime + edited length. Think of the recording as having negative end padding.

Yes, that is exactly what I do, but I also change the EndTime to match the RecordEndTime since the end padding has been edited out. After the recording has been completed it doesn't matter (to me) if the EndTime no longer matches the TV guide since I can't look back at past programs in the guide.

[nickk]

but I also change the EndTime to match the RecordEndTime since the end padding has been edited out.

Ok, just know that doing so is wrong as per our schema.

[Ken.F]

Ok, just know that doing so is wrong as per our schema.

Got it.

[TPeterson]

I see from the logs that the DVR engine creates that it rather frequently "phones home" to find out, among other things, whether I've subscribed to the DVR service. Given that I only intend to use the HDHomerun viewer app to play local recordings, that seems unnecessary O/H for both Silicondust and me. Is there any setting available to mitigate these communications?

Also, I know that your DVR paradigm requires the recording machines to stay powered 24/7, but our method only powers them up for the actual recording, scheduling, and playback sessions with Power Options set to put them to sleep otherwise. I've found however that playback via the DVR engine does not honor the PC's setting "do not sleep during media streaming". Could you change its behavior to honor that setting, please?

[rikd]

I see from the logs that the DVR engine creates that it rather frequently "phones home" to find out, among other things, whether I've subscribed to the DVR service. Given that I only intend to use the HDHomerun viewer app to play local recordings, that seems unnecessary O/H for both Silicondust and me. Is there any setting available to mitigate these communications?

The phone home is to ensure the record engine syncs up with the guide, time sync, notifications for recordings, etc..
i.e. if recording of an event is required, the client will request the cloud service to add the scheduled event - and the DVR engine then phones home periodically to get notification of that event. It doesn't require the HDHomerun Viewer App to be the creator of that event - pretty much any authorized client can add scheduled events to the cloud service - thus the DVR engine must stay in sync with the cloud service to get ALL scheduled events when necessary.

Also, I know that your DVR paradigm requires the recording machines to stay powered 24/7, but our method only powers them up for the actual recording, scheduling, and playback sessions with Power Options set to put them to sleep otherwise. I've found however that playback via the DVR engine does not honor the PC's setting "do not sleep during media streaming". Could you change its behavior to honor that setting, please?

I think there may be some confusion on that power management setting.
Do not sleep during media streaming/sharing ensures that when using the GPU for displaying (sharing/streaming) a video to the screen the device will not go to sleep. It has nothing to do with the streaming of a file via IP over your network - that is generally the CPU/storage/network power management settings - and typically device will not sleep if the CPU is active (reading from disk, packetizing and sending over network).

But am a little confused - you say you put the device to sleep via power options, but then are wondering why it does go to sleep?
Are you expecting the device to wake up if someone decides to stream?
If so - that is definitely not the intention of that power management setting - instead you would need some 'wake on lan' setting to wake up the PC once some client tries to attach to the DVR engine.. then assuming the device wakes up in time and services the request then it should do so and will go to sleep once the CPU, storage and network go idle. But be warned - that time to wake can be more considerable than you may think and could result in the API request to the engine timing out.

[TPeterson]

@rikd, thanks for your reply. Since you're new to this conversation, some background seems to be in order. CW_EPG, my HDHR PVR app (user manual here), has been using HDHR tuners (and others before there were HDHR tuners) for many years. It handles scheduling and recording sessions via Windows waketimers and setting the Windows do-not-sleep flag (ES_SYSTEM_REQUIRED) for the duration of those events. Otherwise, it clears that flag so that the system goes to sleep after the user-designated interval of inactivity. If the system has the "do not go to sleep while media streaming" flag set, the system will stay awake if the usual SMB file requests have been made. This works for streaming using VLC, etc., but does not work; e.g., with LG's DLNA server which somehow is not visible to that watchdog, so the system falls asleep after the Power Options interval has passed.

Silicondust's original recording app hdhomerun_config.exe clearly also used ES_SYSTEM_REQUIRED to stay awake for recordings. However, it appears that the DVR engine, like the LG DLNA server, does not set it when serving recorded media, presumably because it's assumed to be running on a 24/7 host. I'm asking that you change that, please.

Regarding the "phone home" activity, CW_EPG is not going to request EPG data, time sync, or recording schedules from Silicondust's server because its user is not subscribed to the DVR service. It only needs the DVR engine's involvement to provide the HDHR viewer app access to locally recorded files. Therefore, all of the phone-home CPU cycles are wasted motion for both Silicondust and CW_EPG's user.

[rikd]

@rikd, thanks for your reply. Since you're new to this conversation, some background seems to be in order. CW_EPG, my HDHR PVR app (user manual here), has been using HDHR tuners (and others before there were HDHR tuners) for many years. It handles scheduling and recording sessions via Windows waketimers and setting the Windows do-not-sleep flag (ES_SYSTEM_REQUIRED) for the duration of those events. Otherwise, it clears that flag so that the system goes to sleep after the user-designated interval of inactivity. If the system has the "do not go to sleep while media streaming" flag set, the system will stay awake if the usual SMB file requests have been made. This works for streaming using VLC, etc., but does not work; e.g., with LG's DLNA server which somehow is not visible to that watchdog, so the system falls asleep after the Power Options interval has passed.

Ahhh - the request for ES_SYSTEM_REQUIRED to prevent system sleep makes more sense to me.

Silicondust's original recording app hdhomerun_config.exe clearly also used ES_SYSTEM_REQUIRED to stay awake for recordings. However, it appears that the DVR engine, like the LG DLNA server, does not set it when serving recorded media, presumably because it's assumed to be running on a 24/7 host. I'm asking that you change that, please.

so set this for the thread once the engine spins it up for streaming to the client. Otherwise the system will just drop back to sleep anyways if no active client attaches.
Makes sense.

Regarding the "phone home" activity, CW_EPG is not going to request EPG data, time sync, or recording schedules from Silicondust's server because its user is not subscribed to the DVR service. It only needs the DVR engine's involvement to provide the HDHR viewer app access to locally recorded files. Therefore, all of the phone-home CPU cycles are wasted motion for both Silicondust and CW_EPG's user.

so you really just want a DVR playout engine - not record engine.
i.e. something to parse the metdata on the TS files in a folder structure, provide a recordings list, and stream requested recordings (and stay awake ) to the client, all through HDHomeRun APIs to the client.
Makes sense.

[TPeterson]

so you really just want a DVR playout engine - not record engine.
i.e. something to parse the metdata on the TS files in a folder structure, provide a recordings list, and stream requested recordings (and stay awake ) to the client, all through HDHomeRun APIs to the client.
Makes sense.

Now we're on the same page.

Any chance of seeing these changes?