[MikeB2013]

@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 .

OK but mythtv 0.26 is no longer supported.

Just for a bit of fun I have ubuntu mate on Rpi2 running mythbackend 0.28pre with a single DVB-T USB tuner.

Mike

[metaron]

My original aim with the Pi2 was to replace my backend 'spaceheater' with a USB DVB-T2 tuner and NAS storage for the recordings. Might as well use it to check out 0.26 support while I consider migration... but probably not until 0.28 is released.
Personally I left 0.26 fairly quickly when 0.27 was released, but if @janbar wants pvr.mythtv to support it, that's fine by me.

[janbar]

@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

Hi Mike. Yes there was a problem with API 2.0.0. A guy has pulled a commit without bump API version. On some platform it could crash at startup. I had to do a revert of the branch doityourself to go back before commits about series-recordings. Now it should work. So i will merge series-recordings later when the feature will be more stable. This feature still in branch series_recordings.

[MikeB2013]

@janbar

No problem, I will use your series_recordings branch.

Mike

[metaron]

@janbar
I've got my 0.26 backend up and running and have started to experiment.

Trying to edit an existing timer I get "An unexpected error occurred. Try again later or check the log for more information."
The log says:

Code:

13:18:51 T:3012097856   DEBUG: AddOnLog: MythTV PVR Client: UpdateRecordingRule: Dealing with the problem using method 6
13:18:51 T:3012097856   ERROR: PVR - UpdateTimer - addon 'MythTV (Pi2):http://pi2.home:6544' returned an error: the command failed
13:18:51 T:3012097856   ERROR: PVR - UpdateTimer - cannot update timer on client '743': the command failed

I quickly noticed that it has DVR service API Version 1.5. This doesn't include UpdateRecordSchedule, which is a kind of important feature if you ask me...

I'm guessing there are three options:

1. Accept that you can't edit a recording rule using 0.26, put a big fat warning in the WIKI and try to make the error message and log entries as friendly and informative as possible.
   
2. Implement a new method which creates a brand new rule based on the old one, then delete the old one (I don't like this option personally as it will loose all history associated with the old ruleID)
   
3. Drop support for 0.26 in Jxxx altogether (0.26 isn't supported upstream anymore, 0.27 is stable, 0.28 will be released soon...). Requiring users to upgrade to 0.27 would certainly allow the code base to be simplified.
   

Any thoughts?

[janbar]

@janbar
I've got my 0.26 backend up and running and have started to experiment.

Trying to edit an existing timer I get "An unexpected error occurred. Try again later or check the log for more information."
The log says:

Code:

13:18:51 T:3012097856   DEBUG: AddOnLog: MythTV PVR Client: UpdateRecordingRule: Dealing with the problem using method 6
13:18:51 T:3012097856   ERROR: PVR - UpdateTimer - addon 'MythTV (Pi2):http://pi2.home:6544' returned an error: the command failed
13:18:51 T:3012097856   ERROR: PVR - UpdateTimer - cannot update timer on client '743': the command failed

I quickly noticed that it has DVR service API Version 1.5. This doesn't include UpdateRecordSchedule, which is a kind of important feature if you ask me...

I'm guessing there are three options:

1. Accept that you can't edit a recording rule using 0.26, put a big fat warning in the WIKI and try to make the error message and log entries as friendly and informative as possible.
   
2. Implement a new method which creates a brand new rule based on the old one, then delete the old one (I don't like this option personally as it will loose all history associated with the old ruleID)
   
3. Drop support for 0.26 in Jxxx altogether (0.26 isn't supported upstream anymore, 0.27 is stable, 0.28 will be released soon...). Requiring users to upgrade to 0.27 would certainly allow the code base to be simplified.
   

Any thoughts?

Yes you are right, libcppmyth returns false before api version 1.7. Also i haven't replaced the operation by delete/add because until Helix i forbid update of rule: Only disable/enable was allowed and these operations are available with api of 0.26.
So the best approach would be to remove support of 0.26 for J****.

EDIT: When user will connect addon with 0.26, I could show a "Warning" dialog with a special message like "Backend version %s is not fully supported by this addon. Some operations could failed. Please upgrade your backend up to 0.27 or more". Then he has to press "Agree".

[MikeB2013]

@janbar @metaron

I like the idea of putting up a message for unsupported mythtv backend versions. Much better for the User than having to look in logs and minimises support requirements.

In the case of mythtv backend 0.26 (which is out of support) I think it would be best just to give a message and then terminate the pvr.mythtv addon.

May I also suggest a revised message
"Backend version %s is not supported by this addon. Please upgrade your mythtv backend to 0.27 fixes or later"

Mike

[janbar]

@MikeB2013, thanks i get your revised message (best english than me ). Else i have i will have a look if i can terminate addon without kodi retry to load it again.

@metaron, the commit https://github.com/janbar/pvr.mythtv/com...f714fc4e70 could be good for you ?

[janbar]

What else, a guy has again break the feature in kodi: Upcoming cannot to be deleted now due to a bug. The related PR is https://github.com/xbmc/xbmc/pull/7488 . This guy make me crazy but i have to keep cool .

[ksooo]

The bad guy janbar is talking about is me. And I did actually not break things again. The commit janbar is complaining about actually restored the state in master as it was for years(!) until I recently made a change that actuallyvbroke stuff and therefore had to be reverted. This change was on master for not more than 1 week or 2. I discussed this with janbar on github back and forth, but unfortunately I was not able to explain my points well enough.

[janbar]

@ksooo don't blame me , It is a freindly place here. Soon we will resolve our problem and every body will be happy

[ksooo]

@janbar then you should not blame me either. Talking here about "a guy that again broke things and makes you crazy" along with the url to the respective github discussion is as good as blaming me directly here. ;-)

To fix the bug you mentioned above, I suggest you to file another PR, containing only a fix for the buggy compare statement (replace index < 0 by state == new) and I will be happy to merge this in almost no time.

[janbar]

To fix the bug you mentioned above, I suggest you to file another PR, containing only a fix for the buggy compare statement (replace index < 0 by state == new) and I will be happy to merge this in almost no time.

Okay I will do a new one. I close current because every boby is noised and i let you make one to resolve what you want about signed/unsigned thing in kodi.

[ksooo]

@janbar merged your PR last night, as promised.

[metaron]

@metaron, the commit https://github.com/janbar/pvr.mythtv/com...f714fc4e70 could be good for you ?

Sorry - had family to visit so couldn't escape to the man cave for a few days..

Looks good to me.