live script gives error
Status: Alpha
Brought to you by:
elfman09
Menu
▾
▴
#1 live script gives error
When I run example_live.sh, I get the following output:
You must have mplayer installed for this to work (http://mplayerhq.hu)
MPlayer 1.0rc2-4.3.3 (C) 2000-2007 MPlayer Team
CPU: Genuine Intel(R) CPU T2500 @ 2.00GHz (Family: 6, Model: 14, Stepping: 8)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing -.
Reading from stdin...
Cache fill: 0.00% (0 bytes) Bind successful! recv() possible...
Sending Init and video start request to 192.168.1.111
Cache fill: 0.00% (0 bytes) Ack status: -2 (1=success)
Cache fill: 0.00% (0 bytes) Ack status: -2 (1=success)
Win32 LoadLibrary failed to load: avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll
Exiting... (End of file)
-----------------------
I'm attaching my shell script in case I incorrectly entered the parameters.
Thanks,
Michael
example_live.sh
A few questions...
Which version are you using? alpha3? built from svn? You don't happen to be building building from scratch on Vista with cygwin are you?
The mplayer dll loads indicate windows but... the example_live.sh script is for linux while the example_live.cmd script is for windows (In alpha3 I though I only packaged platform appropriate scripts)
On windows, you probably will need a net stop havasvc (see the cmd script) to stop monsoon's service that binds to port 1778
Vista has some issues we tracked down in alpha3 that allow multiple apps to bind to the same port by default but not to work correctly to receive. (worked fine on XP) see setsockopt in hava_util.c which I currently only enable when compiling with visual studio (make windows)
not sure if I should document around this or try to resolve another way...
Alpha3 binaries on Linux - I did not build from SVN.
I read that the dll error is misleading as mplayer sometimes gives that error for a reason unrelated to the error message.
interesting. so that throws one theory out the window.
Every ~1sec the hava sends out a 300byte broadcast. If we get a certain number of these in a row without getting the "proper" response to the initialize stream requests, we timeout with an error -2.
Bind successful! recv() possible...
Sending Init and video start request to 192.168.1.111
Ack status: -2 (1=success)
Ack status: -2 (1=success)
To start the video we send two messages. an init message and a "start stream" message. You're getting a -2 on both. This means you are not getting back the 336 byte response to the initializer for some reason. I am attaching a debug version that dumps some diagnostics.
can you run hava_record 192.168.1.111 0x00 10 a.mpg 2>a.err
(the syntax has changed a bit since alpha3 a new parameter has been added)
and upload a.err
oops, forgot to log in and posted that as nobody. test hava_record is uploaded now.
also, can you say anything about the model and firmware version of hava that you have?
a.err
Uploaded the file... I have a Hava Wireless HD, with the latest firmware that has been out for a while. I can't get the exact firmware version right now, but can later if you need it.
Thanks
Wireless HD is the same as mine. Your firmware is probably close to mine to (from about april if I remember correctly).
Okay, you are not getting a response from Hava to the first initialize packet. It doesn't look to be a firewall issue because you do get a response to the second packet that I send.
The UDP protocol Hava uses sometimes loses packets and I am not yet doing much by way of loss detection/correction because packet loss is so rare on local network. It is odd that you seem to always lose that first packet though. We only saw similar behavior on Vista when two apps bound to the same port.
I am attaching a new debug version that repeats initialization if it fails. It will either get a bit further or get stuck in a loop trying to initialize and you will have to kill it. In either event, please attach a.err.
While it is running can you in another terminal window run "netstat -a -n | grep 1778" to see if anything else might be trying to conflict on the port.
debug record #2
a.err #2
Attached the new debug output. Also, ran netstat command, and got the following:
udp 0 0 0.0.0.0:1778 0.0.0.0:*
Thanks
sigh. So it is not a udp anomoly; we're just not getting a response. This could mean one of a number of things, the most likely of which is that we will need a packet capture when you connect to Hava with windows and a customized initialization packet. I find this a bit odd since a number of other folks are doing okay with this initialization packet (which is used for channel changing which is getting a fair amount of users).
Before we get into how to do packet capture, can you try to run the windows version of alpha3 the windows box that you use to configure Hava? To do this you will need to exit from the Hava player or wizard if they are running, run "net stop havasvc", then run first "hava_info.exe" then "hava_record.exe 192.168.1.111 10 a.mpg". If they report -2 also then I am fairly confident that we'll need to do the packet capture. If either succeeds, we might have a linux anomoly to deal with.
If both windows tests fail, a few questions to try to understand how your setup differs from mine: Is your hava connected to your home network via wired connection (mine is) or are you using the wireless feature? Which input connection on the Hava do you use? Composite, Svideo, Component? It might also be a good time to verify your firmware version. Mine is hardware version 1003100 with firmware 270.322-32.