[janbar]

... just not 'UpdateRecordingRule'.

I never said "not UpdateRecordingRule". Probably also for this call. I let you check from the mythtv code.

What else, about "force push", i push force rarely, only when last changes crash completely and work has to be go directly in the trash. But there is no problem for development because you have to rebase on it: "git fetch upstream doityourself ; git rebase upstream/doityourself" will do the job for you. Also you can quickly refresh a branch which has been forced: "git fetch upstream doityourself ; git reset --hard upstream/doityourself"

[metaron]

... just not 'UpdateRecordingRule'.

I never said "not UpdateRecordingRule". Probably also for this call. I let you check from the mythtv code.

Sorry, I don't understand exactly what you mean but I think it is important.
(Probably this relates to my PR where I removed the 'EPG' check before UpdateRecordingRule ?)

Can you explain?

[janbar]

@metaron, currently i check the addon against api 3.0.0 and i saw a new issue:
- Seems "start time", "end time" fields have been deleted for timer using "first day". So it is not possible to setup a daily or weekly rule based on time as before.

These timers have correct flags (PVR_TIMER_TYPE_SUPPORTS_START_TIME & PVR_TIMER_TYPE_SUPPORTS_END_TIME) as below:

Code:

PVR_TIMER_TYPE_IS_REPEATING |
            PVR_TIMER_TYPE_SUPPORTS_ENABLE_DISABLE |
            PVR_TIMER_TYPE_SUPPORTS_TITLE_EPG_MATCH |
            PVR_TIMER_TYPE_SUPPORTS_CHANNELS |
            PVR_TIMER_TYPE_SUPPORTS_START_TIME |
            PVR_TIMER_TYPE_SUPPORTS_END_TIME |
            PVR_TIMER_TYPE_SUPPORTS_FIRST_DAY |
            PVR_TIMER_TYPE_SUPPORTS_START_END_MARGIN |
            PVR_TIMER_TYPE_SUPPORTS_PRIORITY |
            PVR_TIMER_TYPE_SUPPORTS_LIFETIME |
            PVR_TIMER_TYPE_SUPPORTS_RECORDING_GROUP,
            XBMC->GetLocalizedString(30462), // Record weekly

Before api change this type (above) had entry fields: start time (hour, minute) , end time (hour, minute) and first day date, as expected.

[metaron]

@metaron, currently i check the addon against api 3.0.0 and i saw a new issue:
- Seems "start time", "end time" fields have been deleted for timer using "first day". So it is not possible to setup a daily or weekly rule based on time as before.

I see the same here with your latest doityourself.
Certainly this isn't as intended.
Will investigate.

EDIT: Seems it only affects 'new' timers. Existing ones correctly show start and end times.
Probably it got introduced while rebasing. Unfortunatley I've got to be somewhere this morning, but I will work on a solution this evening.

[janbar]

Before api 3.0.0 , we have fields as expected:

START_END_TIME => start date (date), start time (h:m), end date (date) , end time (h:m)

FIRST_DAY + START_END_TIME => first day (date) , any time check box, start time (h:m), end time (h:m)

[janbar]

Probably it got introduced while rebasing. Unfortunatley I've got to be somewhere this morning, but I will work on a solution this evening.

Thanks. Nothing urgent, save your time ! I will continue to check ...

[metaron]

Probably it got introduced while rebasing. Unfortunatley I've got to be somewhere this morning, but I will work on a solution this evening.

Thanks. Nothing urgent, save your time ! I will continue to check ...

The problem is that bStartAnyTime and bEndAnyTime default to true, even when PVR_TIMER_SUPPORTS_END_ANYTIME and PVR_TIMER_SUPPORTS_START_ANYTIME are not set by the timer type. As the bStartAnyTime and bEndAnyTime variables drive the visibility of the START and END time settings, they are hidden when creating a new timer in these circumstances. 'FIRST DAY' is unrelated to the issue.

This gives me an idea for a 'proper' solution in kodi core, but in the meantime @janbar, if you set PVR_TIMER_SUPPORTS_END_ANYTIME and PVR_TIMER_SUPPORTS_START_ANYTIME for Daily/Weekly rules, you will get back to something approximating the old behaviour.

[metaron]

