> Hmm, it seemed to be sending fine when I got in today implying that it was
> running over the (long) weekend. I restarted it with a higher TTL, and I'll
> try and keep it running as much as I can (I can guarantee 10am EDT - 6pm
> EDT, sorry that that's an awful time for you guys in Australia, heh).
Well, some news...
Firstly, I am able to receive and see your stream here in Birsbane,
Australia :-) ... Although the whole thing is rather dark - but I
presume that it is nighttime over in NY (it is noon here :-) and there
are no lights "on" in your office :-)
Great! Glad to know it's working, thanks. I guess if you want to see some activity or light you should try checking it earlier in the morning, like 8am-11am your time which is 6pm-9pm here, while it's still light outside. I'll point it out a window before i leave :)
> Both the sender and receiver are 91M; they're from checkouts I did on
> Thursday/Friday.
91M - the "M" part is interesting, what does
cd ag-media
svn diff >> leonlog3
say? Basically, the "M" means modified... it could be nothing (e.g.
there are some runtime generated files which should not be a part of
svn repository), but it would be interesting to see anyway (i.e. if
possible, email me the leonlog3 file)...
The only difference is a #define of the svn revision number in an ffmpeg revision file:
Index: Ffmpeg/Revision6182/version.h
===================================================================
--- Ffmpeg/Revision6182/version.h (revision 91)
+++ Ffmpeg/Revision6182/version.h (working copy)
@@ -1 +1 @@
-#define FFMPEG_VERSION "SVN-rUNKNOWN"
+#define FFMPEG_VERSION "SVN-r91"
Not sure how that happened but it doesn't seem to be affecting anything.
Now on to your system/logs :-) ... thanks for the log files by the way!
From leonlog1:
"libGL warning: 3D driver claims to not support visual 0x4b"
This could mean that your system is having issues with OpenGL (we use
OpenGL by default for efficient synchronisation with the vertical
refreshing of your monitor) so try running vic with "-g" option:
./vic -g IP/PORT
I was trying the ./runDV script before, so I was already using -g. (I just tried it with only -g and the same freezing happened)
This will instruct the vic not to use OpenGL for syncing to VBlank (so
in case it was OpenGL issue that made vic "pause" and wait
indefinitely for a vertical retrace - it will be avoided this time)...
Minor side-note: it appears that you are using an Intel graphics card
with i810 driver - this combination will not have proper accelerated
rendering (XVideo's "Overlay" is not sufficient, we need "Blitter" or
"Texture" and even then, the newest intel drivers are still rather
"slowish")...
... current recommended setup would be nvidia card with "nvidia" [
binary / closed-source ] Xorg driver - something as per
http://www.vislab.uq.edu.au/research/accessgrid/software/advideo/system_characteristics.html
Yeah, I had a feeling it might have to do with the lack of a decent video card in this machine.
Without the XVideo accelerated rendering vic should fallback to Imlib2
(software) rendering... but from log files I don't see it using Imlib2
rendering though... (vic would output something like "using Imlib2 for
rendering" or similar) - this could mean that the runtime execution
path did not get around to it or that Imlib2 was not included in the
build...
what does
cat ag-media/vic/IMLIB2INCLUDE.H >> leonlog3
say?
#include "../Imlib2/Installed/include/Imlib2.h"
And that is a valid path.
>From leonlog2: Minor side-note: you have 2 vics running (one of them
is listed as defunct) so *really* killing it (kill -KILL PID) would be
a good thing to try... if this does not help and you end up restarting
the machine, then please run the "setSystem" script again (so that
/sbin/sysctl net.core.rmem_max shows ~17000000 value)
I just had to kill the original ./runDV script, that got rid of it. Didn't make a difference with the freezing, though.
If running vic with "-g" option does not help, try
./vic -g -i -x IP/PORT
and then (if possible) click on the black thumbnail to see if the
larger video window comes up... this is not a deployment solution, but
would help with testing...
Hmm, this actually works... but in a strange way. Sometimes, if I leave the main window open and visible for too long (5ish seconds sometimes, this part is inconsistent), it freezes. (Sometimes it doesn't freeze at all) But before it freezes, I can open the video windows (which are receiving the videos fine) by clicking on the thumbnails. If the main vic window is visible/frozen (and trying to render I presume?) the video windows keep on displaying fine but they can't process any input (like s/m/l for resizing). If the main vic window is not frozen, the windows can process input just fine. Occasionally the main window thaws if I leave it open long enough.
Oh and I wouldn't worry about 2 vics running on the same machine,
using the same class D (multicalt) address and not seing each others
traffic - I think this is OK (i.e. by design this was never an
intended scenario - in fact the original vic (from anl) behaves in
exactly the same way - so we have inherited this behaviour)...
Ah, that's what I thought. Thanks for the clarification.
--Andrew