[User 57826]

Thanks for testing. I think you're describing 2 different issues.
One is that you don't get a dialog or anything that you will miss a recording.
This can be only avoided by setting the "Allow Live TV to move scheduled shows" addon option.
LiveTV should continue and the backend will try to use another tuner.
We'll think about it an if possible add a notification/dialog in the future.

The second issue is the tuner getting stuck. This shouldn't happen of cause.
Are you able to describe a way to perfectly reproduce this for us?
Please describe all necessary steps and also upload a debug log with the "Include more debug information in the log file" option enabled.

Yes, I would like, but know its not available right to have a message pop up asking what to do, if no answer kill LiveTV in favor of scheduled shows. But that is outside of scope of this issue right now.

I do have "Allow Live TV to move scheduled shows" on, but I just found that if you are on the channel that is scheduled to record it will bump a show regardless.

Example:
Watching LiveTV on channel 11
shows are scheduled to start on 11 and 13
one show will fail.

Watching LiveTV on channel 2
shows are scheduled to start on 11 and 13
all shows will succeed (as far as I've seen so far)

So as long as you aren't on a channel that is scheduled to record it appears to be ok, but this is less than ideal.

I have my XBMC logs, but don't wish to post them publicly. I can send you the password.
http://xbmclogs.com/show.php?id=31642&hash=68944135

Mythbackend (taken from when I started watching TV until I had to reboot to unlock the stuck show.)
http://xbmclogs.com/show.php?id=31647

[gpherber]

I'm experiencing the same issue on my new mythtv backend build with XBMC v12.0 frodo. XBMC seems to be choosing the tuner with the lowest scheduler priority consistently (low is first, high last).

my 4 DVB-T tuners are set up as follows.
tuner 1: Schedule: 20, Live TV 5
tuner 2: Schedule: 15, Live TV 10
tuner 3: Schedule: 10, Live TV 15
tuner 4: Schedule: 5, Live TV 20

These settings are under input connections on the second page.

Tuner 1 should be chosen first for Live TV.
Tuner 4 should be chosen first for Scheduled Recordings.

If I use MythTV Frontend this is the case, but in XBMC it always uses Tuner 4 for Live TV unless the tuner is already in use which it then simply fails to view the channel at all.
If XBMC is using Tuner 4 when a recording starts which was scheduled to use that Tuner, the recording will silently fail and become stuck saying Currently Recording in mythweb.

If XBMC's Live TV Stream and the Recording which is scheduled to start are both using the same multiplex then the recording will go ahead as scheduled.

Easiest way to reproduce the problem is to set up a mythtv backend server with 2 tuners, set with opposite prioritys set for Scheduler and Live TV then set a future recording on one multiplex and watch live tv on another until the scheduled recording should have started. Using MythTV Frontend the recording and live tv shouldnt clash but in XBMC they will, and the recording will silently fail.

[richardk]

Can you build a new pvr plugin (1.6.7) for your Rasp Pi?

I don't use Live TV on my Pi, but do on my other two front ends. Building from source has helped mitigate the issue so far. But I am still testing it. One thing you can do is reverse the order of your tuners as I posted in my thread (http://forum.xbmc.org/showthread.php?tid=152012), that has also helped me. But updating the pvr plugin has really helped as well.

I've built OpenELEC using the new version of the plugin, and you can download it here:

ION x86_64: http://www.mediafire.com/?3lb9z64626jircr

Raspberry Pi: http://www.mediafire.com/?ch12hu0dxee5oac

Use at your own risk, of course.

[bobwdn]

I just downloaded and built a sdcard with your RPi 'new' version (OpenELEC-RPi.arm-devel-20130130235045-r13133) just posted.

Realizing that I am a newbie to OpenELEC, here is my immediate impression of what I see that changed with your 'new' 1.6.7 plugin version. All good things!

1. Previously the OpenELEC 2.99.2 would 'pull' both my Homerun Dual tuners giving me duplicate channels listings. I was confused on which channel to use, being a newbie, I thought this was strange and did not know any better. New version does NOT do that anymore. I am now getting one set of channels listed. Makes sense to me that this is the correct way OpenELEC/XBMC should list livetv channels.

2. Old OpenELEC 2.99.2 was recording all livetv, whether I told it to record or not. This put a big load on the backend. NOT ANYMORE, this 'new' version no longer records livetv until I press the "record" button.

3. New version responds more smoothly when selecting a livetv channel. My guess is that it (OpenELEC 'new') is no longer struggling to determine which of the duplicate channels it was to choose, like it did in the old OpenELEC 2.99.2. The "working" icon (lower right) rolls about the same amount of time no matter which channel you choose and channels "pop-up" and start quickly. Old version (OpenELEC 2.99.2) seemed sluggish.

Overall, this is a big jump in improvement and stability. There may be other issues or non-issues but, thank you for your efforts. This GREATLY appreciated. This is a solid step in the right direction.

>>>>>>>>>>>>>>>>>>>

edited 2013-02-06
I am now experiencing crashes and similar but different backend issues. My enthusiasm has diminished. This software needs a little more development time.

[fetzerch]

Thanks for testing. I think you're describing 2 different issues.
One is that you don't get a dialog or anything that you will miss a recording.
This can be only avoided by setting the "Allow Live TV to move scheduled shows" addon option.
LiveTV should continue and the backend will try to use another tuner.
We'll think about it an if possible add a notification/dialog in the future.

The second issue is the tuner getting stuck. This shouldn't happen of cause.
Are you able to describe a way to perfectly reproduce this for us?
Please describe all necessary steps and also upload a debug log with the "Include more debug information in the log file" option enabled.

Yes, I would like, but know its not available right to have a message pop up asking what to do, if no answer kill LiveTV in favor of scheduled shows. But that is outside of scope of this issue right now.

I do have "Allow Live TV to move scheduled shows" on, but I just found that if you are on the channel that is scheduled to record it will bump a show regardless.

Example:
Watching LiveTV on channel 11
shows are scheduled to start on 11 and 13
one show will fail.

Watching LiveTV on channel 2
shows are scheduled to start on 11 and 13
all shows will succeed (as far as I've seen so far)

So as long as you aren't on a channel that is scheduled to record it appears to be ok, but this is less than ideal.

I have my XBMC logs, but don't wish to post them publicly. I can send you the password.
http://xbmclogs.com/show.php?id=31642&hash=68944135

Mythbackend (taken from when I started watching TV until I had to reboot to unlock the stuck show.)
http://xbmclogs.com/show.php?id=31647

I tried to reproduce the issue that the recording gets stuck, but unfortunately I'm not able to.
I'm running 0.26 and I found this http://code.mythtv.org/trac/ticket/10489 and http://code.mythtv.org/trac/ticket/10726.
Both make me think that it's an issue in 0.25 and it might be a good idea upgrading to 0.26.
[edit] You're right, after a few tries, I'm now able to reproduce it now. Will have a look[/edit]

@gpherber: BTW: Unfortunately the addon's versioning is a bit messy and both the released and the development versions have the same version number.
So looking for 1.6.7 doesn't tell too much. Anyway I have double checked the tuner priorities and the development version (that can be build as explained here: http://wiki.xbmc.org/index.php?title=PVR...FromSource )
is always using the correct tuner for me (0.26 backend).

And again, you will currently not see a dialog, warning you about a LiveTV - recording conflict. It's simply not implemented yet.
So if you're watching LiveTV and you don't have "Allow Live TV to move scheduled shows" set and you don't have another tuner that could be used for the recording, then you will miss the recording without any notification.
I hope this clarifies the situation a bit

[fetzerch]

Could you test https://github.com/fetzerch/xbmc-pvr-addons/pull/87 and let me know if this fixes at least the stuck recording?

[User 57826]

Could you test https://github.com/fetzerch/xbmc-pvr-addons/pull/87 and let me know if this fixes at least the stuck recording?

I was just about to upgrade to 0.26, did you want me to test this with 0.25 first?

[Jbruntt]

Doesn't look like it will be fixed.

https://github.com/cmyth/cmyth/issues/15

I have updated my post with a "kinda" work around. Basically XBMC uses your first tuner for watching Live TV. I just moved my tuners to record from the Last tuner towards the first tuner.

http://forum.xbmc.org/showthread.php?tid=152012

Are you using Myth 0.25? I don't even have the same Live TV priority option on my backend.

I am using Myth 0.25 as my backend. I have (had) the same problem. And I fixed it using the method outlined by djroketboy.

Stop the server
Run mythtv-setup
5. Input connections
Select a connection
Next

On this window I have a headline saying Interaction between inputs
Then I have a field called Input Priority value 0
Then there is a field called Schedule order value 4
Then a field called Live TV order

What you can fiddle with here is the Schedule order field. It controls how the backend chooses which of your tuners to use.

What I did was to observe (using the mythweb status page) which of my tuners the Live TV PVR addon chooses when it activates. That tuner got a very high number in the Schedule order on my backend Myth server. Effectively making sure that the backend never tries to record using that tuner.

[User 57826]

I am using Myth 0.25 as my backend. I have (had) the same problem. And I fixed it using the method outlined by djroketboy.

Stop the server
Run mythtv-setup
5. Input connections
Select a connection
Next

On this window I have a headline saying Interaction between inputs
Then I have a field called Input Priority value 0
Then there is a field called Schedule order value 4
Then a field called Live TV order

What you can fiddle with here is the Schedule order field. It controls how the backend chooses which of your tuners to use.

What I did was to observe (using the mythweb status page) which of my tuners the Live TV PVR addon chooses when it activates. That tuner got a very high number in the Schedule order on my backend Myth server. Effectively making sure that the backend never tries to record using that tuner.

If you are willing to compile and test from git, cfetzer has been graciously working on a fix.
https://github.com/fetzerch/xbmc-pvr-addons/issues/85
https://github.com/fetzerch/xbmc-pvr-addons/pull/87

I've been using it for the last few days and its been great.

[Jbruntt]

Compiling stuff is outside my skillset I am afraid.

[efolse]

Also, I am getting it deleting older recordings freeing up an additional 60 gig of recordings against my wishes. I am having the same problems also, live TV pulls another tuner off an recording and it starting to record scheduled items at the wrong time (about 3 hours early). Frodo and mythtv backend .26 (mythbuntu). I am running xbmc on a windows 7 as the front end. Been using mythbuntu for about 6 years. I run xbmc as a portable (with the p flag in the shortcut.)

It seems to be honoring the do not delete flag on the recordings. BTW it really kills the mythlog server. My backend log on mythweb is this...

0 1842283 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1397 HandleAnnounce 2013-02-12 19:46:26 6 adding: R8X1WNZ as a client (events: 1)
1 1842282 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1395 HandleAnnounce 2013-02-12 19:46:26 6 MainServer::ANN Playback
2 1842281 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 5841 connectionClosed 2013-02-12 19:46:26 4 MainServer: Unknown socket closing MythSocket(0x9d53d08)
3 1842280 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1294 HandleVersion 2013-02-12 19:46:26 2 MainServer::HandleVersion - Client speaks protocol version 8 but we speak 75!
4 1842279 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1397 HandleAnnounce 2013-02-12 19:46:26 6 adding: R8X1WNZ as a client (events: 0)
5 1842278 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1395 HandleAnnounce 2013-02-12 19:46:26 6 MainServer::ANN Playback
6 1842277 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 5841 connectionClosed 2013-02-12 19:46:25 4 MainServer: Unknown socket closing MythSocket(0xa004ad0)
7 1842276 efolse-desktop mythbackend 15638 501 ProcessRequest mainserver.cpp 1294 HandleVersion 2013-02-12 19:46:25 2 MainServer::HandleVersion - Client speaks protocol version 8 but we speak 75!
8 1842275 efolse-desktop mythbackend 15638 15786 HouseKeeping housekeeper.cpp 221 RunHouseKeeping 2013-02-12 19:45:34 6 Running housekeeping thread
9 1842274 efolse-desktop mythbackend 15638 15786 HouseKeeping housekeeper.cpp 221 RunHouseKeeping 2013-02-12 19:40:30 6 Running housekeeping thread
10 1842273 efolse-desktop mythbackend 15638 15787 Expire autoexpire.cpp 264 CalcParams 2013-02-12 19:38:21 5 AutoExpire: CalcParams(): Max required Free Space: 202.0 GB w/freq: 14 min
11 1842272 efolse-desktop mythbackend 15638 15786 HouseKeeping housekeeper.cpp 221 RunHouseKeeping 2013-02-12 19:35:29 6 Running housekeeping thread
12 1842271 efolse-desktop mythbackend 15638 15786 HouseKeeping housekeeper.cpp 221 RunHouseKeeping 2013-02-12 19:30:29 6 Running housekeeping thread
13 1842270 efolse-desktop mythbackend 15638 15785 Scheduler scheduler.cpp 2243 HandleReschedule 2013-02-12 19:30:05 6 Scheduled 654 items in 3.3 = 0.00 match + 0.00 check + 3.30 place
14 1842269 efolse-desktop mythbackend 15638 15785 Scheduler scheduler.cpp 2130 HandleReschedule 2013-02-12 19:30:02 6 Reschedule requested for PLACE PrepareToRecord
15 1842268 efolse-desktop mythbackend 15638 15783 TVRecEvent tv_rec.cpp 4056 TuningNewRecorder 2013-02-12 19:30:02 6 TVRec(1): rec->GetPathname(): '/media/hd3/mythtv/recordings/1081_20130213013000.mpg'
16 1842267 efolse-desktop mythbackend 15638 15638 CoreContext scheduler.cpp 655 UpdateRecStatus 2013-02-12 19:30:01 6 Updating status for "New Girl":Models on cardid 1 (Tuning => Recording)
17 1842266 efolse-desktop mythbackend 15638 15785 Scheduler scheduler.cpp 2651 HandleRecordingStatusChange 2013-02-12 19:30:01 6 Tuning recording: "New Girl":Models: channel 1081 on cardid 1, sourceid 1
18 1842265 efolse-desktop mythbackend 15638 15785 Scheduler autoexpire.cpp 264 CalcParams 2013-02-12 19:30:01 5 AutoExpire: CalcParams(): Max required Free Space: 202.0 GB w/freq: 14 min
19 1842264 efolse-desktop mythbackend 15638 15783 TVRecEvent tv_rec.cpp 3562 TuningCheckForHWChange 2013-02-12 19:30:00 6 TVRec(1): HW Tuner: 1->1
20 1842263 efolse-desktop mythbackend 15638 15783 TVRecEvent tv_rec.cpp 1043 HandleStateChange 2013-02-12 19:30:00 6 TVRec(1): Changing from None to RecordingOnly
21 1842262 efolse-desktop mythbackend 15638 15784 TVRecEvent tv_rec.cpp 1557 HandlePendingRecordings 2013-02-12 19:29:46 6 TVRec(2): ASK_RECORDING 2 13 0 0
22 1842261 efolse-desktop mythbackend 15638 15783 TVRecEvent tv_rec.cpp 1557 HandlePendingRecordings 2013-02-12 19:29:46 6 TVRec(1): ASK_RECORDING 1 13 0 0
23 1842260 efolse-desktop mythbackend 15638 15786 HouseKeeping housekeeper.cpp 221 RunHouseKeeping 2013-02-12 19:25:27 6 Running housekeeping thread
24 1842259 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:49 6 adding: R8X1WNZ as a remote file transfer
25 1842258 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:49 6 MainServer::HandleAnnounce FileTransfer
26 1842257 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:49 6 adding: R8X1WNZ as a remote file transfer
27 1842256 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:49 6 MainServer::HandleAnnounce FileTransfer
28 1842255 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:34 6 adding: R8X1WNZ as a remote file transfer
29 1842254 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:34 6 MainServer::HandleAnnounce FileTransfer
30 1842253 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:18 6 adding: R8X1WNZ as a remote file transfer
31 1842252 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:18 6 MainServer::HandleAnnounce FileTransfer
32 1842251 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:17 6 adding: R8X1WNZ as a remote file transfer
33 1842250 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:17 6 MainServer::HandleAnnounce FileTransfer
34 1842249 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:23:03 6 adding: R8X1WNZ as a remote file transfer
35 1842248 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:23:03 6 MainServer::HandleAnnounce FileTransfer
36 1842247 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:49 6 adding: R8X1WNZ as a remote file transfer
37 1842246 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:49 6 MainServer::HandleAnnounce FileTransfer
38 1842245 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:49 6 adding: R8X1WNZ as a remote file transfer
39 1842244 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:49 6 MainServer::HandleAnnounce FileTransfer
40 1842243 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:34 6 adding: R8X1WNZ as a remote file transfer
41 1842242 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:34 6 MainServer::HandleAnnounce FileTransfer
42 1842241 efolse-desktop mythbackend 15638 420 ProcessRequest programinfo.cpp 2284 GetPlaybackURL 2013-02-12 19:22:34 3 ProgramInfo(1491_20130211060000.mpg): GetPlaybackURL: '1491_20130211060000.mpg' should be local, but it can not be found.
43 1842240 efolse-desktop mythbackend 15638 15787 Expire autoexpire.cpp 641 SendDeleteMessages 2013-02-12 19:22:22 5 Expiring 4407 MB for 1491 at 2013-02-11T06:00:00Z => NUMB3RS:"Robin Hood"
44 1842239 efolse-desktop mythbackend 15638 15787 Expire autoexpire.cpp 264 CalcParams 2013-02-12 19:22:22 5 AutoExpire: CalcParams(): Max required Free Space: 200.0 GB w/freq: 15 min
45 1842238 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:20 6 adding: R8X1WNZ as a remote file transfer
46 1842237 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:20 6 MainServer::HandleAnnounce FileTransfer
47 1842236 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:03 6 adding: R8X1WNZ as a remote file transfer
48 1842235 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:03 6 MainServer::HandleAnnounce FileTransfer
49 1842234 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:22:03 6 adding: R8X1WNZ as a remote file transfer
50 1842233 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:22:03 6 MainServer::HandleAnnounce FileTransfer
51 1842232 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:49 6 adding: R8X1WNZ as a remote file transfer
52 1842231 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:49 6 MainServer::HandleAnnounce FileTransfer
53 1842230 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:34 6 adding: R8X1WNZ as a remote file transfer
54 1842229 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:34 6 MainServer::HandleAnnounce FileTransfer
55 1842228 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:34 6 adding: R8X1WNZ as a remote file transfer
56 1842227 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:34 6 MainServer::HandleAnnounce FileTransfer
57 1842226 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:33 6 adding: R8X1WNZ as a remote file transfer
58 1842225 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:33 6 MainServer::HandleAnnounce FileTransfer
59 1842224 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:33 6 adding: R8X1WNZ as a remote file transfer
60 1842223 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:33 6 MainServer::HandleAnnounce FileTransfer
61 1842222 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:32 6 adding: R8X1WNZ as a remote file transfer
62 1842221 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:32 6 MainServer::HandleAnnounce FileTransfer
63 1842220 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:32 6 adding: R8X1WNZ as a remote file transfer
64 1842219 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:32 6 MainServer::HandleAnnounce FileTransfer
65 1842218 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:32 6 adding: R8X1WNZ as a remote file transfer
66 1842217 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:32 6 MainServer::HandleAnnounce FileTransfer
67 1842216 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:31 6 adding: R8X1WNZ as a remote file transfer
68 1842215 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:31 6 MainServer::HandleAnnounce FileTransfer
69 1842214 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:31 6 adding: R8X1WNZ as a remote file transfer
70 1842213 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:31 6 MainServer::HandleAnnounce FileTransfer
71 1842212 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:30 6 adding: R8X1WNZ as a remote file transfer
72 1842211 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:30 6 MainServer::HandleAnnounce FileTransfer
73 1842210 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:30 6 adding: R8X1WNZ as a remote file transfer
74 1842209 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:30 6 MainServer::HandleAnnounce FileTransfer
75 1842208 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:29 6 adding: R8X1WNZ as a remote file transfer
76 1842207 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:29 6 MainServer::HandleAnnounce FileTransfer
77 1842206 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:29 6 adding: R8X1WNZ as a remote file transfer
78 1842205 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:29 6 MainServer::HandleAnnounce FileTransfer
79 1842204 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:28 6 adding: R8X1WNZ as a remote file transfer
80 1842203 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:28 6 MainServer::HandleAnnounce FileTransfer
81 1842202 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:28 6 adding: R8X1WNZ as a remote file transfer
82 1842201 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:28 6 MainServer::HandleAnnounce FileTransfer
83 1842200 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:21:13 6 adding: R8X1WNZ as a remote file transfer
84 1842199 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:21:13 6 MainServer::HandleAnnounce FileTransfer
85 1842198 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:57 6 adding: R8X1WNZ as a remote file transfer
86 1842197 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:57 6 MainServer::HandleAnnounce FileTransfer
87 1842196 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:57 6 adding: R8X1WNZ as a remote file transfer
88 1842195 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:57 6 MainServer::HandleAnnounce FileTransfer
89 1842194 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:56 6 adding: R8X1WNZ as a remote file transfer
90 1842193 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:56 6 MainServer::HandleAnnounce FileTransfer
91 1842192 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:56 6 adding: R8X1WNZ as a remote file transfer
92 1842191 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:56 6 MainServer::HandleAnnounce FileTransfer
93 1842190 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:55 6 adding: R8X1WNZ as a remote file transfer
94 1842189 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:55 6 MainServer::HandleAnnounce FileTransfer
95 1842188 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:55 6 adding: R8X1WNZ as a remote file transfer
96 1842187 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:55 6 MainServer::HandleAnnounce FileTransfer
97 1842186 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:54 6 adding: R8X1WNZ as a remote file transfer
98 1842185 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1510 HandleAnnounce 2013-02-12 19:20:54 6 MainServer::HandleAnnounce FileTransfer
99 1842184 efolse-desktop mythbackend 15638 420 ProcessRequest mainserver.cpp 1512 HandleAnnounce 2013-02-12 19:20:53 6 adding: R8X1WNZ as a remote file transfer

I will keep looking for any answers. I am running the script from the system menu in the disabled addons pvr...

[sfrooster]

If you are willing to compile and test from git, cfetzer has been graciously working on a fix.
https://github.com/fetzerch/xbmc-pvr-addons/issues/85
https://github.com/fetzerch/xbmc-pvr-addons/pull/87

I've been using it for the last few days and its been great.

I built from git (using instructions you pointed me to - thanks!) on Sunday.

On Monday, both of my boxes were watching live tv (I've got an HDHR with three tuners). One box was watching live tv at 9:00 on a channel that was set to record a show at 9:00. I noticed that xbmc reported it was recording it during the correct timeslot, and continued reporting that the recording was still ongoing after it should've ended, but didn't pay any attention until last night when it was still reporting that it was recording the show. Of course the recording wasn't actually present on the backend, and I couldn't delete it via mythweb.

I finally "got rid" of it by cancelling the recording and rebooting the backend (and then adding the schedule back in), but I think this was the issue being described here (I'm on myth 0.26, BTW) and I was running on the latest version of the plugin as near as I know (I'm assuming that's what all the compiling I did on Sunday got for me).

[User 57826]

Yes! That is the bug we've been talking about.

In the myth-pvr add-on config there is a new menu selection at the bottom that will ask what you want to do when the backend needs the tuners. I tell mine to kill LiveTV. You can play with that and see if it helps.

[jshoor]

I am not sure if this is the same issue but it seems related. I am running cmyth 1.6.7 on Frodo/win7x64 against a MythTV 0.26-fixes backend and I am constantly seeing the message that I am "currently recording" some show that is days old. Although cmyth is showing the message, the back end is definitely not recording for days on end and I don't think my recording schedule is being effected. If I restart the mtythv backend the message will go away, but it will eventually come back and stay untill I restart the backend again. Restarting xbmc does not fix it. Unfortunately I dont know what is triggering the message. I only have one dvb tuner, so it cant be a tuner priority thing.

Im happy to provide a debug log if it would be helpful.

[ullix]

jshoor,

"Yes! That is the bug we've been talking about." (to quote djroketboy). The problem, or at least part of it, is in your version of cmyth. In version 1.7.x a fix is implemented, which allows you to configure (in the settings for the cmyth add-on) the action of cmyth, when an overlap of recordings happens. In my experience this fix does not completely solve the problem, but then the remaining issues could result from something else.

I use a ppa described here http://forum.xbmc.org/showthread.php?tid...pid1364383 which provides the new cmyth version.