[scott967]

I want to update what is getting shown in FullScreenLiveTV window.  I was looking at Estuary as an example skin but have the following which seems confusing:

My PVR client (PVR.WMC) supports "time shift" or "chasing playback".  What Estuary shows is info about the now playing (clock time) EPG item and a second progress bar for the timeshift buffer.  The problem is first the timeshift buffer progress isn't really useful that I can see, except in seeking backwards, as it seems to stop at where I am in playback, not where the buffer actually is.  For example, I start watching and "pause" liveTV.  The timeshift progress is "frozen" in time, even though it actually is growing.  The timeshiftoffset shows you how much "behind" you actually are.  ISTM the timeshift progess should show the duration between when timeshift recording started and current time.

The second problem is displaying the EpgEventElapsedTime, EpgEventDuration and PVR.EpgEventProgress.  When the "real time" EPG has switched to the "next EPG" that's what I see so it's stuck on 00:00 / 01:00:00 for example because I am playing back from the timeshift buffer in the previous EPG entry.  It seems more useful to show the EPG info for the EPG entry I currently am viewing in the timeshift buffer.   I could maybe provide a small indication of "what's playing now" EPG in the corner.

It's really confusing. In the upper right of Estuary I have an "ends at" and the time there is the clock time the playing now EPG entry would end IF I jump ahead in the timeshift buffer to the start of the playing now entry.  But there isn't an easy way I see to know to how far I need to seek forward to get to the start of the last EPG covered by the timeshift buffer.

Or maybe there's some alternatives I could skin that would work better for me than what I see in Estuary?

scott s.
.

[ksooo]

I want to update what is getting shown in FullScreenLiveTV window.  I was looking at Estuary as an example skin but have the following which seems confusing:

My PVR client (PVR.WMC) supports "time shift" or "chasing playback".  What Estuary shows is info about the now playing (clock time) EPG item and a second progress bar for the timeshift buffer.  The problem is first the timeshift buffer progress isn't really useful that I can see, except in seeking backwards, as it seems to stop at where I am in playback, not where the buffer actually is.  For example, I start watching and "pause" liveTV.  The timeshift progress is "frozen" in time, even though it actually is growing.  The timeshiftoffset shows you how much "behind" you actually are.  ISTM the timeshift progess should show the duration between when timeshift recording started and current time.

The second problem is displaying the EpgEventElapsedTime, EpgEventDuration and PVR.EpgEventProgress.  When the "real time" EPG has switched to the "next EPG" that's what I see so it's stuck on 00:00 / 01:00:00 for example because I am playing back from the timeshift buffer in the previous EPG entry.  It seems more useful to show the EPG info for the EPG entry I currently am viewing in the timeshift buffer.   I could maybe provide a small indication of "what's playing now" EPG in the corner.

It's really confusing. In the upper right of Estuary I have an "ends at" and the time there is the clock time the playing now EPG entry would end IF I jump ahead in the timeshift buffer to the start of the playing now entry.  But there isn't an easy way I see to know to how far I need to seek forward to get to the start of the last EPG covered by the timeshift buffer.

Or maybe there's some alternatives I could skin that would work better for me than what I see in Estuary?

scott s.
.

The add-on needs to be adapted to support the API function GetStreamTimes. Otherwise all kind of weird play and epg time related GUI issues can be observed which are not solvable by skinning.

[scott967]

The add-on needs to be adapted to support the API function GetStreamTimes. Otherwise all kind of weird play and epg time related GUI issues can be observed which are not solvable by skinning. 

  

I was afraid of something like that. Is there a reference client that can be used for skin testing? Also, a way to test if a client has implemented GetStreamTimes?

scott s.
.

[ksooo]

The add-on needs to be adapted to support the API function GetStreamTimes. Otherwise all kind of weird play and epg time related GUI issues can be observed which are not solvable by skinning. 

  

I was afraid of something like that. Is there a reference client that can be used for skin testing? Also, a way to test if a client has implemented GetStreamTimes?

scott s.
.

For example pvr.hts or pvr.vdr.vnsi are well maintained and properly adapted.

If you want to know if an add-on already was adapted, you have to look at the code (or ask me, I can look this up in the code for you, then).

[scott967]

The add-on needs to be adapted to support the API function GetStreamTimes. Otherwise all kind of weird play and epg time related GUI issues can be observed which are not solvable by skinning. 

  

I was afraid of something like that. Is there a reference client that can be used for skin testing? Also, a way to test if a client has implemented GetStreamTimes?

scott s.
.   

For example pvr.hts or pvr.vdr.vnsi are well maintained and properly adapted.

If you want to know if an add-on already was adapted, you have to look at the code (or ask me, I can look this up in the code for you, then).   

 OK I poked around the source for PVR.WMC and see this in client.cpp: 

Code:

+ PVR_ERROR IsEPGTagPlayable(const EPG_TAG*, bool*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR IsEPGTagRecordable(const EPG_TAG*, bool*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetEPGTagStreamProperties(const EPG_TAG*, PVR_NAMED_VALUE*, unsigned int*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetStreamTimes(PVR_STREAM_TIMES*) { return PVR_ERROR_NOT_IMPLEMENTED; } 
+ PVR_ERROR GetStreamProperties(PVR_STREAM_PROPERTIES* pProperties) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetChannelStreamProperties(const PVR_CHANNEL* channel, PVR_NAMED_VALUE* properties, unsigned int* iPropertiesCount) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetRecordingStreamProperties(const PVR_RECORDING*, PVR_NAMED_VALUE*, unsigned int*) { return PVR_ERROR_NOT_IMPLEMENTED; }

Which I guess speaks for itself    but my question really is about is there a way for a skin to determine the capabilities of the client for these EPG things via a boolean for visiability?

scott s.
.

[ksooo]

  

I was afraid of something like that. Is there a reference client that can be used for skin testing? Also, a way to test if a client has implemented GetStreamTimes?

scott s.
.   

For example pvr.hts or pvr.vdr.vnsi are well maintained and properly adapted.

If you want to know if an add-on already was adapted, you have to look at the code (or ask me, I can look this up in the code for you, then).   

 OK I poked around the source for PVR.WMC and see this in client.cpp: 

Code:

+ PVR_ERROR IsEPGTagPlayable(const EPG_TAG*, bool*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR IsEPGTagRecordable(const EPG_TAG*, bool*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetEPGTagStreamProperties(const EPG_TAG*, PVR_NAMED_VALUE*, unsigned int*) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetStreamTimes(PVR_STREAM_TIMES*) { return PVR_ERROR_NOT_IMPLEMENTED; } 
+ PVR_ERROR GetStreamProperties(PVR_STREAM_PROPERTIES* pProperties) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetChannelStreamProperties(const PVR_CHANNEL* channel, PVR_NAMED_VALUE* properties, unsigned int* iPropertiesCount) { return PVR_ERROR_NOT_IMPLEMENTED; }
+ PVR_ERROR GetRecordingStreamProperties(const PVR_RECORDING*, PVR_NAMED_VALUE*, unsigned int*) { return PVR_ERROR_NOT_IMPLEMENTED; }

Which I guess speaks for itself    but my question really is about is there a way for a skin to determine the capabilities of the client for these EPG things via a boolean for visiability?

scott s.
.

No, and there will not be. Add-ons must implement the API properly, then no special skin voodoo is required.