[hoppel118]

It's a pity. Greetings Hoppel

[Rjsachse]

Ok so this was a jarvis skinning change but no skinners have been able to add it in yet. It is a feature that alot of people want. My issue as a windows developer is that not much pvr addons support this. I have asked in mediaportal but seems margo has no idea how to implement it. Wmc addon krusty has seem to got it added but i can't find a way to implement it.

Is it time to revisit this?

Please don't remove but improve and maybe get the pvr devs on board.

[FernetMenta]

There will be a major change of the pvr api in v18. The streaming API will be split from the rest of pvr API and will go to inputstream extension point. After this all gui infos related to the playing stream will come from player, not PVRGUIInfo anymore.
Then it is up to the skins how to use those new values.

[aegidius]

Old thread but looking to see if my request had already been placed...

I would like (for a skin) infotags that show:
- the start of the timeshift buffer
- the current position being played (this is just Player.Progress)
- the end of the timeshift buffer

all as percentages of the program's time from start to end.

That way a skin could show a slider with a graphical indication of timeshift buffer coverage, in the simple and intuitive way that WMC does.

[Rantanplan-1]

There will be a major change of the pvr api in v18. The streaming API will be split from the rest of pvr API and will go to inputstream extension point. After this all gui infos related to the playing stream will come from player, not PVRGUIInfo anymore.
Then it is up to the skins how to use those new values.

Just curious

Does that mean we get (finaly) working Timeshift buffer/indicator for every backend?

That would be gr8!

Regards

[ksooo]

There will be a major change of the pvr api in v18. The streaming API will be split from the rest of pvr API and will go to inputstream extension point. After this all gui infos related to the playing stream will come from player, not PVRGUIInfo anymore.
Then it is up to the skins how to use those new values.

Just curious

Does that mean we get (finaly) working Timeshift buffer/indicator for every backend?

That would be gr8!

Regards

No magic happens here. If and only if the add-on implements it, it will be available in Kodi. Exactly, like it is today.

[omriamos]

There will be a major change of the pvr api in v18. The streaming API will be split from the rest of pvr API and will go to inputstream extension point. After this all gui infos related to the playing stream will come from player, not PVRGUIInfo anymore.
Then it is up to the skins how to use those new values.

Just curious

Does that mean we get (finaly) working Timeshift buffer/indicator for every backend?

That would be gr8!

Regards

No magic happens here. If and only if the add-on implements it, it will be available in Kodi. Exactly, like it is today.

So basically the answer is no....

What's weird though is that MediaPortal TV-Server for example does not "implement" anything, however the MediaPortal client is able to get this information from it...
So I believe that it is available, just not in the format Kodi's developers (obviously) chose for themselves.

[ksooo]

Just curious

Does that mean we get (finaly) working Timeshift buffer/indicator for every backend?

That would be gr8!

Regards

No magic happens here. If and only if the add-on implements it, it will be available in Kodi. Exactly, like it is today.

So basically the answer is no....

What's weird though is that MediaPortal TV-Server for example does not "implement" anything, however the MediaPortal client is able to get this information from it...
So I believe that it is available, just not in the format Kodi's developers (obviously) chose for themselves.

No idea what you want to tell us, but yeah,
there is a Kodi pvr add-on api for timeshift status which needs to be implemented properly by the different pvr add-ons, yes. Kodi has a pvr backend agnostic API to be able to support different pvr backends, yes. And for this, the backend specific data need to be converted to the Kodi format by the different pvr add-ons, yes.

Although I do not have any specific knowledge about mp server, I seriously doubt that the mp client can pull timeshift data out of thin air, without the mp server providing anything. If the mp client is able to obtain the data from the server, the server must provide access to this data (via an API).

Why do you quote "implement", btw? If you do not know what implement means in the context of software development you'd better not speak up here, honestly.

[omriamos]

No magic happens here. If and only if the add-on implements it, it will be available in Kodi. Exactly, like it is today.

So basically the answer is no....

