[MikeB2013]

@janbar

Is there anyway to indicate in the Status column (or elsewhere) on the main timer screen, when Group timers is active, that there are recording conflicts or no conflicts ?

When Group timers is not active, the main timer screen shows every upcoming recording, but users may have to scroll to seen any conflicts.

Mike

[metaron]

@janbar

Is there anyway to indicate in the Status column (or elsewhere) on the main timer screen, when Group timers is active, that there are recording conflicts or no conflicts ?

When Group timers is not active, the main timer screen shows every upcoming recording, but users may have to scroll to seen any conflicts.

Mike

This was one of my previous 'fixes' (well the currently recording status part of it anyway). I've added 'conflict' status to the list and sent janbar a pull request ( https://github.com/janbar/pvr.mythtv/pull/6 )

NB: Noticed while doing this that the 'Conflict' status shows as 'Active' in the list, rather than 'Inactive' so attempting to 'fix' the conflict creates a 'don't record override' rule, rather than a 'record over-ride'. This clears the conflict, but not in the way I expected...

[janbar]

Hi @metaron. the rule status can have 2 values only (Actice/Inactive). The primary reason is this status is use to toogle the rule state in update screen or context menu. I cannot fill with "Conflict" which is linked with state "Inactive" in PVR code. So this state show rule status for repeating timer and not upcoming status.
If you look in MythWeb you have same view: rule page doesn't show upcoming status. I will make some test later to see what we can do. Also main screen of kodi (TV screen) should show you the conflicts and what happen around timers.

[MikeB2013]

@janbar @metaron

Just an update, all are against mythbackend 0.28pre

Switched back to building from xbmc master (now that Isengard has branched), with janbar pvr.mythtv doityourself for Ubuntu 15.04.

Raspberry pi now using Milhouse Openelec 16 daily builds, with janbar pvr.mythtv doityourself. Running well on pi1 (model B) and pi2

Tried Android build from source, crashes soon after starting with pvr.mythtv enabled, no on screen messages when communicating with mythbackend at kodi startup. I can provide debug log but prefer to concentrate on Ubuntu at present

Tried Windows build from source, does not crash, but pvr does not start, no on screen messages when communicating with mythbackend at kodi startup, again I can provide debug log but prefer to concentrate on Ubuntu at present

I can build from source for Ubuntu 15.04, Windows (7 and 8.1), Android (although this takes a long time to build) and Raspberry pi Openelec (if needed, but prefer to use Milhouse 16, as Openelec source build takes hours to build even on my core i7)

Mike

[metaron]

Hi @metaron. the rule status can have 2 values only (Actice/Inactive). The primary reason is this status is use to toogle the rule state in update screen or context menu. I cannot fill with "Conflict" which is linked with state "Inactive" in PVR code. So this state show rule status for repeating timer and not upcoming status.
If you look in MythWeb you have same view: rule page doesn't show upcoming status. I will make some test later to see what we can do. Also main screen of kodi (TV screen) should show you the conflicts and what happen around timers.

I guess presentation of conflict status and 'in progress' recordings for 'rules' should really be handled by PVR core in general, rather than squeezed in by the Addon as an afterthought. Probably best to give @ksooo a day or two to recover from his 'post merge code review' before the inevitable bikeshedding starts though ...

I'll re-work my pull request to just include the 'time' part as that simply works around a 'mythbackend' issue with in progress up-comings. Also means it doesn't need to iterate the full list, just check the 1st upcoming to see if it has an in-progress recording, in which case pull the start/end time from there. That is unless you think it would be better to just restore it from a pair of time_t variables set when the upcoming list is parsed?

[metaron]

@janbar @MikeB2013
I'm on Gentoo, i586 on a Core2 (it's a long story involving the untimely death of my original low-power backend's motherboard)
I also have RPi B+ and PI2 B models to play with and an OpenElec build environment at Isengard beta 2/Helix standard on the Core2 for compilation.
For now I'm using the PIs to check what I do is backwardly compatible, but could easily give the Millhouse 16 builds a whirl...

[MikeB2013]

@janbar @metaron

Conflicts

Is the mythtv services API Dvr/GetConflictList being used for this ?

I have just done a quick test, the API works for 0.27 and 0.28pre


Mike

[metaron]

As part of my 'alternative stategy' for rule modification, I've noticed that a large number of my older rules had starttime=endtime=0. (I suspect they were created in 0.24 mythweb days as 'record all' rules).

This isn't causing them not to function, but when trying to amend those rules by echoing back the current rule with changes using the DVR API, 0.27.4 mythbackend says:

Code:

2015-07-04 19:12:02.423208 E [21857/28498] HttpServer71 servicehost.cpp:143 (Invoke) - MethodInfo::Invoke - An Exception Occurred: Invalid duration.

And rejects the command.

This is slightly more complicated as my power search rules and the 'Default' recording template have starttime=endtime!=0

I've now amended all the rules in the database that had a zero duration and zero end time to have a 2 second duration - and everything is fine again, but it begs the question:
Should pvr.mythv simply fail under these circumstances, or attempt a 'fix' of some sort?

