Closed seanf closed 9 years ago
Sorry, my account defaulted to ignoring this repository, so I have only just seen this issue. Will look into it.
Does running getWizPnP.exe from the commandline hang as well?
"C:\Program Files (x86)\YARDWiz\getWizPnP.exe" -vv --all -l --episode --index --sort=fatd -H 192.168.0.122 -p 49152
No, getWizPnp works. The deleted entries appear like this on stderr, without any delay:
The Checkout:idehdd/Recordings/ABC_Apr.30.2015_19.53+57142.71580.tvwiz:
header too small to be valid 0 < 81140
YARDWiz takes a little while to skip (silently) over each of the deleted entries, but eventually YARDWiz gets stuck at what must be this point:
Hawaii
Five-0:idehdd/Recordings/TEN_Digital_Mar.11.2015_22.33+57092.81180.tvwiz: header too small to be valid 0 < 81140
On 24 May 2015 at 07:43, lpinner notifications@github.com wrote:
Does running getWizPnP.exe from the commandline hang as well? "C:\Program Files (x86)\YARDWiz\getWizPnP.exe" -vv --all -l --episode --index --sort=fatd -H 192.168.0.122 -p 49152
— Reply to this email directly or view it on GitHub https://github.com/lpinner/yardwiz/issues/43#issuecomment-104947069.
If you look in the Windows task manager when it hangs, do you see a getWizPnP.exe process? If so, what happens if you kill the getWizPnP process?
I haven't been able to reproduce the hang, testing on Linux and Windows, but I've only got a handful of recordings deleted using YARDWiz/GetWizPnP. I've put a little workaround in that will allow you disable the fetching of program info when the quick listing option is enabled. Get it from this link.
https://bintray.com/lukepinnerau/generic/YARDWizDev/Development
It does mean that all you'll see is the basic dump from the Wiz's index.txt so deleted recordings will show up and you'll need to know which ones you deleted.
To use, in the tools->options menu, enable quick listing and disable extended info (next option below quick listing).
Using Process Explorer, I found 2 copies of getWizPnP.exe, each with a child process running getwizpnp.exe.
One group had this command line for both getWizPnP.exe and getwizpnp.exe: getWizPnP.exe --all -v -l --episode --index --sort=fatd -H 192.168.0.122 -p 49152 --wizpnpTimeout=2 --delay=0.25
but the other group had this: getWizPnP.exe -vv --all -l --episode --index --sort=fatd -H 192.168.0.122 -p 49152
When I killed the child process getwizpnp.exe with the shorter command line (no timeout parameter), the parent must have exited, YARDWiz woke up and carried on with the rest of the list as if nothing had happened. On closer inspection, the remaining entries don't have episode descriptions, but everything else is fine, including the hiding of deletions.
I tried running both command lines manually at the same time, but I couldn't reproduce the problem that way.
Seeing the sheer amount of output on the console made me think - could it be that the stderr of getwizpnp.exe is exceeding the size of a buffer, causing a deadlock? I've had such problems when using Java's low level process handling; maybe this is the Python version. A bit like this? http://stackoverflow.com/a/2561918/14379
It looks like stderr just exceeds 4096 bytes, right about where the freeze happens.
On 27 May 2015 at 22:20, lpinner notifications@github.com wrote:
If you look in the Windows task manager when it hangs, do you see a getWizPnP.exe process? If so, what happens if you kill the getWizPnP process?
I haven't been able to reproduce the hang, testing on Linux and Windows, but I've only got a handful of recordings deleted using YARDWiz/GetWizPnP. I've put a little workaround in that will allow you disable the fetching of program info when the quick listing option is enabled. Get it from this link.
https://bintray.com/lukepinnerau/generic/YARDWizDev/Development
It does mean that all you'll see is the basic dump from the Wiz's index.txt so deleted recordings will show up and you'll need to know which ones you deleted.
To use, in the tools->options menu, enable quick listing and disable extended info (next option below quick listing).
— Reply to this email directly or view it on GitHub https://github.com/lpinner/yardwiz/issues/43#issuecomment-105887786.
Yep, I think that’s it. I was able to artificially reproduce by filling the stderr buffer up. The above commit should fix it. Can you try the version at https://bintray.com/artifact/download/lukepinnerau/generic/YARDWiz-1.1dev-2-win32setup.zip
Working well for my machine, thanks Luke!
On 28 May 2015 at 07:05, lpinner notifications@github.com wrote:
Yep, I think that’s it. I was able to artificially reproduce by filling the stderr buffer up. The above commit should fix it. Can you try the version at https://bintray.com/artifact/download/lukepinnerau/generic/YARDWiz-1.1dev-2-win32setup.zip
— Reply to this email directly or view it on GitHub https://github.com/lpinner/yardwiz/issues/43#issuecomment-106075064.
If I enable quick listing, the titles and dates are all listed, but when YARDWiz starts listing the details, it gets through about a dozen before hanging, always after the same entry. It just keeps saying "Connecting..." with the progress bar moving, but nothing else is ever loaded. At this point, "Delete" is greyed out on the context menu, and if I try to download anything, the actual download never starts.
If I disable quick listing, YARDWiz just lists the details of a dozen entries before hanging the same way.
I should probably mention that I deleted a large number of recordings using YARDWiz. (I can't re-index because my Beyonwiz's remote control functions no longer work. Network access is my only access.)
Edited YARDWiz debug log follows:
For what it's worth WizZilla gives lots of errors for the deleted shows like this: