I have the Web PVR Manager running under Win 7 64 bit, recording radio programmes to a NAS box. Everything seems fine for about 24 hours or so, after which the browser windows report "Cannot connect to 127.0.0.1:1935" and the command line window, after many apparently successful "INFO: Refreshing" lines, reports:-
"Cannot fork at get_iplayer.cgi line 307".
At that point, I have to restart GiP altogether. Everything runs fine for 24 hours or so, after which and so on.
Any assistance gratefully received.
'Cannot fork' points to some kind of resource limitation: too many processes for system or user, memory or swap space exhausted, etc. It may have nothing to do with get_iplayer - 'cannot fork' may just be a symptom of a problem caused by some other application or service. Consider any upgrades or changes you've made recently. Recording directly to a NAS will be a bit more resource intensive since each download is pushed over the wire four times during re-muxing and tagging (that's several GB per hour of HD video), but I've no idea if that would make a difference in your case. Whatever the cause, it is unique to your system. My only suggestion is to run Task Mananger or Resource Monitor to see if your system is encountering resource limitations of some kind or some application is hogging memory, etc. The get_iplayer processes will appear as 'perl.exe'.
If you are running the Web PVR around the clock just to run PVR jobs, you might consider using Task Scheduler instead. Some slightly outdated instructions are here:
http://www.beebotron.org/helper_get_iplayer_help.php
Use the Vista instructions and note that you will already have this file:
Code:
C:\Program Files\get_iplayer\get_iplayer--pvr.bat
Thanks very much for your reply. There's no reason for - nor sign of - any resource limitation that I can see, yet the behaviour persists.
I will try using Task Scheduler instead as you suggest. But if I do this, does the cache still get refreshed automatically?
Many thanks for your help.
Quote:Quote:I will try using Task Scheduler instead as you suggest. But if I do this, does the cache still get refreshed automatically?
Yes
I can confirm this behaviour.
Seems to happen when doing something on the web ui.
The console will simply exit with the reported line 307.
Except there is no code at line 307.
I have had this issue on win 7 64 bit with 16G ram and on a win XP.
I was searching, applying settings and saving searches at the time.
I can assure you that there is code at line 307. You wouldn't have received that error message otherwise.
I never could duplicate this problem, so I've nothing more to add. The fork() system call is emulated by Perl for Windows, so the Web PVR is really a single process, which is why my best guess is that some sort of resource limitation might be the culprit, but that is conjecture. Until someone who knows what to look for encounters this problem, there's nothing to be done except restart your web pvr every day and/or use task scheduler for pvr runs.
My only other suggestion is to roll back to an earlier version of Perl and see if it behaves better. I don't know why it would make any difference, but it's easy enough to test. You can reinstall get_iplayer with older Perl 5.12 using the previous version of the installer:
http://www.infradead.org/get_iplayer_win...up_4.5.exe
You only need to reinstall the get_iplayer component.
i encountered the same issue and ended up setting the task scheduler to run the pvr and then terminate it after a couple of hours every day, but it's working fine, so no issues there with that solution. :)
vibe666: There is no reason to force Task Scheduler to terminate after a fixed period of time. No get_iplayer-related processes should be running when the pvr jobs are completed. The Web PVR runs the pvr queue in a different way that is more expensive in terms of system resources. The Web PVR server forks a copy of itself to handle each action invoked from the browser interface. On Windows, there is some as-yet-unknown problem that eventually prevents the server from forking after an extended period of time. This problem was hidden until recently because the browser-based pvr queue auto-run had always been broken. I may regret ever having fixed it :} You avoid the whole mess by using Task Scheduler.