NextPVR Forums

Full Version: UpdateEPG.bat not being triggered. (Using Webgrab+Plus)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi All,

I realise that this is a problem that crops up from time to time and have read the older posts but have not found the answer.

I have a working UpdateEPG.bat file in the \scripts directory.
By working, I mean that it executes Webgrab+Plus which successfully downloads the EPG and updates the EPG .xml file correctly.
NextPVR then displays the updated EPG in the NextPVR application.
However this only works when I click the 'Update EPG' button in Channels section of Settings and not automatically at the time set in Misc2 (02:00:00AM).
I also changed the time to the current time +2mins, and restarted the recording service. Webgrab+Plus does not trigger.
The contents of my .bat file are as follows:

Code:
cd "C:\Program Files (x86)\Webgrab+Plus\bin\"
Webgrab+Plus.exe

Running the .bat file manually also correctly runs the Webgrab+Plus.exe and updates the EPG.xml file.
Any help would be appreciated.

System is Windows 10 Home x64
Quote:UpdateEPG.bat not being triggered
Everytime we've looked in to these types of posts before, we've found that UpdateEPG.bat is being run, but something is going wrong in the users batch file. If you want to post the logs, I can confirm that is the case.

When it runs from the recording service overnight, it runs as the 'localsystem' account. Its possible this "Webgrab+Plus.exe" utility is looking for something in your account, like a settings file etc, and not able to find it.

To diagnose what is happening you might need to put some logging in your batch file, like redirecting the output of Webgrab+Plus.exe to text file, so you can see what it's saying when you run it.
Hi sub,
Thanks for your prompt reply. Indeed you could be on the right track! Webgrab+Plus uses a 'WebGrab++.config.xml' file which is located in C:\Users\MyUserName\AppData\Local\WebGrab+Plus\ directory. Where "MyUserName" is the currently logged in user. So question: If the .bat file is run, is it via a system account which does not have access to that directory??
If that's the case, I need to read more of the WebGrab++ documentation to see if maybe I can relocate the config file where it's accessible and redirect output to a text file as you suggested. My guide is currently updating (takes about 2 hours), so I might not get to it today but I will update you on this tomorrow and post the logs if needs be.
Thanks,
pmcdon
Looking a the documentation for WebGrab plus it uses %localappdata% which willn include a different username. From a quick search there is a second command line option you will need to add to point to the folder with the webgrab config.xml file.

Martin
Ok, Just to update: I moved the 'WebGrab++.config.xml' file to "C:\Program Files (x86)\Webgrab+Plus"
and modified the UpdateEPG.bat:

cd "C:\Program Files (x86)\Webgrab+Plus\bin"
Webgrab+Plus.exe "C:\Program Files (x86)\Webgrab+Plus"

I also edited WebGrab++.config.xml to change the location of the output guide.xml to the same directory.
The argument added to the batch file is simply the path to the config file in quotes. This did not initially work because needed site.ini files were not found in the expected location (Same folder or sub-folder). So I relocated the site.ini folder also and then everything worked then. Interestingly, it only worked correctly when I ran the batch file with administrator privileges.
However, it also runs correctly when NextPVR launches it without having to force elevation of permissions.
(I tried runas /user:administrator in the .bat file, but that prompts for the admin password).
The only issue I have now is that I have 300+ channels mapped to the incorrect guide.xml file and I don't see an easy way to remap these other than editing each channel individually.
I've tried exporting the channels from devices, then doing a 'replace' in a text editor to change the paths and then importing the channels back in, but when I check the channel details, the original path is still shown??
Is there another way?

Thanks for pointing me in the right direction. If I get time, I may put together a howto for configuring WebGrab+Plus for use with NPVR because the default file locations cause it to fail.

The only comment I would make is that surely the "Update Guide" button should execute the UpdateEPG.bat file in exactly the same way as the timer does. The fact that it doesn't, is causing issues to users. This is based on my own experience and from reading through posts from others using other grabbers.
Maybe a feature request would be to ensure that the guide updates under the logged in user account, or alternatively launch the batch file as localsystem when the Update EPG button is pressed?
It's not a great idea to put data files in the Program Files folder - it would have been easier just to change the Nrecord service to run under a user account.

Alex
ACTCMS Wrote:It's not a great idea to put data files in the Program Files folder - it would have been easier just to change the Nrecord service to run under a user account.

Alex

I appreciate this but I needed to debug and understand what was going on, so I put them in a convenient location for testing. The plan is to tidy up when I find a fix.
I've put the .xml files back in their original location (not least because I don't want to have to edit all the channel details) and am sure I have identified a simple solution (I just need to tidy up). I'll post back later with details later when I verify that everything now works as expected.
OK after much messing about, I've settled on this as the solution:

When the UpdateEPG.bat is launched, it does not have full access to the config file in the logged in user AppData directory (as mentioned by sub) which in my case is "C:\Users\myUsername\AppData\Local\WebGrab+Plus". So 'WebGrab+Plus.exe' immediately exits with an error.

From interpreting the WebGrab++ logs in "C:\ProgramData\ServerCare\Webgrab" (Note ProgramData is a hidden folder), I was able to see that the application searches through a set of directories if it cannot find 'WebGrab++.config.xml' file in the default location. One of those directories is "C:\ProgramData\ServerCare\Webgrab" (Same as log output).

So the solution I have settled on is to move the config file to that location. Secondly, any site.ini files that are referred to in the config file must also accompany it. So in my case (I only use Sky UK), I moved a copy of the 'uk-sky.com.ini' file there also. Strangely, I was able to leave the guide.xml file in "C:\Users\myUsername\AppData\Local\WebGrab+Plus", which is great as I now don't need to change the channel mapping.
And 'UpdateEPG.bat' is now back exactly as in my OP (No need to add a path to the config file).

Finally for anyone reading this in a similar situation, when I was debugging, I also elevated permissions for "WebGrab+Plus.exe", I can't say for sure that this made any difference but just in case. Locate the .exe file, right click on it, choose Properties. Then click on the security tab and make sure ALL APPLICATION PACKAGES, SYSTEM, Administrators and Users have 'Full Control' permissions. You can select each group name one by one and click on the edit button to set this.
I also set 'Run this program as administrator' in the Compatibility tab -> 'Change settings for all users' dialogue. The above did not have any effect though until I relocated the config.ini file, so I can't say it made a difference.
Perhaps not surprising using that folder is how it is documented on the WebGrap web site http://www.webgrabplus.com/documentation...re/nextpvr However I didn't link it because of this post here https://forums.nextpvr.com/showthread.ph...post482789

Forum searches can be helpful.

Martin
mvallevand Wrote:Perhaps not surprising using that folder is how it is documented on the WebGrap web site http://www.webgrabplus.com/documentation...re/nextpvr However I didn't link it because of this post here https://forums.nextpvr.com/showthread.ph...post482789

Forum searches can be helpful.

Martin

Well done. So rather than being helpful, you decided to go the obnoxious route.
Pages: 1 2