Getting Pluto extra to work

[bouilliabai]

Attached.

Note that the software is being run on an old laptop, with the idea of making it a dedicated PVR server. Since no transcoding is taking place and NextPVR is Windows 7 compatible, there didn't seem to be any need to use anything newer. Over the period of the logs there will be some instances where the laptop was put into sleep mode or even shut down entirely. Some manual EPG updates were performed in that time as well.

[mvallevand]

I didn't see any wake for epg overnight or extra ones today so it is not clear what you are saying

Martin

[bouilliabai]

The extra updates occur between 11 pm and 8 am, when no updates should be occurring. The computer was offline last night due to stormy weather (which is quite welcome this time of year), but looking at BatchProcessing.log for the previous night, there were updates at:

3:11:19.51, 3:40:44.98, 4:09:40.00, 4:38:10.56, 5:06:15.02, 5:33:48.50, 6:00:57.60, 6:27:34.14, 6:53:43.76, 7:19:27.12  and 7:44:48.62 before regular updates resumed every 3 hours (t=180) at 8:09:46.18.

[mvallevand]

Ok I will wait for fresh logs, when the logs show what is happening. They started after those times.

Martin

[bouilliabai]

The logs are rolling over so quickly due to the frequency of updates and number of channels that only the ones between 6 am and the resumption of regular updates at 8:09 this morning are shown in full. At the beginning of each cycle there are some calls via requests.py. Hopefully this is enough to help determine the reason for the off-schedule updates.

Edit: Looks like attachments are limited to 2 MB. Therefore sending in 2 parts.

[mvallevand]

Nope, I am not going to look at it without logs. Remember this addon is not supported so I am not going to spend much time on it. This doesn't happen to me.

[bouilliabai]

Part 2. The logs weren't attached prior to the edit because the single zip file was apparently too large.

[bouilliabai]

Yesterday, I did several manual EPG updates, and that increased the frequency of timed Pluto EPG updates considerably.  Relevant logs attached.

A reboot at 9 am, and another afterward for another reason will hopefully calm things down.

As an aside, the main issue with updating Pluto channels is that pluto.py looks to see if a channel number is taken, then if so, adds or indexes the minor number via the ExtraChannel function. In order to keep the channel numbering intact, the channels have to be deleted in the extra device page before running "pluto.py extra". But then, it appears they are assigned new id's and have to be remapped to the EPG. Using the method sub suggested for updating channels, therefore, requires quite a bit of manual intervention. For now the best way around this appears to be generating the new extras file, comparing with the old, then editing one or the other to restore the existing channel numbers and include the new information, and finally updating the channels in NextPVR, saving only the new ones. Would it be possible to ignore existing channel numbers in pluto.py by commenting out the responsible lines of code without messing up something else, or better yet, make the channel numbering process user selectable?

[mvallevand]

I was away last week I forgot about this but will have a look later today.

For updating an extra untick them all with the top left box and only add the ones that are new. Sub's process for updating varies a lot by device type.

Martin

[mvallevand]

The pluto.py on the wiki is different from the one I use,  could you overwrite yours with the pluto.py in this zip file run the xmltv-update 300 and see if it helps.  Note the default is now 5 hours not 3 since more data is being provided in the API

Martin