Recording metadata - TPeterson
-
- Posts: 130
- Joined: Thu May 31, 2007 8:29 pm
- Device ID: 10123716, 10157425, 1039FE2B, 103AEA6C, 1075D4B1, 1076C3A7, 1080F19F
- Location: San Carlos, CA
- Contact:
Re: Recording metadata - 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!
-
- Posts: 2546
- Joined: Fri Apr 05, 2013 9:20 am
- Device ID: 1041A706, 1043EB32, 104BAD9E, 13168DC5, 1322A7AC
- Location: West Rockhill, PA
- x 5
Re: Recording metadata - TPeterson
Good to know, thanks. My OCD dictates everything must match so I'll keep doing it my way even if it's wrong.
Re: Recording metadata - TPeterson
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.
-
- Posts: 2546
- Joined: Fri Apr 05, 2013 9:20 am
- Device ID: 1041A706, 1043EB32, 104BAD9E, 13168DC5, 1322A7AC
- Location: West Rockhill, PA
- x 5
Re: Recording metadata - TPeterson
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 wrote: ↑Wed Apr 10, 2024 11:37 am 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.
-
- Posts: 130
- Joined: Thu May 31, 2007 8:29 pm
- Device ID: 10123716, 10157425, 1039FE2B, 103AEA6C, 1075D4B1, 1076C3A7, 1080F19F
- Location: San Carlos, CA
- Contact:
Re: Recording metadata - 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?
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?
-
Online
- Silicondust
- Posts: 45
- Joined: Thu Mar 02, 2023 10:48 am
- Device ID: 108042A1, 10814D8E
- Location: Arizona
Re: Recording metadata - TPeterson
The phone home is to ensure the record engine syncs up with the guide, time sync, notifications for recordings, etc..TPeterson wrote: ↑Mon Apr 15, 2024 3:24 pm 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?
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.
I think there may be some confusion on that power management setting.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?
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.
-
- Posts: 130
- Joined: Thu May 31, 2007 8:29 pm
- Device ID: 10123716, 10157425, 1039FE2B, 103AEA6C, 1075D4B1, 1076C3A7, 1080F19F
- Location: San Carlos, CA
- Contact:
Re: Recording metadata - 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.
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.
-
Online
- Silicondust
- Posts: 45
- Joined: Thu Mar 02, 2023 10:48 am
- Device ID: 108042A1, 10814D8E
- Location: Arizona
Re: Recording metadata - TPeterson
Ahhh - the request for ES_SYSTEM_REQUIRED to prevent system sleep makes more sense to me.TPeterson wrote: ↑Tue Apr 16, 2024 9:09 am @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.
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.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.
Makes sense.
so you really just want a DVR playout engine - not record engine.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.
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.
-
- Posts: 130
- Joined: Thu May 31, 2007 8:29 pm
- Device ID: 10123716, 10157425, 1039FE2B, 103AEA6C, 1075D4B1, 1076C3A7, 1080F19F
- Location: San Carlos, CA
- Contact:
Re: Recording metadata - TPeterson
Now we're on the same page.rikd wrote: ↑Tue Apr 16, 2024 9:58 amso 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.
Any chance of seeing these changes?