• 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 108
pvr.mythtv add-on
@ MikeB2013

Faint hearted here - I'll try the nightly builds and I'm glad it has support for .28 backend!

@janbar

Good news that Kodi 15.2 will include the latest v2.7.2 instead of v2.5.0 and some added Android fixes.


Thanks guys for all of your hard work on Kodi & for responding to me and giving us the good news!

Kodi Rocks!
Reply
@janbar @MikeB2013

thanks for all of the info!

Just tried the Jarvis nightly and the pvr.mythtv v2.6.2 worked great!

thanks!
Reply
@janbar

Unable to delete timers, debug log here http://paste.ubuntu.com/12451382/

Edit
Same problem with OpenELEC (Milhouse) - Version: devel-20150917222016-#0917-g2eec924 [Build #0917] build on Raspberry Pi2 which uses pvr.mythtv from https://github.com/kodi-pvr/pvr.mythtv

Mike
Reply
@MikeB2013 , thank Mike. I haven t yet checked the addon with the api 4.0 changes. It seems to have an issue with "force" flag of delete member. - will fix this evening. Thanks again.
Reply
(2015-09-18, 19:36)MikeB2013 Wrote: Unable to delete timers, debug log here http://paste.ubuntu.com/12451382/

Fixed with version 3.3.5 (merged in kodi-pvr).
Reply
Sorry if this has been answered but have latest stock build with Kodi 15.1.

I have conflict resolution setup to prefer live recordings. Today I had three recordings on three tuners configured, 2 with a priority 0 and 1 with priority 9. My wife went to watch tv ( I wasn't there ), and so happen the show she wanted to watch was one of the 0 priority shows. Conflict resolution resulted in cancelling the priority 9 show, freeing up a tuner for her live broadcast and continuing with the previous two 0 priority recordings ( one of which she was watching on the live tuner ).

My expectation would have been for the 0 priority recording she was watching to be cancelled and the last recording to be cancelled would have been the highest priority recording.

Is this a config issue on my part or a weakness in mythtv and/or pvr addon.


Thanks!
Reply
She should have watched the recording.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
(2015-09-29, 07:21)nickr Wrote: She should have watched the recording.

Hmm, I guess you are right. It's insight like this you just can't find anywhere else.
Reply
To enlarge, why record it twice? 1x as scheduled recording, 1x live tv.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
To avoid this situation you could update addon setting as "Prefer Live TV when recording has later slot". So if no later slot then the addon will stop live TV to allow scheduled recording.
If you setup "Prefer Live TV and cancel conflicting recording" and wife or child watch often TV then you have lot of chance to loose your favorite series.
Reply
Assuming you're using a DVB based tuner (DVB-T, S or C) you could simply increase the number of 'virtual' tuners associated to your 'real' tuners on the backend (I believe mythtv defaults to 2, but you could increase this to 4 or even 6).

That way mythbackend should use a spare virtual tuner to record the 'live' version of the 'scheduled' recording, keeping the 'real' tuner free to record your priority 9. Probably a good idea if you have several kodi frontends which might be watching the same show at the same time as they will each grab a 'tuner' to create their own live recording.

However, like you I'm not 100% convinced pvr.mythtv always makes the right choice here. I've a DVB-T and a DVB-S2 setup (2 real tuners with 2 virtual tuners each). I think I've had pvr.mythtv tell me I've no spare tuners when the DVB-S2 shouldn't have been recording anything, but I never investigated further. Not all channels exist on both transport media however, so it might have been correct operation. Also it was a while ago when the client was a bit more buggy.

Maybe pvr.mythtv doesn't prefer a 'virtual' tuner on an active source when it starts a 'live' recording?

If it doesn't this would probably be a feature which enhances future family harmony ;-o
Reply
(2015-10-02, 00:43)metaron Wrote: Assuming you're using a DVB based tuner (DVB-T, S or C) you could simply increase the number of 'virtual' tuners associated to your 'real' tuners on the backend (I believe mythtv defaults to 2, but you could increase this to 4 or even 6).

That way mythbackend should use a spare virtual tuner to record the 'live' version of the 'scheduled' recording, keeping the 'real' tuner free to record your priority 9. Probably a good idea if you have several kodi frontends which might be watching the same show at the same time as they will each grab a 'tuner' to create their own live recording.

However, like you I'm not 100% convinced pvr.mythtv always makes the right choice here. I've a DVB-T and a DVB-S2 setup (2 real tuners with 2 virtual tuners each). I think I've had pvr.mythtv tell me I've no spare tuners when the DVB-S2 shouldn't have been recording anything, but I never investigated further. Not all channels exist on both transport media however, so it might have been correct operation. Also it was a while ago when the client was a bit more buggy.

Maybe pvr.mythtv doesn't prefer a 'virtual' tuner on an active source when it starts a 'live' recording?

If it doesn't this would probably be a feature which enhances future family harmony ;-o

I have 3 tuners available and am not able to add additional virtual tuners as it is a HDHomerun Prime. I'm pretty sure this is an logic issue in the mythtv or pr.mythtv code. Before a tuner is commandeered for live tv, all available tuners should be scanned .. if free, first tuner should be grabbed, and if none available, there should be other criteria available to prioritize the remaining tuners besides (grab the 1st one). My guess is that the first one is always the highest priority, so maybe a simple solution is choose the last one.
Reply
Janbar,

My coding skills are rusty, and I'm not sure how to start a proper branch, compile and test locally .. but happy to do so if someone could point me to a quick tutorial for macos (have github desktop and Xcode installed).

That said... would a simple change to mythlivetvplayback.cpp SpawnLiveTV fix this?

instead of sequencing through the cards forward (from preferredCards.begin() to preferredCards.end()) to reverse this from .end()-- to begin()?
Reply
@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.

(2015-10-02, 00:43)metaron Wrote: 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.
Reply
@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.
Reply
  • 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 108

Logout Mark Read Team Forum Stats Members Help
pvr.mythtv add-on1