What's weird though is that MediaPortal TV-Server for example does not "implement" anything, however the MediaPortal client is able to get this information from it...
So I believe that it is available, just not in the format Kodi's developers (obviously) chose for themselves.

No idea what you want to tell us, but yeah,
there is a Kodi pvr add-on api for timeshift status which needs to be implemented properly by the different pvr add-ons, yes. Kodi has a pvr backend agnostic API to be able to support different pvr backends, yes. And for this, the backend specific data need to be converted to the Kodi format by the different pvr add-ons, yes.

Although I do not have any specific knowledge about mp server, I seriously doubt that the mp client can pull timeshift data out of thin air, without the mp server providing anything. If the mp client is able to obtain the data from the server, the server must provide access to this data (via an API).

Why do you quote "implement", btw? If you do not know what implement means in the context of software development you'd better not speak up here, honestly.

LOL.
You're cute, you've probably been to kindergarten when I was first "implementing" things "in the context of software development".

Now let me clarify this for you:

1. Kodi is NOT the center of the world.
2. If you expect all other pvr servers in the world to implement kodi's own API, well, as you can see it hasn't been done for a few years now. So yeah... keep on dreaming.
3. MP client does not pull anything "out of thin air" - as I said before but your inflated ego didn't allow you do understand, it gets it from MP's TV-SERVER.
4. Hence, MP TV-SERVER definitely serves this information. In its own format of course, they didn't "IMPLEMENT" (here's this word again) Kodi's solution because why would they? They couldn't care less about you / kodi, they have their own format and if Kodi (or anyone else) want to get it - they can.
5. But Kodi is in no position to tell others how to implement (.......) their own API.
6. If Kodi wants to continue waiting forever until tv-servers developers will somehow start thinking / believing that they work for Kodi (.....) - then I guess we can meet up here again in 5 years when someone will bump this topic again and ask if there's any updates.....

[Gade]

I think you got this all wrong.

It's all the PVR add-ons made for Kodi that need to implement the timeshift status properly. That's it.

[ksooo]

So basically the answer is no....

What's weird though is that MediaPortal TV-Server for example does not "implement" anything, however the MediaPortal client is able to get this information from it...
So I believe that it is available, just not in the format Kodi's developers (obviously) chose for themselves.

No idea what you want to tell us, but yeah,
there is a Kodi pvr add-on api for timeshift status which needs to be implemented properly by the different pvr add-ons, yes. Kodi has a pvr backend agnostic API to be able to support different pvr backends, yes. And for this, the backend specific data need to be converted to the Kodi format by the different pvr add-ons, yes.

Although I do not have any specific knowledge about mp server, I seriously doubt that the mp client can pull timeshift data out of thin air, without the mp server providing anything. If the mp client is able to obtain the data from the server, the server must provide access to this data (via an API).

Why do you quote "implement", btw? If you do not know what implement means in the context of software development you'd better not speak up here, honestly.

LOL.
You're cute, you've probably been to kindergarten when I was first "implementing" things "in the context of software development".

Now let me clarify this for you:

1. Kodi is NOT the center of the world.
2. If you expect all other pvr servers in the world to implement kodi's own API, well, as you can see it hasn't been done for a few years now. So yeah... keep on dreaming.
3. MP client does not pull anything "out of thin air" - as I said before but your inflated ego didn't allow you do understand, it gets it from MP's TV-SERVER.
4. Hence, MP TV-SERVER definitely serves this information. In its own format of course, they didn't "IMPLEMENT" (here's this word again) Kodi's solution because why would they? They couldn't care less about you / kodi, they have their own format and if Kodi (or anyone else) want to get it - they can.
5. But Kodi is in no position to tell others how to implement (.......) their own API.
6. If Kodi wants to continue waiting forever until tv-servers developers will somehow start thinking / believing that they work for Kodi (.....) - then I guess we can meet up here again in 5 years when someone will bump this topic again and ask if there's any updates.....

