UltraXMLTV runs manually, freezes when GBPVR calls it

[zehd]

Whether you open manually or automatically, Ultra will always 'open' the file. It's obvious that when run automatically, Ultra is not even beginning to process records.

Because it seems to work for eveyone when using the task schedule method, I'm not concerned at the moment. Personally I don't use the UdateEG.bat method either, and that's why I haven't found a problem. I have tested with Update.bat method, and it never fails for me.

I still don't think it's related to 'Interact with Desktop' issue, but who knows.

It's possible that it's because you're using non default paths, though I've tested for that too. Maybe it's something like XP SP3 or some other udate, that I haven't done, and others have...

For now, use the Task Schedule method and you should be fine

[dennit]

I still don't think it's related to 'Interact with Desktop' issue, but who knows.

I don't think it's related to this either.

It's possible that it's because you're using non default paths

That's why I put this info in my post - one of the things that was similar between my machine and the other reports.

Maybe it's something like XP SP3 or some other udate, that I haven't done, and others have...

For background, I'm on Media Center Edition 2005 of XP, and on SP2, not SP3.

For now, use the Task Schedule method and you should be fine

That's my plan. I'm pretty sure that will fix it, but I'll report back just to confirm. I'm not really concerned - it's easy to run manually or by scheduled task, but I thought it was an interesting phenomenon. That's why I posted as much detail as I thought would be enlightening.

I wonder if the UpdateEPG.bat method is working reliably for anyone. Originally, I saw intermittent success with an older version of Ultra, which would keep the EPG full as long as it succeeded before data ran out. Anyone who reboots before data runs out would also see data in the EPG. Anyone who manually runs an update via System or uses the scheduled task method would also miss this subtle problem.

[zehd]

I don't think it's related to this either.



That's why I put this info in my post - one of the things that was similar between my machine and the other reports.



For background, I'm on Media Center Edition 2005 of XP, and on SP2, not SP3.



That's my plan. I'm pretty sure that will fix it, but I'll report back just to confirm. I'm not really concerned - it's easy to run manually or by scheduled task, but I thought it was an interesting phenomenon. That's why I posted as much detail as I thought would be enlightening.

I wonder if the UpdateEPG.bat method is working reliably for anyone. Originally, I saw intermittent success with an older version of Ultra, which would keep the EPG full as long as it succeeded before data ran out. Anyone who reboots before data runs out would also see data in the EPG. Anyone who manually runs an update via System or uses the scheduled task method would also miss this subtle problem.

Well, I use MCE 2005 and SP2, but I don't auto install all the udates that come around...

I know that it works with UpdateEPG.bat, at least when I test, and when ever I have set it to perform thye update at the GB-pPVR udate time...

It's great that you gave so much information. I'm actually going to try again, with non default paths AND udateEPG method just to see if it's that...

[dennit]

New info - it ran correctly last night, before I'd changed it to the scheduled task method. It seems to still be intermittent. I'm going to just watch it for a while.

[zehd]

New info - it ran correctly last night, before I'd changed it to the scheduled task method. It seems to still be intermittent. I'm going to just watch it for a while.

You know, I've been thinking that maybe you could benefit from using a sleep between lines in the UpdateEPG.bat. I have a small util called sleep.exe ( forgot where I got it, and pretty sure it's free or public or whatever.

Sometimes I add something like 'sleep 2' between the download and the enhance.

I can see from your logs the enhancer loads the file and it knows that it is automatic (that means it should start processing) but I just don't know why it acts up...

It might have something to do with CU priorities... I really don't know...

Maybe it's time I get the 'Manager' cleaned up and working again...

[dennit]

You know, I've been thinking that maybe you could benefit from using a sleep between lines in the UpdateEPG.bat.

I may try that. Still .... if it needed a sleep pause, you'd think it would hang some of the time when run manually by either running the batch file directly from Windows or from the System screen. I've never seen that happen and I've run it manually quite often.

It really looks like it has something to do with being run by the Recording Service. In my logs, you see that the batch file was started by the RS at about 1:00 AM. The batch downloaded EPG data, then Ultra started processing and hung in memory for 9.5 hours. Then I killed the Ultra task, the original batch file continued on, it downloaded another load of EPG data and Ultra hung again - until I again killed the hung task 45 minutes later. Yet the manual run of the complete batch file with the same two Ultra runs in it a few minutes later ran just fine.

The RS runs under a different user account. I wonder if I can figure out a way to run Ultra under that user.

[zehd]

The RS runs under a different user account. I wonder if I can figure out a way to run Ultra under that user.

Why? Eiether the System account or desktop should be fine...

[dennit]

Why? Eiether the System account or desktop should be fine...

Why? - Because sub says the only difference between running UpdateEPG automatically at the time set by config vs. running it manually at the System screen is the account under which it runs. It seems to run fine in one case (manual), but not the other (auto via config), so it makes sense to me to try to duplicate the conditions where it fails by running it under the account that seems to cause it to fail.

[zehd]

Why? - Because sub says the only difference between running UpdateEPG automatically at the time set by config vs. running it manually at the System screen is the account under which it runs. It seems to run fine in one case (manual), but not the other (auto via config), so it makes sense to me to try to duplicate the conditions where it fails by running it under the account that seems to cause it to fail.

GB-PVR Recording service can either run as a System Account, Or the desktop session (which is effectively like running it manually from your desktop, logged in, or yet another user, specified

I suggest interacting with desktop, but then also means you must be logged into your desktop all the time. I guess someguys like to log off and log into a different account to surf or game or write letters. In this case Interact with Desktop won't work, as you need to be logged in.

I doubt that I will ever write a program that does not require interacting with desktop... But that's because when Windows isn't logged in, I can't run and use my dev tools, so I'm effectively blind.

[dennit]

GB-PVR Recording service can either run as a System Account, Or the desktop session (which is effectively like running it manually from your desktop, logged in, or yet another user, specified

I suspect I wasn't being clear. I was just thinking about debugging and wondering if there was some way to log in as the System Account and then manually run Ultra. I don't know if it's even possible, but if it is, it might throw some light on why the scheduled runs are failing when manual runs don't.

I suggest interacting with desktop, but then also means you must be logged into your desktop all the time.

I'm not totally sure how desktop interaction [or not] applies to my comment. I've tried it both ways and it seems to have no effect. Are you saying that running with desktop interaction turned on is the same as logging in as the System Account? I'd still like to manually run UpdateEPG.bat as the System Account.

IIRC, you can specify the account that a scheduled task runs under. Maybe I should try setting up a scheduled task and running it under the System Account. Purely for debugging info, not as any kind of fix.