NextPVR - wrong parsing of episode data?

[chjohans]

I'm using NextPVR as a backend, with Emby and the EMby plugin for NextPVR.

I'm on Version: 5.2.7.220410 of NextPVR, on Windows 10, as I'm not sure that the Emby plugin has support for version 6.x.

I have "series recording" enabled for a couple of daily news broadcasts, and I just noticed that this stopped recording a couple of days ago. This happened just when the "Episode" for the news program(s) passed 1000.

I noticed that NextPVR seems to "truncate" the episode number to three digits so that episode 1001 becomes episode 100. Since Emby gets EPG data from the NextPVR plugin, it gets the wrong episode numbers and thinks it has already recorded the upcoming episodes. Or rather, it will schedule for recording every 10th episode above 1000 as E1001 becomes E100 in Nextpver and remains at that until E1010 becomes E101, then it stays at that until E1021 becomes E102, and so on.

Please see the attached screenshot of EPisode S01 E1006 of a news broadcast, and notice how this is truncated to S01E100. Here is the entry in my XMLTV source for this exact episode:

Code:

<programme start="20221007020000" stop="20221007030000" channel="CNA">
    <title lang="en">Asia Tonight</title>
    <sub-title>Episode S1 E1006</sub-title>
    <desc lang="en">CNA correspondents bring you the top stories of the day with 'live' reports and interviews to keep you up-to-date on the day's events.</desc>
    <icon src="https://production.togglestatic.com/shain/v1/dataservice/ResizeImage/$value?Format='jpg'&amp;Quality=85&amp;ImageId='5230082'&amp;EntityType='LinearSchedule'&amp;EntityId='26082941-ae82-41c4-a01e-3380e3fb1d92'&amp;Width=1280&amp;Height=720&amp;device=web_browser&amp;subscriptions=Anonymous&amp;segmentationTags=all" />
    <episode-num system="onscreen">S1 E1006</episode-num>
  </programme>

I was able to work around this issue by deleting all guide data from NextPVR itself and adding the same XMLTV guide to Emby, so that Emby gets its EPG directly rather than through the NextPVR plugin. This seems to work, and the episode numbers are now correct also when E is above 1000. This of course means that I have no EPG in NextPVR, but I can live with that as I mainly watch TV through the various Emby clients.

Is this a known issue, and is there a solution to this?

Granted, a series with episodes above 1000 might be rare, but I actually have more than one such case in my XMLTV source (grabbed with WenGrab+ from the broadcaster's online guide). There is nothing in the XMLTV

And, maybe this is a long shot, but does anyone happen to know if the NextPVR plugin in Emby will work with Nextpver Version 6.x?
(I was thinking this might have been fixed in a version later than what I'm currently on)

[mvallevand]

Sub, I looked at the regex that the strings64.exe command output and there is a mix of \d+ and \d{1,3}. I saw the post on the Emby forum and it looks like WebGrab+ is putting monthday as the episode in this case. I am worried about \d+ because this weird use of episode could really be screwy if the grabber had put 202210006 in there. I am not even sure if apps like Kodi and other NextPVR clients format it correctly, I'd have to do some testing with 4 digits.

Martin

[chjohans]

Thanks, it works for me now by not using any EPG in NextPVR, but others might run into the same or a similar issue. The episode data is perfectly valid according to the XMLTV DTD. WebGrab+ is just grabbing the episode data, not using monthday, but it might very well be that the site it's grabbing from (https://www.mewatch.sg/channels/cna/97072) use monthday as it's episode number. But in any case, it's a perfectly valid episode number.

[sub]

If you can supply a sample xmltv file, I'll fix it for the next build. I can't do anything about old v5 builds though.

I'm on Version: 5.2.7.220410 of NextPVR, on Windows 10, as I'm not sure that the Emby plugin has support for version 6.x.

It should work fine with v6. For the most part v6 was about moving to a newer version of the .NET runtime. The network api etc (that Emby use) didn't change.

[mvallevand]

I forced episode to 4 digit and tested Kodi and it doesn't have any issue with it so this seems OK. Where I saw it in the code with strings64.exe was

.*S(?<SeasonNumber>\d{1,3}).?E[p]?(?<EpisodeNumber>\d{1,3})
^(?<SeasonNumber>\d{1,3})\\\/(?<EpisodeNumber>\d{1,3})\.

If you change that you might want to change SeasonNumber too since year is a valid season number.

Martin

[chjohans]

If you can supply a sample xmltv file, I'll fix it for the next build. I can't do anything about old v5 builds though.

I'm on Version: 5.2.7.220410 of NextPVR, on Windows 10, as I'm not sure that the Emby plugin has support for version 6.x.

It should work fine with v6. For the most part v6 was about moving to a newer version of the .NET runtime. The network api etc (that Emby use) didn't change.

Great, please see the example XMLTV file attached.

It stopped working for me again as NextPVR would again populate its EPG from DVB/ATSC EPG, and I see no option to disable that. So the EPG from NextPVR will again overrule the (correct) XMLTV in Emby, so a quick fix for this would be greatly appreciated. It won't be any peace at home until my wife gets her news recordings back.....

In the meantime I'll upgrade to NextPVR 6.0, and hopefully, a new build with this issue fixed will arrive sooner rather than later!

Edit: Found a way to disable the EPG from DVB/ATSC EPG, turns out it had a default time set to update the EPG. I cleared that and now it says "No automatic EPG update" so hopefully that will stick.

Thanks again!!!

[sub]

This is fixed for the next build.

[chjohans]

Great, thank you!