Well, let's check. I'm 48 years old. Maybe you are older, but I guess there are good chances that there is not that much of a difference in age between you and me.

Although it seems that you are not able to stay polite, I'm not giving up on you (yet).

It seems you do not understand the underlying software architecture, thus we're not talking the same language. Let me try to explain:

1. There is Kodi, utilizing a tv backend agnosting API to implement Kodi's pvr functionality for different tv backends.

2. There are different tv backends (servers), each with its own feature set and own API.

3. In between 1 and 2 there is a Kodi pvr add-on, which translates data between a certain tv server and the generic Kodi API.

Nobody expects that a tv server implements the native Kodi API. This is the "job" of some Kodi pvr add-on developer. We do not expect anything from the tv server providers/developers! You got this important part just plain wrong and all your personal attacks are based on this misunderstanding, I guess.

[Rantanplan-1]

If you expect all other pvr servers in the world to implement kodi's own API,

This thells me u dont knew much about software development.

even if something bugs u, (at least) try to be nice! I knew specially kasooo does much for the PVR section! and he cares..

A lot offer a lot of there sparetime!!


Edi:
I knew specialy if it comes to PVR (with it various backends/servers) its not always easy to knew where to ask, and to finde out what or who is responcible for a specivic feature.

Edi2:
Jer, nd i also would like to see (working) timeshift (timeshiftbuffer) indicators in Kodi (MP-Server as well), guess we'll see ..

Edi3:
As i understand this correctly, if the MP-Server provides this info, the specivic Addon Developer shuld be able to provide this Info for Kodi, which would be god news imho.

i did also back in the day try to Skinn that stuff, but never get it working with MP-Backend, other did may try it to. (just refering to the second Post where the Skinners where blamed)

[Rantanplan-1]

Just curious..

Would it be possible for a Backend-Addon to show the buffer as

Code:

Player.ProgressCache

and the actual progress as

Code:

Player.Progress

?

This would be for me, from a Skinner perspective, the simplest way to implement a basic functionality.

what about to implement "PVR.TimeshiftStart" instead of

Code:

PVR.TimeshiftProgress

?

The Idea would be to have 3 Bars overlying each other.

PHP Code:

<!--  Progress bar -->
    <control type="progress" id="1">
        <left>350</left>
        <top>27</top>
        <width>1220</width>
        <height>6</height>
        <info>Player.Progress</info>
        <texturebg border="2">osd/OSDProgressBack.png</texturebg>
        <lefttexture>-</lefttexture>
        <midtexture border="2">osd/OSDProgressBar.png</midtexture>
        <righttexture>-</righttexture>
        <overlaytexture>-</overlaytexture>
    </control>

    <!--  Cache bar -->
    <control type="progress" id="1">
        <left>350</left>
        <top>27</top>
        <width>1220</width>
        <height>6</height>
        <info>Player.ProgressCache</info>
        <texturebg colordiffuse="00ffffff" border="2">osd/OSDProgressBack.png</texturebg>
        <lefttexture>-</lefttexture>
        <midtexture colordiffuse="66ffffff" border="2">osd/OSDProgressBar.png</midtexture>
        <righttexture>-</righttexture>
        <overlaytexture>-</overlaytexture>
    </control>

       <!--  NEW!:Cache-Start  bar -->
    <control type="progress" id="1">
        <left>350</left>
        <top>27</top>
        <width>1220</width>
        <height>6</height>
        <info>PVR.TimeshiftStart</info>
        <texturebg colordiffuse="00ffffff" border="2">osd/OSDProgressBack.png</texturebg>
        <lefttexture>-</lefttexture>
        <midtexture colordiffuse="66ffffff" border="2">osd/OSDProgressBar.png</midtexture>
        <righttexture>-</righttexture>
        <overlaytexture>-</overlaytexture>
    </control> 


The 3rd Bar could be darker (would overlay the other bars) and would only have a value if the Timeshift-startpoint would be greather than the beginning of the actual playing show.

