Re: Ez Grabber 2 Driver Windows 7
Edelira Longinotti
After installing "MAGIX Video easy Rescue Your Videotapes!" via a physical DVD in a box (marked MAGIX Rescue Your Videotapes!) as purchased from Magix Software's website, I am having trouble with getting the drivers to install for the included K0065 video capture device, and no device is listed in the programme after selecting "Import video from analogue source".
I have Windows 10 64-bit installed, and the above programme installed to the 64-bit program directory. Following installation, the drivers were installed (and I held off connecting the K0065 until prompted by the installer), but the drivers do not seem to be installed fully.
After looking over this forum, this seems to have popped up now and then with reference to the wrong bit type of driver being installed, but without any conclusion. A screenshot of my Device Manager is here, along with the error I get if I try to use "Update Driver" and point Windows into the \addon\Driver folder on the DVD (the same error shows when selecting either the x86 folder or the x64 one.)
There are many drivers out there for the black unit but not as many for the red and white. This thread may help you; I am about to try some of these options. But I am close to returning this thing to the store; I wanted something to save time not waste it! -rescue-your-video-tapes-doesn-t-recognise-vcr--1167887/#ca1462935
Need help. Same issue here with K0065 (black stick). Just received from mail. I have installed according to Magix instructions but the driver was not working (Code 28). I have tried to uninstall and then reinstalled the whole software without any result. I have also tried to uninstalled only the video grabber driver and reinstall the 64 bit driver from the CD but no luck. On the Windows 10 Privacy policy for Microphone and Camera were both options on "Allow" but the software "MAGIX Video easy Rescue Your Videotapes!" app was not listed for the allowed apps to use the Microphone and Camera. Please see the attached.
I am struggling with the same problem(s).
The error I get 'A problem was encountered while attempting to add the driver to the store'. It could be that the device driver is not signed, and the Internet suggests 'BCDEDIT /set nointegritychecks ON' on a administrator CMD window, but my PC now (W10 update 1903) says it has a secure start-up strategy and this cannot be changed. Any suggestions?
Hi John,
Some updates:
1. I got a package (french version) of RYVT (version 6.0.2.31 (UDP3) after an update. While it does install into Program Files (so the 64bit version), it does lanch an X86 version for drivers.
2. The analog2USB dongle is a K0065 black device.
3. The device is the one from the CD.
4. I had the windows privacy / folder protection settings already to 'off' as suggested here.
When I start from scratch and plug in the dongle, two 'new' devices appear in the device manager. One pilot installs as 'Magic Video Converter 3'. The other driver does not install. Windows signals an error 'the driver cannot be added to the store'. The BCDEDIT doesn't work anymore, but there is a means to install an unsigned device driver. That allows to install the (apparently unsigned) driver on the CD.
I could not install the driver for K0065 based on the original CD. The Windows Defender is superseded by BitDefender TS. Thus, the folder protection was handled by BitDefender. I have tried to put those folders unprotected and reinstall the video grabber' driver with the same unfortunate result.
However, I have followed @koen44 thread and installed the "Treiber Premium Wandler" from Magix (with upgrade option). The driver install went through without any workaround and there were no more errors on Device Manager (attached).
Yes, I have change it from NTSC to PAL and did not get the video feed. Then I opened the import option from File and select the video grabber. This time I had the video feed. After restarting the RYVT it went normal. The export was in PAL.
In Windows 95, I was the one responsible for the grabbers, and I made some improvements to text rendering performance, and a lot of improvements to graphics rendering performance. In particular, Windows 3.1 could not run graphical MS-DOS programs in a window, but Windows 95 could: The video driver folks were able to improve graphics virtualization, and my optimizations for graphics rendering made it possible to re-render the screen contents in real time.
Right. I remember running GEM 1.0 in a Window under Windows 3.1. It was possible selecting the CGA video driver, which meant that GEM ran at 640200, in monochrome, with those hideous 1:2 pixels. And, of course, it required a screen resolution of at least 800600. But it definitely did run.
What Windows 95 did was to add support for EGA and VGA modes (640200, 640350 and 640480 at 16 colors, and 320200/240 at 256 colors) in windowed mode. Maybe Raymond worked on the EGA and VGA grabbers, and his recollections come from that.
Sounds interesting, will try it within the next days.
However I already see a problem. This grabber sends the captured information via network to hyperion, this means, depending on your network configuration, the ambilight will have a very noticeable lag.
At the moment I am using the AVR -> splitter+converter+usb-grabber -> RPi method and also have a lag, although very little and thus tolerable. But nothing compared to when the content is grabbed directly on the Raspberry Pi.
So my question is, would it be possible to develop a grabber that sends the information via a usb interface instead of via network? I reckon that would be a lot faster. Please bear in mind that I am by no means a developer and can not estimate realisability or required effort.
Another solution would be to run hyperion directly on windows and send the information for the lights to the Pi via usb which only converts them to the SPI interface.
I know something like this is possible with an arduino, however i then would not have philips hue support and would need additional hardware. That is why I like Hyperion.
Well technically it doesn't have to be a slave. Right now the pi gets the grabbed videostream via a USB connection from the usb-grabber. If it would be possible to have a screengrabber that grabs the display output directly in windows and pushing it out via USB all the splitter/converter/grabber peripherals would become obsolete and you would have a digitally grabbed signal which should be more accurate in colour and resolution compared to analog. However I don't know if this is possible at all. I guess the Windows grabber program would need to register as a grabbing device via that specific usb connection on a specific usb port of the windows pc in order to get recognised by OS of the Pi. But again, this is all hypothetically as I am not a developer and only have rudimentary knowledge of software programming.
To have a windows port of hyperion would be very nice. Preferably with the support to use an arduino to control the leds. This way everything, given that the windows grabber works, can be grabbed digitally, processed directly on the machine and then pushed out to the LED devices, e.g. light strip, philips hue, etc.
That would mean very low latency, except for an arduino to control the leds no additional hardware and more accurate colours.
From my experience with network transfer of frames (the hyperion forwarder) network is fast enough for this task. Important is to scale down the captured frames like e.g. the hyperon-x11 grabber does.
I built my Hyperion Ambilight yesterday and got it working so far with the USB grabber, but colors are wrong pretty often. And since I use an ultra widescreen its not gettin any better.
This little tool has very accurate colors out of the box.
Working here on Windows 10 x64 so should work (GTX1080 + 368.39 drivers):) , on multi monitor setups you do have to supply the monitor index if the screen you are capturing is not the first one (primary).
Also make sure to use the latest build:
I finally got the x11 grabber working. But it is stuttering. Not like it is behind what is shown on the screen, but it seems like it drops frames. I tried 60fps ands 120fps. Same result. width and height are both 64 pixels, any other value doesn't work at all. I guess it ist just my network configuration. I use a wired access point that connects to the router which handles HDCP and NAT. So the whole route of the data package is: PC -> AP -> Router -> AP -> Switch -> RPi
Thats a shame since the colour reproduction was better with the windows grabber. But the stuttering kills it for me
Oh yeah, DHCP HDCP was for the copyright protection :facepalm:
Just did a ping from my laptop that is connected via wifi to another access point in the house and had an average ping of 16ms on 10 pings. So I guess you are right. But what could it be? My understanding is, that hyperion runs my normal grabber config, but because the windows grabber sends packages to the json/proto server with a lower priority channel, hyperion uses that information instead of the usb grabber input right? Smoothing etc comes after that? Because it somehow looks like it is a lower framerate without smoothing. Another thing I could try is to comment out the whole grabber part. Maybe that interferes somehow.
I should use old frame grabber PCI-1409 in new PC, because the old one was broken. So I installed PCI-1409 and almost every NI drivers (MAQmx, VISA and Vision Acquisition Software), but it does not contain a driver for PCI-1409 even though NI-MAX recognize it, as a screenshot below.
I followed the guide ( =kA00Z0000019PFISA2), but it did not work. I tried to find a driver in NI's FTP server, but it is too messy. How can I find a driver for PCI-1409 and install it? I hope NI does not stop providing a driver for legacy boards.
I ordered EasyCap, but it does not work on windows 10. I found driver for windows 10 online, but it didn't work. Someone knows how could I solve this problem? The device is recognized as an audio device also after I installed the driver.Thank you very much.
aa06259810