[kraka40]

@kraka40,

preferedCards is the list of recorder order by your preference settings for liveTV from your mythtv-setup. So there is no reason to reverse the order which is correct. If you think your issue is here then you should configure your backend to choose your prefered order for liveTV recorders.

However, like you I'm not 100% convinced pvr.mythtv always makes the right choice here

About liveTV conflicts, that is not the pvr addon chooses which recording to stop, but your backend. The addon receives a message from the backend telling "I want you stop live TV because i need a spare recorder to record something". And then depending of your choice in addon settings, the addon will prefer to "stop live TV because you ask to prefer scheduled recording" or "cancel the recording because you ask to prefer live TV anyway". Finnally this is your backend chooses which recording will be proposed to be cancelled.

Ok thanks .. so definitely backend .. I'll add this one to my mythtv coding bucket list.

[kraka40]

@metaron, @kraka40, and experienced users

Help would be welcome to complete the manual of the addon ( http://janbar.github.io/pvr.mythtv/manua...leshooting ).
The git branch containing the manual is "gh-pages". You could propose some changes to complete the manual and the section troubleshooting, which could be a great help for basic users. Thanks to all contributors.

ok will check it out.

[kraka40]

@kraka40,

preferedCards is the list of recorder order by your preference settings for liveTV from your mythtv-setup. So there is no reason to reverse the order which is correct. If you think your issue is here then you should configure your backend to choose your prefered order for liveTV recorders.

However, like you I'm not 100% convinced pvr.mythtv always makes the right choice here

About liveTV conflicts, that is not the pvr addon chooses which recording to stop, but your backend. The addon receives a message from the backend telling "I want you stop live TV because i need a spare recorder to record something". And then depending of your choice in addon settings, the addon will prefer to "stop live TV because you ask to prefer scheduled recording" or "cancel the recording because you ask to prefer live TV anyway". Finnally this is your backend chooses which recording will be proposed to be cancelled.

Ok thanks .. so definitely backend .. I'll add this one to my mythtv coding bucket list.

I found this explanation on Gossamer ..

For live, by default it chooses an available card with the same
hostname as the requesting frontend. If none, it chooses the lowest
numbered cardid that is available. If none it shows a warning message.
The default input for the chosen card is initially used. Pressing
"Y" switches to the next higher available card and wraps after the
highest number. If I have five card and I'm sitting at the host for
card 4 while card 2 is in use, it will pick card 4. "Y" changes to
5. "Y' again goes to 1 and again goes to 3.

If the avoid conflict with the scheduler is checked, it ignores
hostnames and chooses the highest numbered card available. "Y" still
counts up and wraps.

For recording, for a the same showing with the same priority score,
it choose the lowest numbered cardinputid available for the sourceid
of the channel. If there are two single input cards for one video
source, the input on card 1 will be chosen unless there is a higher
priority show already assigned then it will choose card 2. If the
Input preference is higher for cardinputid 2, the showing for card
2 is considered first (priority +1) before the showing on card 1
(priority +0). Therefore the episode wins the spot on the preferred
card 2 before the same showing on card 1 is ever considered.

I've reversed the live tv and scheduler priorities in mythtv. Still need to test, but this should help to mitigate conflict of priorities between scheduled and live tv recordings... at least if they start at the same time.

[AshG]

@metaron, @kraka40, and experienced users

Help would be welcome to complete the manual of the addon ( http://janbar.github.io/pvr.mythtv/manua...leshooting ).
The git branch containing the manual is "gh-pages". You could propose some changes to complete the manual and the section troubleshooting, which could be a great help for basic users. Thanks to all contributors.

janbar - I doubt I'll be able to help with any of the answers, However, if your manual on GitHub gets updated, I'm happy to duplicate the efforts on Kodi's official wiki if you wish - it the least I can do for all the hard work you've done....

[afremont]

I've reversed the live tv and scheduler priorities in mythtv. Still need to test, but this should help to mitigate conflict of priorities between scheduled and live tv recordings... at least if they start at the same time.

This is what I do. Recordings are made from one end of the tuner stack and live TV from the other. I find that I have a lot less problems and confusion this way.

[MikeB2013]

I've reversed the live tv and scheduler priorities in mythtv. Still need to test, but this should help to mitigate conflict of priorities between scheduled and live tv recordings... at least if they start at the same time.

This is what I do. Recordings are made from one end of the tuner stack and live TV from the other. I find that I have a lot less problems and confusion this way.

I do the same, plus in pvr.mythtv addon

"Allow Live TV to move scheduled shows" deselected
"Conflict handling" set to "Prefer recording and stop Live TV"

Mike

[metaron]

janbar
I notice that recent versions of your doityourself branch (since 538416d Aug 13th) don't adjust the 'start' time of a repeating timer to use 'next recording' / 'last recorded' anymore.

I liked the way rules which were going to do something appeared above 'now' and those that had done something in the past appeared at the time they last did it. This made it much easier to keep track of my long list of repeating timers.

The message which goes with commit 538416d says "This commit preserve rule timeslot against bad overriding when user update the timer". I guess this means there was a conflict with editing a timer, but I don't understand what or why.

If there's a problem I'd like to try and find a fix so the addon can use 'next recording' / 'last recorded' again.

Can you explain?

[mattlach]

Janbar, are you also behind the version of the mythtv plugin packaged in wsnipex repository?

The reason I ask is, I recently had to do a clean install on my broadwell based system following the new Linux - New Era: VAAPI with EGL interoperation thread.

This method of install is based on wsnipex's xbmc-fernetmenta-master ppa, which includes a "more stable" build of the 16.0 alpha.

Because of this I am running the 3.3.6 version of the plugin. Everything works pretty amazing, but I ahve seen a return of the freezing bug I thought you had fixed by increasing a timeout back in the Helix build, as mentioned in this message:

@mattlach
Different case here:
- For the first you have a read timeout after 3 sec. The backend didn't update file size. I will update to allow 10 sec before close demuxer.

Did the 10 second timeout somehow revert back to a 3 second timeout again by version 3.3.6?

The symptoms are exactly the same, and I haven't seen this kind of freezing since April when you changed the timeout.

Thanks again for doing a great job with this plugin!

[Segfault]

There is currently no "Gentoo way" to install this plugin for 15.2. Can some kind soul give some pointers how can I have it?

Edit: Found an Gentoo overlay with everything I needed. Plugin didn't build for 15.2, though, had to upgrade Kodi to live git build.

[janbar]

I notice that recent versions of your doityourself branch (since 538416d Aug 13th) don't adjust the 'start' time of a repeating timer to use 'next recording' / 'last recorded' anymore.

I liked the way rules which were going to do something appeared above 'now' and those that had done something in the past appeared at the time they last did it. This made it much easier to keep track of my long list of repeating timers.

The message which goes with commit 538416d says "This commit preserve rule timeslot against bad overriding when user update the timer". I guess this means there was a conflict with editing a timer, but I don't understand what or why.

If there's a problem I'd like to try and find a fix so the addon can use 'next recording' / 'last recorded' again.

Can you explain?

Before this commit , RULE with valid timeslot (not "any time") was overriden with next or last recorded. On user update the timeslot was updated with these wrong values, also next or last recorded include margin start and we cannot determine the right end time.
My conclusion is RULE with valid timeslot cannot be overriden because RULE have to be the mirror of backend RULE, and only RULE without timeslot (any time) can be overriden.

[janbar]

Janbar, are you also behind the version of the mythtv plugin packaged in wsnipex repository?

Yes the source of the addon is pulled from https://github.com/kodi-pvr/pvr.mythtv , and this repo is used to build the addon provided with kodi builds.
Also i didn't change the read timeout which is always configured with 10 sec. This timeout allows to avoid to break the playback when you are at the end of the recording being recorded, waiting for 10 sec to receive new bytes.

[metaron]

I notice that recent versions of your doityourself branch (since 538416d Aug 13th) don't adjust the 'start' time of a repeating timer to use 'next recording' / 'last recorded' anymore.

I liked the way rules which were going to do something appeared above 'now' and those that had done something in the past appeared at the time they last did it. This made it much easier to keep track of my long list of repeating timers.

The message which goes with commit 538416d says "This commit preserve rule timeslot against bad overriding when user update the timer". I guess this means there was a conflict with editing a timer, but I don't understand what or why.

If there's a problem I'd like to try and find a fix so the addon can use 'next recording' / 'last recorded' again.

Can you explain?

Before this commit , RULE with valid timeslot (not "any time") was overriden with next or last recorded. On user update the timeslot was updated with these wrong values, also next or last recorded include margin start and we cannot determine the right end time.
My conclusion is RULE with valid timeslot cannot be overriden because RULE have to be the mirror of backend RULE, and only RULE without timeslot (any time) can be overriden.

Thanks.

It isn't a problem for me as most of my rules are 'find all' or 'find once' types so the rule start/end times aren't important.
I can see rules with 'search type manual' break doing this though (and I know the addon currently does this for several repeating timer types as a fallback option...)

When (if) I get some time to work on Kodi again (and if I come up with something I think might be a better solution) I'll post back.

[khodhi]

Hi,

I apologize ahead of time if my question sounds like a repetition. I installed MythTV add-on (frontend/backend) on my Standalone OpenELEC with 14.2 Helix version running on an HP Chromebox.

However, I can't seem to operate it and when I'm watching a live TV, for example, USTVNow, I can't record. What am I missing here? I'm not using any tuner just EPG running on my Simple IPTV Client.

Do I need to disable IPTV SImple client to be able to run MythTV? I've been reading that the Backend needs to be started before it can record which I also confirm by a message on my Kodi each time I try to record a show. It says something like 'switch on backend to use timer'

[nickr]

You can't install mythbackend on OpenELEC.

[khodhi]

You can't install mythbackend on OpenELEC.

Thanks! I'll just get a Pi 2 to build an Ubuntu Server for the backend.

Thanks again.