EPG Update Errors

[jcole998]

Hello.

I know that V4 is obsolete but it still has value for me and I use it every day in addition to V6.

I'm getting errors while updating the EPG and would like to know if I can do something to prevent them from recurring. I manually updated the EPG this afternoon and the NPVR.log.1 at record 2108 shows the following:

{
  "stationID": "96299",
  "serverID": "20141201.web",
  "code": 7020,
  "response": "SCHEDULE_RANGE_EXCEEDED",
  "minDate": "no_db_mindate",
  "maxDate": "no_db_maxdate",
  "requestedDate": "2025-04-01",
  "message": "Date requested (2025-04-01) not within no_db_mindate -> no_db_maxdate for stationID 96299."
}
2025-04-01 15:12:39.691 [ERROR][188] (798 - Uplift HD): Date requested (2025-04-01) not within no_db_mindate -> no_db_maxdate for stationID 96299.
2025-04-01 15:12:39.691 [DEBUG][188] 798 Uplift HD
{
  "stationID": "96299",
  "serverID": "20141201.web",
  "code": 7020,
  "response": "SCHEDULE_RANGE_EXCEEDED",
  "minDate": "no_db_mindate",
  "maxDate": "no_db_maxdate",
  "requestedDate": "2025-04-02",
  "message": "Date requested (2025-04-02) not within no_db_mindate -> no_db_maxdate for stationID 96299."
}
2025-04-01 15:12:39.691 [ERROR][188] (798 - Uplift HD): Date requested (2025-04-02) not within no_db_mindate -> no_db_maxdate for stationID 96299.
2025-04-01 15:12:39.691 [DEBUG][188] 798 Uplift HD

Can you offer some tips I can use to prevent these errors?

Thanks.

[mvallevand]

Looking at the logs there might not be any data for the stations with the error so contact SD lineup support.

Also make sure your EPG update times are offset, this error is troubling, are you using a VPN on either of your servers or are they on different PC's? Tokens shouldn't be expiring in normal use thanks to change in SD recently.

Code:

2025-04-01 04:07:07.173    [DEBUG][9]    Requesting /schedules
2025-04-01 04:07:07.240    [ERROR][9]    System.Net.WebException: The remote server returned an error: (403) Forbidden.
   at System.Net.HttpWebRequest.GetResponse()
   at NShared.SchedulesDirectJSONEPGSource.DoPOSTRequest(String url, String token, String body)
2025-04-01 04:07:07.240    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:07Z"}
2025-04-01 04:07:07.240    [DEBUG][9]    Got /schedules:

Martin

[jcole998]

Thanks, Martin.

I'll go through log and remove those channels from the lineup.

Also, I checked the update times between V4 and V6 and found V6 update starting only 30 minutes before V4 starts. I changed that to 2 hours. They may have overlapped. Thanks for the heads-up.

JohnC

PS - Love the Maple Leaf.

[mvallevand]

Do you have the v6 logs? It looks like more than an overlap. I can see that the initial token expiry was here "tokenExpires":1743494819 but it should only have only logged in once and this was at the start of the EPG.

Code:

2025-04-01 04:07:00.478    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:00Z"}
2025-04-01 04:07:01.113    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:00Z"}
2025-04-01 04:07:01.526    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:01Z"}
2025-04-01 04:07:02.024    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:01Z"}
2025-04-01 04:07:02.411    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:02Z"}
2025-04-01 04:07:02.658    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:02Z"}
2025-04-01 04:07:02.899    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:02Z"}
2025-04-01 04:07:03.125    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:03Z"}
2025-04-01 04:07:03.535    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:03Z"}
2025-04-01 04:07:03.821    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:03Z"}
2025-04-01 04:07:04.256    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:04Z"}
2025-04-01 04:07:04.680    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:04Z"}
2025-04-01 04:07:05.078    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:04Z"}
2025-04-01 04:07:05.178    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:05Z"}
2025-04-01 04:07:05.293    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:05Z"}
2025-04-01 04:07:05.874    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:05Z"}
2025-04-01 04:07:06.279    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:06Z"}
2025-04-01 04:07:06.574    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:06Z"}
2025-04-01 04:07:06.869    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:06Z"}
2025-04-01 04:07:07.240    [ERROR][9]    {"response":"TOKEN_EXPIRED","code":4006,"serverID":"20141201.web","message":"Token has expired. Request new token.","datetime":"2025-04-01T08:07:07Z"}

[jcole998]

Yeah, I posted the V6 logs. No sure I understand the token concern though. Not unusual for me...

JohnC

[mvallevand]

I just wanted to confirm that the overlap wasn't the problem. I think see what happens though, since v4 doesn't have logic to login after the token expiry that sub added in 2022.

This code on the EPG update used to give a new token that would be valid for 24 hours

Code:

2025-04-01 04:06:39.277    [DEBUG][9]    Checking for any Schedules Direct listings
2025-04-01 04:06:39.277    [DEBUG][9]    Doing EPG update from Schedules Direct JSON
2025-04-01 04:06:39.278    [DEBUG][9]    Authenticating Schedules Direct account

Now it renews the existing token

Code:

2025-04-01 04:06:39.561    [DEBUG][9]    Using URL: https://json.schedulesdirect.org/20141201
2025-04-01 04:06:39.603    [DEBUG][9]    
{"account":{"expires":"2025-08-26T16:55:53Z","messages":[],"maxLineups":4},"lineups":[...],"lastDataUpdate":"2025-04-01T08:01:44Z","notifications":[],"systemStatus":[{"date":"2023-08-01T16:00:00Z","status":"Online","message":"No known issues."}],"serverID":"20141201.web","datetime":"2025-04-01T08:06:39Z","code":0,"tokenExpires":1743494819}

The bad news is that expiry was 20 seconds later 4:06:59 AM during the EPG update. So you are now potentially dependent on v7 (or v6.1.5 in your case) resetting the token or needing to wait 24 hours so the EPG login will do it.

My gut says you probably should do the EPG update in v4 first.

I am going to link SD to this thread.

Martin

[jcole998]

OK, Martin, I understand what you are suggesting and will make the change.

I'll let you know.

Your effort on this is greatly appreciated. Thank you.

JohnC

[mvallevand]

SD did look at this thread and said the original issue was that these channels don't exist anymore so you needed to do a lineup scan. The more critical issue on v4 not meeting SD spec was noted but there aren't enough v4 users of SD anymore to make any API change worthwhile.

I did not that v4 was causing other issues for you with SD and even recording

2025-04-01 09:01:00.270 [DEBUG][8] No errors, but no data delivered

Time to figure out why you need v4 and move on especially as a Kodi user.

Martin

[jcole998]

My V4/V6 dichotomy began with release of V5 and the introduction of using TCPIP protocol instead of UDP for commuinications. After finally getting V5 to work, I noticed that recordings were not completing. At some random point, the device would simply stop sending data. At this point I learned how to use Wireshark to capture and analyze what's going on. Wireshark showed that TCPIP was not keeping up with data rates being used by the Hauppauge DCR-3250 Triple Tuner with a tuning card. Further research convinced me that TCPIP was not meant to be used for this type of video transmission. I asked about this at several points in the NextPVR forum but despite all explanations from helpful posters, there was no solution offered that worked. So I stopped using V5. V4 was working perfectly using UDP.

When V6 appeared, I thought maybe something changed and decided to give it a try. V6 behaved the same way...recordings just stopping. I installed V4 and V6 on a new HP laptop with Win 11 thinking a speedier machine would fix my problem. It did not.

Again I stayed with V4 but every time a new release of V6 appeared, I gave it a try until one day, V6 worked. I used Wireshark to make sure V6 was still using TCPIP. It was and I have no explanation as to why V6 started working for me. Since then, I have used V4 for most of my reording and only V6 for Kodi. Kodi works nicely on my Lenovo tablet.

So...here I am today. I'd planned to post my logs from both V4 and V6 showing the overnight EPG updates but I'd failed to change the V4 update ahead of V6. Dumb. I'll have both logs tomorrow with updates running at the proper times. I can post them tomorrow if you still wish to take a peek.

Overall, I've enjoyed considerable success running this duet of NextPVR versions, but if V4 has to go, I think my confidence in V6/V7 will allow me to sleep at night.

Sub and you maintain a terrific product. Thank you.

JohnC

[BrettB]

My V4/V6 dichotomy began with release of V5 and the introduction of using TCPIP protocol instead of UDP for commuinications. After finally getting V5 to work, I noticed that recordings were not completing. At some random point, the device would simply stop sending data. At this point I learned how to use Wireshark to capture and analyze what's going on. Wireshark showed that TCPIP was not keeping up with data rates being used by the Hauppauge DCR-3250 Triple Tuner with a tuning card. Further research convinced me that TCPIP was not meant to be used for this type of video transmission. I asked about this at several points in the NextPVR forum but despite all explanations from helpful posters, there was no solution offered that worked. So I stopped using V5. V4 was working perfectly using UDP.

When V6 appeared, I thought maybe something changed and decided to give it a try. V6 behaved the same way...recordings just stopping. I installed V4 and V6 on a new HP laptop with Win 11 thinking a speedier machine would fix my problem. It did not.

Again I stayed with V4 but every time a new release of V6 appeared, I gave it a try until one day, V6 worked. I used Wireshark to make sure V6 was still using TCPIP. It was and I have no explanation as to why V6 started working for me. Since then, I have used V4 for most of my reording and only V6 for Kodi. Kodi works nicely on my Lenovo tablet.

It seems strange that you would have seen problems with TCP (vs UDP) like you describe. In fact, TCP should have been better because it has reliable/guaranteed packet delivery vs UDP's "send it and if it gets lost, oh well" functionality. I know that back with v4, I would occassionally have recordings with "glitches" when the network was busy with other things going on and some of the UDP packets didn't make it. And that situation was eliminated with using the TCP connections. I wonder if your problem was on the Hauppauge DCR-3250 driver/firmware side rather than the NextPVR side. I don't think that many users had DCR-3250s.

At any rate, it probably would be really good for you to get away from V4--especially with the changes on the SD API side.

I recently cut the cord and got rid of my Xfinity cable TV service. So, I've got 2 Silicon Dust HDHR3-CC 3-tuner cable card devices that I'm no longer using. They have been used extensively with NextPVR v4, v5, and v6 over the years very successfully. I'd be happy to share one with you if you would like.

-Brett