My guess is 'apply a fix' and this is probably why the current code re-creates each rule from scratch using a 'known good' template, rather than simply modifying an existing rule :-(
For now I'll press on and add a 'check rule for consistency' function to fix problems like this before sending anything to the services API. More complication here we come...

PS: I also checked in the 0.27 source code. You can't just skip the start and end time parameters in the services API call :-(

EDIT: The existing code can't cope with this either - UpdateRecordingRule wasn't passing on start or end time at all for most timer types, so just uses the value provided by the original GetRecordScheduleList API call; Which the services API will then reject...

[metaron]

Is the mythtv services API Dvr/GetConflictList being used for this ?

@MikeB2013 - The conflicts are being identified by the DVR/GetUpcomingList services API method. Nothing wrong with that, works fine.

The problem is how to squeeze the status of a subordinate timer (aka upcoming) into the status line for the parent timer (aka rule). It seems the PVR core people want to keep this purely as 'Active' or 'Inactive', rather than echoing an 'Active recording' or 'Conflict' status up from the subordinate items below it 'artificially'.

I can see a good case for providing PVR core with separate information (for flexibility of presentation), but I'm not sure if a way to report 'currentlyRecording' or 'hasActiveConflicts' for a repeating timer (aka rule) exists at present. I think @janbar was going to check.

Failing that we might have to ask @ksooo / @opdencamp nicely for an API change... or just go back to a version of my 'hack'...

[MikeB2013]

@metaron

For info

I have one record (out of 135) with starttime=endtime=0 in my 0.28pre database on my main system.
Unlikely that this was created using mythweb.

Mike

[metaron]

@janbar

I seem to have been having success re-working 'NewFromTimer' to be less reliant on EPG data and more tolerant of 'Any Channel', but I've come across an issue with 'Anytime'.

According to the 1.9.7 (or 2.0.0 as it now is) API, PVR_TIMER.startTime=endTime=0 is the state required to show 'Any Time' as active. Unfortunately as stated in my previous post above, starttime=endtime=0 is invalid for a myth recording rule.

The way to distinguish an 'anytime' myth rule in our case is the use of an ST_TitleSearch, as opposed to ST_ManualSearch or the FM_ThisDayAndTime / FM_ThisDay filters.

Looks like this conversion requires cleverness similar to the 'Lifetime/Number of recordings to keep' approach, so I guess you would suggest a similar object in MythScheduleHelper which does the conversion between the MythTimerEntry and MythRecordingRule layers.

The different rule Type/Filter/SearchTypes which apply within the Timer Types further complicate the situation, but I think it is still resolvable. Using a 'clerverness object' should also help ensure the code remains 'reversible'.

I'll see what I can come up with.

[metaron]

OK - had a bit more of a play. Setting startTime=endTime=0 works in that it now shows up as an anytime timer...
The problem is it shows the timer as running on 1/1/1970 which puts it completely out of order in the list when sorting by date.

There are other 'Any Time' issues as well: It appears there is no way of saying it shouldn't be shown / is implicit for certain timer types (i.e. 'Record All' or 'Find One' rules).

My guess is these 'features' were never envisaged by @ksooo. Probably an API change would be required to 'fix' this :-(.

I've raised this on Ksooo's PVR API thread ( http://forum.kodi.tv/showthread.php?tid=...pid2047336 )

[metaron]

@metaron I don't want provide a way which will break rules of users: If a user set priority -82, the addon cannot override value

I agree with you completely. Kodi must not break a rule created on another system.
Anything which can't be presented on Kodi's UI should be left 'unchanged' from the original rule.

This is the problem I have with the current code model:

• converts the PVR_TIMER into a MythTimerEntry using a set of rules (PVRtoTimerEntry)
  
• converts the MythTimerEntry into a MythRecordingRule using a set of rules (NewFromTimer)
  
• selectively copies aspects of that new MythRecordingRule over the top of the existing one (UpdateRecordingRule)
  
• and finally sends the modified rule to the backend (m_control->UpdateRecordSchedule)
  

I've decided you were right, it is unnecessarily complex to go directly from a PVR_TIMER to a MythRecordingRule. Thank you for talking me out of it .

I still want more control:

• to set & reset 'ThisChannel' without affecting other filters
  
• to confirm rule type / search type before changing it (Any time / specific time conversion for Weekly/Daily rules)
  
• to be able to manage 'don't change' list options for Lifetime and Priority (see PVR posting)
  

The approach I'm taking is to change 75/76::NewFromTimer to use the existing rule as a template.
I've kept UpdateRecordingRule as a 'safety net'.

So far I've made good progress prototyping with 0.27 (AnyChannel/Specific channel changing works!), but I want to make sure I have a working 0.26 solution (I'm converting a Pi2 to use as a 0.26 mythbackend).

Once I've got it fully working and tidied it up a bit (maybe later next week?), I'll push it to Github. I hope you will like some of my ideas and I can convert them into PRs.

Issues with 'Time'
While doing this I've found problems in the 2.0.0 API / PVR Core with Time/Date AnyTime, Scheduled Time display and list sorting. This isn't simple and still a work in progress (I'm sure you've seen my discussions with @ksooo...)

[MikeB2013]

@metaron

I am interested in why for the Pi2 you are using 0.26 mythbackend. I would have expected either 0.27/5 or 0.28pre.

Mike

[metaron]

@MikeB2013 - just so I can make sure the addon talks to it properly. The supported recording types changed for 0.27 and several of @janbar's comments for my previous attempts were 'breaks 0.26 support'.
Might require some cleverness though. The 0.26 version in portage won't compile on arm .