The problem is that bStartAnyTime and bEndAnyTime default to true, even when PVR_TIMER_SUPPORTS_END_ANYTIME and PVR_TIMER_SUPPORTS_START_ANYTIME are not set by the timer type. As the bStartAnyTime and bEndAnyTime variables drive the visibility of the START and END time settings, they are hidden when creating a new timer in these circumstances. 'FIRST DAY' is unrelated to the issue.

See https://github.com/xbmc/xbmc/pull/7875

[janbar]

I activated the feature to override "not recording" rule (commit b1ebef5). To test it use the scenario below:

1 - Create a situation with upcomings having status "Later showing", "Earlier recording", "Previous recording" etc ...
2 - Go to timer screen and enable "Show not recordings" by context menu "Client actions -> Show/hide rules with status 'Not Recording'"
3 - Now upcoming 'not recording' are displayed with status "Inactive"
4 - You can check the MythTV status by context menu "Client actions -> Show status of scheduling"
5 - To override the rule and force recording: just enable the timer.
Delete or disable the overriden timer to cancel override.

[metaron]

@janbar - I tried your latest doityourself with the 'show not recording' feature and it seems to work well.

The only slightly confusing thing is that Icons are shown indicating that a recording will happen for these 'inactive' upcomings. I guess this is something that needs to be fixed in kodi core.

Unfortunately while testing I managed to crash kodi just after selecting an item to 'show status of scheduling' from the 'client specific' menu.

Crashlog: http://xbmclogs.com/ptvvkvvdp

[janbar]

Unfortunately while testing I managed to crash kodi just after selecting an item to 'show status of scheduling' from the 'client specific' menu.

Code:

Thread 1 (Thread 0xb376e740 (LWP 32695)):
#0  __shared_ptr (this=0xbfe29e48, this@entry=0xbfe29df8) at /usr/lib/gcc/i586-pc-linux-gnu/4.8.4/include/g++-v4/bits/shared_ptr_base.h:779
#1  shared_ptr (this=0xbfe29e48, this@entry=0xbfe29df8) at /usr/lib/gcc/i586-pc-linux-gnu/4.8.4/include/g++-v4/bits/shared_ptr.h:103
#2  PVR::CPVRTimerInfoTag::GetEpgInfoTag (this=0x0) at PVRTimerInfoTag.cpp:856

I haven't this issue here. It is related to kodi core and it could be linked with your timers data. Probably a new issue to fix in api.

EDIT: I have lot of crash in EPG screen since this stuff has been refactored, and it could be linked with yours.

[janbar]

The only slightly confusing thing is that Icons are shown indicating that a recording will happen for these 'inactive' upcomings. I guess this is something that needs to be fixed in kodi core.

Yes it is in kodi. I guess current code doesn't use member IsActive() to show the icon in epg.

[metaron]

Unfortunately while testing I managed to crash kodi just after selecting an item to 'show status of scheduling' from the 'client specific' menu.

Code:

Thread 1 (Thread 0xb376e740 (LWP 32695)):
#0  __shared_ptr (this=0xbfe29e48, this@entry=0xbfe29df8) at /usr/lib/gcc/i586-pc-linux-gnu/4.8.4/include/g++-v4/bits/shared_ptr_base.h:779
#1  shared_ptr (this=0xbfe29e48, this@entry=0xbfe29df8) at /usr/lib/gcc/i586-pc-linux-gnu/4.8.4/include/g++-v4/bits/shared_ptr.h:103
#2  PVR::CPVRTimerInfoTag::GetEpgInfoTag (this=0x0) at PVRTimerInfoTag.cpp:856

I haven't this issue here. It is related to kodi core and it could be linked with your timers data. Probably a new issue to fix in api.

EDIT: I have lot of crash in EPG screen since this stuff has been refactored, and it could be linked with yours.

Logged as http://trac.kodi.tv/ticket/16229

[janbar]

The only slightly confusing thing is that Icons are shown indicating that a recording will happen for these 'inactive' upcomings. I guess this is something that needs to be fixed in kodi core.

Yes it is in kodi. I guess current code doesn't use member IsActive() to show the icon in epg.

I proprose this PR to fix it: https://github.com/xbmc/xbmc/pull/7923

[janbar]

@metaron you could try this commit: https://github.com/janbar/xbmc/commit/53...1f93ecac0f , and let me know if it resolve the issue.

EDIT: I pushed force a new commit to use best style using swap()