[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AG-TECH] Not finding Firewire DV on UQ advanced vic



On 5/27/07, Christoph Willing <willing@xxxxxxxxxxxxxxxx> wrote:

On 26/05/2007, at 7:57 AM, Andrew Ford wrote:

> Thanks Chris, sending DV seems to work fine now. The problem now is
> that when I try and receive it (on another machine) the receiving
> vic hard freezes (there's the listing for the video with a black
> thumbnail, and the window is completely frozen - I have to kill the
> process to stop it). I'll attempt to leave the stream sending (to
> RIT's AG multicast video address, 224.2.224.225/20002) over the
> weekend, so if anyone could try receiving it, that would be awesome.

Andrew,

I don't see any multicast traffic on that address - maybe you've
stopped sending, or perhaps a highter ttl is needed?


chris

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). Is there any other good way to check multicast traffic on an address?

On 5/27/07, leon zadorin <leonleon77@xxxxxxxxx> wrote:
On 5/26/07, Andrew Ford <acf0659@xxxxxxx> wrote:
> Thanks Chris, sending DV seems to work fine now. The problem now is that
> when I try and receive it (on another machine) the receiving vic hard
> freezes (there's the listing for the video with a black thumbnail, and the
> window is completely frozen - I have to kill the process to stop it). I'll
> attempt to leave the stream sending (to RIT's AG multicast video address,
> 224.2.224.225/20002) over the weekend, so if anyone could try receiving it,
> that would be awesome.

Hello Andrew,

Firstly - thanks for spending some time with our software - I
certainly appreciate it :-)

No problem :) integrating DV & HDV into vic is a huge advantage for us.

Secondly, I was wondering if the following commands could be executed
on the machine which is having troubles receiving DV stream:

a) quit the receiving vic

b) run the following commands:

cat /var/log/dmesg > leonlog1
dmesg >> leonlog1
cat /proc/cpuinfo >> leonlog1
cat /proc/meminfo >> leonlog1
/sbin/sysctl net.core.rmem_max >> leonlog1
grep -i driver /etc/X11/xorg.conf >> leonlog1
xvinfo >> leonlog1
glxinfo >> leonlog1
./vic YOUR-IP/PORT >> leonlog1 2>&1

then (without killing vic) open another terminal and run:
top -b -n 5 > leonlog2

After top has exited (will take ~15 seconds), just email me all of the
"leonlog1/2" files... this, I hope, will give me more info about your
receiving machine's setup... (I presume you are able to see the DV
stream from the transmitting vic [on the transmitting machine] ?)

Logs are attached. Also, yeah, I can see the DV stream in the sending vic window, but if I run 2 copies on the same machine (pointing at the same address), both sending streams (I tried X11 on one and DV on the other), neither can see the other's stream. Not sure if that's normal or not.

Also, which revision of vic are you running?
To find out, cd to the sources ( e.g. cd ag-media) and then run
svnversion
it will tell you the revision number(s) information of your local source tree...

Both the sender and receiver are 91M; they're from checkouts I did on Thursday/Friday.

--Andrew


Attachment: leonlog1
Description: Binary data

Attachment: leonlog2
Description: Binary data