Several Minor Issues

[DanGilbertTX]

I am running NextPVR 2.6.2 for several months now and have found several issues. I was hoping someone could either verify they are known issues or provide a possible fix for the issues. I mostly use the NEWA web interface for working with NextPVR.

• The Guide is limited to 7 days of data. The guide XML though has 14 days worth of data. It just seems NextPVR won't show/retain more than 7 days worth of guide data.
  
• Recurring Scheduled Recordings that I cancel via NEWA will re-appear and be recorded every time the guide updates. Possibly sooner than that, but definitely cannot cancel a single recording more than 1 day in advance.
  
• I created a Recurring Recording to start daily at 5am. I set pre-padding to 1 minute and post-padding to 3 minutes. However, no matter what I do NextPVR records the FULL previous broadcast at 4am and the following broadcast at either 6am or 6:30am. I am assuming this is an error caused by the padding, but I don't want the full previous and post broadcast.
  

Anyway, I am looking for some answers on these issues. If you need any more information, logs, or screenshots I would be happy to provide them. And thank you in advance for any help you provide.

[mvallevand]

[*]The Guide is limited to 7 days of data. The guide XML though has 14 days worth of data. It just seems NextPVR won't show/retain more than 7 days worth of guide data.

You can increase this in config.xml

[*]Recurring Scheduled Recordings that I cancel via NEWA will re-appear and be recorded every time the guide updates. Possibly sooner than that, but definitely cannot cancel a single recording more than 1 day in advance.

Correct, if I good unique id can't be determined this will happen.

[*]I created a Recurring Recording to start daily at 5am. I set pre-padding to 1 minute and post-padding to 3 minutes. However, no matter what I do NextPVR records the FULL previous broadcast at 4am and the following broadcast at either 6am or 6:30am. I am assuming this is an error caused by the padding, but I don't want the full previous and post broadcast.

I could see that happening. There are a couple of things you could do, create a manual daily recording and name it the same as the show or reduced the window that NextPVR searches ahead for the show (default is 90 minutes) to something less than 60.

Martin

[DanGilbertTX]

You can increase this in config.xml

Thanks. I am assuming that the setting we are talking about is <SchedulesDirectDays>8</SchedulesDirectDays>. I am guessing that increasing that to 14 is what would fix the guide data length. Or is there another setting I should be looking for.

Correct, if I good unique id can't be determined this will happen.

I don't understand why this would happen. If I remove a scheduled recording (just a single instance and not the recurring recording) shouldn't that persist past guide updates? If I manually remove a scheduled recording I would expect that recording to NOT record.

I could see that happening. There are a couple of things you could do, create a manual daily recording and name it the same as the show or reduced the window that NextPVR searches ahead for the show (default is 90 minutes) to something less than 60.

I believe I created the recording by finding the show in the guide and specifying that I wanted to record daily at 5am and no other time slot. Even so, why would the search ahead record the show PRIOR to the timeslot I want?

[sub]

When you do a timeslot recording it'll schedule any show with the same name and a start time +/-90 minutes of the original start time. This is to accommodate slight variations to the schedule, like a show running an hour late one week etc. This generally works well, but has caused problems for some US based users, where they show a lot of repeats, often right next to the new episode.

If this +/-90 minute logic doesn't suit you, you can reduce it to zero minutes in the config.xml

[martint123]

I don't understand why this would happen. If I remove a scheduled recording (just a single instance and not the recurring recording) shouldn't that persist past guide updates? If I manually remove a scheduled recording I would expect that recording to NOT record.

I understand that when the EPG is loaded individual existing scheduled recordings are deleted and the EPG re-scanned to schedule season recordings. This is to catch and time changes in the EPG. The only time they are not re-scheduled is if the unique ID is the same (not sure of details as this is not available to most of the rest of the world).

[DanGilbertTX]

When you do a timeslot recording it'll schedule any show with the same name and a start time +/-90 minutes of the original start time. This is to accommodate slight variations to the schedule, like a show running an hour late one week etc. This generally works well, but has caused problems for some US based users, where they show a lot of repeats, often right next to the new episode.

If this +/-90 minute logic doesn't suit you, you can reduce it to zero minutes in the config.xml

Thank you for the explanation. That makes sense now and I can see how that is useful logic. In this case the show is SportsCenter and there are a LOT of repeats.

I understand that when the EPG is loaded individual existing scheduled recordings are deleted and the EPG re-scanned to schedule season recordings. This is to catch and time changes in the EPG. The only time they are not re-scheduled is if the unique ID is the same (not sure of details as this is not available to most of the rest of the world).

Interesting. I would not think that it would overwrite unique IDs each time the guide updates. I am using mc2xml to pull guide data every evening. So, not sure where to start on remedying this issue.

[mvallevand]

Interesting. I would not think that it would overwrite unique IDs each time the guide updates. I am using mc2xml to pull guide data every evening. So, not sure where to start on remedying this issue.

You can't solve it, the table of deleted shows does not keep time, date or channel. If you browse your npvr.db3 database and look at the epg_event table, the unque_id's beginning with SH* are generic and cannot be trusted to tell you anything.

Martin