Login at Kodi Home

**ksooo** · 2015-10-02, 07:49

The "what if the epg data is present at back-end but not loaded by Kodi, for example due to the default Kodi setting only to fetch three days from back-end" is a very common problem.

That's why I plan to introduce a new API function "GetEpgTag(unsigned not iEventId)" and to extend Kodi core to try to fetch missing EPG_TAGs on demand using this new function.

@Jönke yes, I think I have fixed find similar from guide window as well. My commit contained a very basic bug fix for the search window when it was triggered with a query from another window.

metaron · 2015-10-09, 17:53

(2015-10-02, 07:49)ksooo Wrote: That's why I plan to introduce a new API function "GetEpgTag(unsigned not iEventId)" and to extend Kodi core to try to fetch missing EPG_TAGs on demand using this new function.

+1 for that Smile

Jönke · 2015-10-14, 22:46

(2015-10-02, 07:49)ksooo Wrote: @Jönke yes, I think I have fixed find similar from guide window as well. My commit contained a very basic bug fix for the search window when it was triggered with a query from another window.

Tested with rpi build from yesterday, and find similar won´t work. It just closes the window and returns to guide

krustyreturns · 2015-10-15, 16:44

Hi guys,

Yesterday a user asked about large end padding for sporting events, I looked in more detail at how the padding is set in kodi16 and found that you couldn't set the padding greater than one hour. This really isn't enough for live sporting events, for instance in american football I always add two hours of end padding just to make sure the end of the game is captured.

And even if you want to set the end padding to the one-hour limit it takes 59 (!) button presses to get to it. I don't think is useful - does anybody really need to be able to set 51 minutes instead of 50 minutes? I suggest in the padding spinners we use non-linear settings for the beginning and ending padding and allow for much bigger values. In particular I suggest:
0 min, 1 min, 3 min, 5 min, 10 min, 15 min, 20 min, 30 min, 1 hour, 1.5 hour, 2 hour, 3 hour

This lets you set a small amount of padding, or a large amount, with very few clicks. I think this is standard for pvrs, so I think it would be safe to hardwire it in. But another option could be to let the backend fill out these spinner values. What do you guys think? Any chance we can get this change?

**negge** · 2015-10-15, 16:55

@ksooo didn't this change in Jarvis? Or was it just lifetime that was adopted?

If not, we could probably use the same values as for the "instant recording duration" setting which IIRC goes to 240 minutes.

**ksooo** · 2015-10-15, 16:58

No, did not touch this for Jarvis.

And this is actually not an API change request. This can be changed easily in Kodi core, if people feel this is useful. Don't have this on my own to-do list, though.

krustyreturns · 2015-10-15, 17:37

If we feed the padding values from the backend, is that an api change? Smile

**ksooo** · 2015-10-15, 17:38

Yes.

**negge** · 2015-10-16, 13:08

I don't think it makes sense to supply these values from the backend since they're just numbers. I'll try to remember to work on this during the weekend.

**ksooo** · 2015-10-16, 13:23

I agree with you on this, @negge.

krustyreturns · 2015-10-16, 16:47

That would be great @negge, thanks. My only reason for suggesting the backend feed these numbers was concern that some backends might have limits on how large the padding can be.

**negge** · 2015-10-16, 17:34

@krustyreturns IMO that's something the addon can take care of internally.

metaron · (This post was last modified: 2015-10-18, 00:35 by metaron.)

(2015-10-15, 16:44)krustyreturns Wrote: I suggest in the padding spinners we use non-linear settings for the beginning and ending padding and allow for much bigger values. In particular I suggest:
0 min, 1 min, 3 min, 5 min, 10 min, 15 min, 20 min, 30 min, 1 hour, 1.5 hour, 2 hour, 3 hour

This lets you set a small amount of padding, or a large amount, with very few clicks. I think this is standard for pvrs, so I think it would be safe to hardwire it in. But another option could be to let the backend fill out these spinner values. What do you guys think? Any chance we can get this change?

I agree this is a good suggestion, however for existing rules (or other frontentends), I would suggest that if a restricted list of options is presented that the list also have the 'current' one a rule is set to added (similar to what was done for first day/start day so as to accommodate days in the past).

**ksooo** · 2015-10-18, 10:14

+1 to what metaron said.

We should go for a hardwired list + 1 entry for the value actually supplied by the add-on, if that value is not in the hardwired list. This worked out quite well for instance for "first day" values where we already do it like this.

krustyreturns · 2015-10-18, 18:54

Another quibble with jarvis: You have a repeating timer created and then in the timer display you 'push' down into this timer to see its upcoming single episode timers (very cool btw). If you choose to delete one of these single timers kodi opens a dialog that says:

Do you want to delete this timer or the repeating timer that has scheduled it?

and your choices to answer this are: Yes or No

and the right answer is...? and if you answer wrong the entire series is deleted.

IMO it would be better to not ask the question at all and just delete the episode - if the user has made a point to push down into the repeating timer I'm pretty sure that is what they want to do. But if that change is not acceptable, then I think this dialog needs to be reworded.