NScriptHelper.dll -service:setting.m3u.update

[TheKenR]

Guys,

Here is exactly what it is trying to do when I run the command line I posted above. It never leaves the local server, all traffic is over the loopback adapter. There are 3 request/responses:

  6 0.349113594    127.0.0.1 → 127.0.0.1    HTTP 189 GET /service?method=session.initiate&ver=1.0&device=scripthelper HTTP/1.1
  8 0.350777311    127.0.0.1 → 127.0.0.1    HTTP/XML 350 HTTP/1.1 200 OK

Response to this GET is:
<rsp stat="ok">
<sid>64eac11ded8e4666b4d270c27144bbda</sid>
<salt>c29b50e8-5de5-46d6-8b8b-495064bda229</salt>
</rsp>

16 0.368299903    127.0.0.1 → 127.0.0.1    HTTP 232 GET /service?method=session.login&sid=43795b08a9444eff843c99de7c48b7a6&md5=3A8AFC95332D4A8021F85838027910E6 HTTP/1.1
18 0.370179093    127.0.0.1 → 127.0.0.1    HTTP/XML 478 HTTP/1.1 200 OK

Response to this GET is:
<rsp stat="ok">
<sid>43795b08a9444eff843c99de7c48b7a6</sid>
<donator>true</donator>
<allow_settings>true</allow_settings>
<allow_watch>true</allow_watch>
<allow_schedule>true</allow_schedule>
<allow_delete>true</allow_delete>
</rsp>

This is where it goes sideways...
26 0.375573440    127.0.0.1 → 127.0.0.1    HTTP 202 GET /services/service?setting.m3u.update&sid=43795b08a9444eff843c99de7c48b7a6 HTTP/1.1
28 0.375985152    127.0.0.1 → 127.0.0.1    HTTP 165 HTTP/1.1 404 Not Found

Response to this GET is a 404 error and the script exits.

It seems to login OK and has what appears to be a session ID but the "setting.m3u.update" parameter of the service URI doesn't appear to exist?

So then I noticed a subtle difference in the requests... so I tried this on the server using curl:

http://127.0.0.1:8866/services/service?m...de7c48b7a6

Response:
<rsp stat="ok"> </rsp>

Then I tried on the command line, and there's no error!

/opt/dotnet/dotnet /opt/nextpvr/system/NScriptHelper.dll -methodetting.m3u.update

So it appears instead of "service" the syntax requires "method". I don't have the source code but can you confirm that this is correct?

And after all that, I just took a look in the NPVR DB3 file and now see it has somehow retained an old URL from before I changed my password! When I changed my password I deleted the IPTV device and set it up from scratch again. It worked fine after this but are the old URLs cached somewhere? I'm sure sure where it grabbed it from. I'll delete and setup again then try once more.

Thanks
K

[TheKenR]

I just noticed Sub's message above has the method.

"-service:method="

Sorry, I missed that. I'll do a complete reset to get the M3U URL correct and try again. I'll report back later.

[TheKenR]

If you run this instead, does it make a difference?

dotnet NScriptHelper.dll -service:method=setting.m3u.update

Sub,

Once I reverted to a blank database to remove all the residual junk I ran the command you recommended and it works. I'll wait until tomorrow to see if it in fact will update the URLs in a new M3U file but at least I'm not seeing an error now. The key was the missing "method".

ken@ubuntu:/var/opt/nextpvr$ /opt/dotnet/dotnet /opt/nextpvr/system/NScriptHelper.dll -service:method=setting.m3u.update                      
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
</rsp>

ken@ubuntu:/var/opt/nextpvr$

Thanks Guys!
K

[mvallevand]

The logs should show you 3 new messages

updating tuning for
new channel:
Unchanged

@sub I was wrong about the VLCOPTS they seem to work. The issue is the m3u file https://github.com/iptv-org/iptv/blob/ma...calbtv.m3u there is a user-agent property that has a comma in it. Not sure if that is an error in the m3u spec. or NextPVR parsing.

Martin

[sub]

The key was the missing "method".

ken@ubuntu:/var/opt/nextpvr$ /opt/dotnet/dotnet /opt/nextpvr/system/NScriptHelper.dll -service:method=setting.m3u.update                      
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
</rsp>

Yep. This method= bit is only required for setting.xxxx services. It wasn't intentional, but rather a bug.

[TheKenR]

So I confirmed that it does work. All the URLs are updated with the new M3U file when I run the m3u.update helper. Although, it appears I need to stop and start the NextPVR-Server service before it takes effect. Is there another service in the script helper DLL that I can call to avoid a completer server restart to pick up the changed URLs?

Thanks
K

[sub]

Although, it appears I need to stop and start the NextPVR-Server service before it takes effect.

In what way - what's not working? If you then open the Settings->Channels tab, are the channels shown with the correct urls?

[TheKenR]

Although, it appears I need to stop and start the NextPVR-Server service before it takes effect.

In what way - what's not working? If you then open the Settings->Channels tab, are the channels shown with the correct urls?

Hi Sub,

What happens is my provider changes the URL (new access token). When the stream stops working I see this in the NextPVR log.

2022-06-17 15:40:03.477 [ERROR][34] {"message":"Invalid or expired token"}
2022-06-17 15:40:03.477 [ERROR][34] Download m3u8 failed...
2022-06-17 15:40:03.477 [ERROR][94] Unable to StartStream(): One or more errors occurred. (Response status code does not indicate success: 401 (Unauthorized).)

So I run the helper DLL to update NextPVR with the new M3U file. That works fine, I do see the new URL in the channel list and I also can query the CHANNEL_MAPPING table and see it there. The log file shows success as well. So that's all good but when I go to view the channel, NextPVR is still using the old URL and I get the 401 error again. It appears to have it cached or something. So I restart the service and then it will load up the new URL from the database and everything works until the next token change. I'm hoping there is some way I can "flush the cache" without a restart.

Thanks
K

[sub]

I've made a change to the next release that should resolve this.

There is a few things that can cause it to reload the channel cache, but none of them very easy for you to do from a script.

[TheKenR]

I've made a change to the next release that should resolve this.

There is a few things that can cause it to reload the channel cache, but none of them very easy for you to do from a script.

Ok great! Thanks! Do you have any idea when you will be releasing this?

K