In short
• CacheBar (Player.ProgressCache): indicates the last point to jump to (the actual/Live progress)

• ProgressBar (Player.Progres): Indicates where u actualy watching (actual/Live progress minus the time u skip back)

• NEW! "PVR.TimeshiftStart": Indicates how far back the timeshift can be used. (if the the starttime of the timeshift is lower than the start Time of the currently watching show, its empty, else it shows the differece between the show-startTime and the Timeshiftbuffer-StartTime.

Would be imho. a usable solution if doable.


EDIT:

Hers a quick illustration:



Wouldnt that make more sense than the current "two bar"-Solution i see on some Screens?

Not shure, its just a guess, but it could be its the "current" implementation which holds the different PVR-Backend devs back from supporting Timeshift indicators?


EDIT2:
Guess to fill "Player.ProgressCache", it wouldnt need any timeshift backend Info at all (("actual Time" - "show start Time") divided by ("show endtime" - "show start time") multiplied by 100 equals progress%)
may kinde of a Hack, but if it does the job?

[aegidius]

That is essentially the kind of scaled display that WMC provides. That would be perfect (and is what I tried to get going in my Mousetuary skin)

In addition, when WMC is chase-playing from a program that is being recorded, the timeshift-start corresponds to when the recording started.

It would be good (read: essential) for the data to be usable directly in the skin, or if not, some calculation functionality to be added to the skin engine to work out percentages, etc. on the fly.

[RockerC]

You're cute, you've probably been to kindergarten when I was first "implementing" things "in the context of software development".

Now let me clarify this for you:

1. Kodi is NOT the center of the world.
2. If you expect all other pvr servers in the world to implement kodi's own API, well, as you can see it hasn't been done for a few years now. So yeah... keep on dreaming.
3. MP client does not pull anything "out of thin air" - as I said before but your inflated ego didn't allow you do understand, it gets it from MP's TV-SERVER.

@omriamos, stop and do some research reading before replying.

Your comments only show that you do not understand the specific client–server model concept that Kodi have used for its PVR API implementation in Kodi's software architecture. The agnostic approach that they chosen might be unique enough that you have not stumbled upon it before when dealing with PVR, but such server-client concepts are not unique software architecture when talking about other client–server model applications.

You see, Kodi uses a client–server model concept with an open API which means that PVR server developers does not need to conform with Kodi's standard and nor does Kodi need to confirm with whatever standard that PVR server developers choose to use for their API. You really need to understand this specific client–server model you understand how the inner working PVR really works in Kodi, behind the scenes so to speak.

Please read Kodi's wiki article which explains how the different parts communicate in a chain to achieve its specific client–server model concept.

http://kodi.wiki/view/PVR

As you can read there, for each PVR backend/server you need a specific "PVR client addon" and each of those act as a translator speaking both the unique languages of Kodi's PVR API and the third-party PVR backend software.

Using this concept neither Kodi's own developers or the developers of third-party PVR backend software needs to follow the same standards or talk the same language, as the only one who needs to talk both languages is the developer of each specific "PVR client addon" in order to translate one to the other and vice versa. And in addition here you have to understand that the Kodi development team themselves are not necessary developers of PVR client addon for each PVR backend/server, that could be done by another third-party developer just like with any other addon.

Chain goes like this for each PVR backend/server which all have their own unique PVR client addon that acts as a middleman / man-in-the-middle as a translator:

Kodi frontend (Kodi's PVR API) <=> PVR client addon for each PVR backend/server (C binary addon) => third-party PVR backend/server software (PVR backend's own unique API)

So, if now Kodi's PVR API have support for receiving timeshift status and the PVR backend/server also have support for sending timeshift status then the missing link in the chain is for the developer of the PVR client addon for each PVR backend/server to implement support in the PVR client addon (C binary addon).

If you do not read this and grasp this concept fully then you should not reply any more, and if you do grasp it then maybe you should apologize for not grasping it earlier and instead making assumptions that made you say 'bad words' to some people here