From breuer.jens at googlemail.com  Wed Dec  9 11:29:11 2009
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Wed, 9 Dec 2009 11:29:11 +0100
Subject: [Udpcast] Missing Kernel Config & USB Memory Stick Probs
Message-ID: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>

Hello List,
hello Alain,

I recently wanted to download the current udpcast-kernel .config but
the link on the Homepage returns 404 for me:
http://udpcast.linux.lu/download/udpc-config-2.6.32-rc5.txt

Additionally, I wanted to test some stuff with a USB-Memory-Stick but
I could not manage to mount the filesystem (fat32) on the stick. I did
not even see messages in dmesg regarding the stick being connected. I
tried to test with a nonmodified udpcast-cd-image.
I fear that this problem is not related to udpcast-framework but
rather related to missing kernel or other framework features. However,
after googling I am still none the wiser. I hope that someone can show
me the right direction on where to investigate, so I can have full
USB-Memory-Stick support.

Thanks & Regards
Jens


From alain at knaff.lu  Wed Dec  9 13:42:02 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 09 Dec 2009 13:42:02 +0100
Subject: [Udpcast] Missing Kernel Config & USB Memory Stick Probs
In-Reply-To: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>
References: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>
Message-ID: <4B1F9B1A.5040207@knaff.lu>

On 09/12/09 11:29, Jens Breuer wrote:
> Hello List,
> hello Alain,
> 
> I recently wanted to download the current udpcast-kernel .config but
> the link on the Homepage returns 404 for me:
> http://udpcast.linux.lu/download/udpc-config-2.6.32-rc5.txt

It's now up.

> Additionally, I wanted to test some stuff with a USB-Memory-Stick but
> I could not manage to mount the filesystem (fat32) on the stick. I did
> not even see messages in dmesg regarding the stick being connected. I
> tried to test with a nonmodified udpcast-cd-image.

And, what was the outcome?

> I fear that this problem is not related to udpcast-framework but
> rather related to missing kernel or other framework features. However,
> after googling I am still none the wiser. I hope that someone can show
> me the right direction on where to investigate, so I can have full
> USB-Memory-Stick support.
> 
> Thanks & Regards
> Jens

It more looks like a problem with the USB chipset module (uhci-hcd) than
the VFAT or fat32 module

Regards,

Alain


From breuer.jens at googlemail.com  Thu Dec 10 07:55:17 2009
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Thu, 10 Dec 2009 07:55:17 +0100
Subject: [Udpcast] Missing Kernel Config & USB Memory Stick Probs
In-Reply-To: <4B1F9B1A.5040207@knaff.lu>
References: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>
	<4B1F9B1A.5040207@knaff.lu>
Message-ID: <76ce20420912092255m606382cdk311a5a095f9f9139@mail.gmail.com>

On Wed, Dec 9, 2009 at 1:42 PM, Alain Knaff <alain at knaff.lu> wrote:
> On 09/12/09 11:29, Jens Breuer wrote:
>> Hello List,
>> hello Alain,
>>
>> I recently wanted to download the current udpcast-kernel .config but
>> the link on the Homepage returns 404 for me:
>> http://udpcast.linux.lu/download/udpc-config-2.6.32-rc5.txt
>
> It's now up.
Thank you. :)

>> Additionally, I wanted to test some stuff with a USB-Memory-Stick but
>> I could not manage to mount the filesystem (fat32) on the stick. I did
>> not even see messages in dmesg regarding the stick being connected. I
>> tried to test with a nonmodified udpcast-cd-image.
>
> And, what was the outcome?
The stick has not been recognized by the kernel, I think. At least
nothing showed up in the logs and "fdisk -l" did not show anything.
Yes, that is not really helpful information but I will test more and
share my results with you.

>> I fear that this problem is not related to udpcast-framework but
>> rather related to missing kernel or other framework features. However,
>> after googling I am still none the wiser. I hope that someone can show
>> me the right direction on where to investigate, so I can have full
>> USB-Memory-Stick support.
>
> It more looks like a problem with the USB chipset module (uhci-hcd) than
> the VFAT or fat32 module
Ok, I am going to investigate things from this point of view first. I
had the feeling that I needed something like hotplug or related stuff.
However, I am not a Kernel-Guru so I depend on the expertise of people
who know more than I do and hopefully you put me into the right
direction.

Thanks & Regards
Jens


From alain at knaff.lu  Tue Dec 15 13:56:02 2009
From: alain at knaff.lu (Alain Knaff)
Date: Tue, 15 Dec 2009 13:56:02 +0100
Subject: [Udpcast] Missing Kernel Config & USB Memory Stick Probs
In-Reply-To: <76ce20420912092255m606382cdk311a5a095f9f9139@mail.gmail.com>
References: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>	<4B1F9B1A.5040207@knaff.lu>
	<76ce20420912092255m606382cdk311a5a095f9f9139@mail.gmail.com>
Message-ID: <4B278762.60601@knaff.lu>

Found out what is going on:

- in newer kernels, you need to load an additional modules (ums-*.ko) for
many USB storage devices. In older kernels the device-specific
functionality in these modules used to be part of usb-storage, now it is a
separate module. So you need to manually modprobe that module as well.

- The dialog of "disk controller modules" only proposes PCI or on-board
devices (mostly for SCSI and SATA), but not USB...

- ... however the creation of the device nodes (/dev/sda*, /dev/sdb*) is
only performed if a disk controller module has been selected



So, for now, the workaround is:

- manually modprobe the appropose ums-*.ko module:

    modprobe ums-cypress.ko

 It may fail on first attempt (due to a weird kernel or busybox bug), in
that case, just try again.

- enter the "disk controller module", and pick your PATA or SATA controller
(you need to pick something, or else no device nodes will be created, even
though the actual module has already been loaded manually)

- near the end, /dev/sdb should appear (/dev/sda being the built-in disk)


For the next release, I'll change it such that now the ums* modules also
show up in the list of disk controller modules, and that device nodes are
created unconditionally.

Regards,

Alain


From alain at knaff.lu  Wed Dec 30 00:30:31 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 30 Dec 2009 00:30:31 +0100
Subject: [Udpcast] unicast with async
In-Reply-To: <22efa0550901261827s34eec00cr9f599465f983cceb@mail.gmail.com>
References: <22efa0550901231050l24d2276cn872fbb0d2cd6a68f@mail.gmail.com>	
	<497E3E68.2060803@knaff.lu>
	<22efa0550901261827s34eec00cr9f599465f983cceb@mail.gmail.com>
Message-ID: <4B3A9117.2010307@knaff.lu>

Justin Lipman wrote:
> Yep. Thanks for the reply Alain.
> That assumes the back channel is not a human supplying the info. ;-)
> 
> Is there a way to override this and provide the necessary receiver
> info/registration?
> Or do I need to modify the source?
> 
> Cheers,
> J

Not sure whether I mentioned this already, but you could always start up
udpcast as follows:

  udp-sender --async --mcast-data-addr 10.0.0.2

i.e. specifying a unicast address as multicast.

Regards,

Alain

> 
> On Tue, Jan 27, 2009 at 6:51 AM, Alain Knaff <alain at knaff.lu> wrote:
> 
>> Justin Lipman wrote:
>>> Hi folks,
>>> I'd like to use udp-sender with async and a unicast address instead of
>>> multicast so that unicast at the MAC layer is actually used.
>>> Ive tried using the pointopoint switch, but I get the message
>> "pointopoint
>>> mode set, and 0 participants instead of 1".
>>>
>>> Is there a way to do this with udpcast?
>>>
>>> Thanks kindly.
>>> J
>> This is to be expected. Pointopoint only works if the receiver is known;
>> however that is only possible if he may register with the sender.
>>
>> Async on the other hand means that there is no back channel by which the
>> receiver may make itself known to the sender
>>
>> Regards,
>>
>> Alain
>>
> 



From alain at knaff.lu  Wed Dec 30 22:54:53 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 30 Dec 2009 22:54:53 +0100
Subject: [Udpcast] Udpcast for streaming data.
In-Reply-To: <4A9E46B1.7040307@enigma.det.uvigo.es>
References: <4A673FFC.2090609@enigma.det.uvigo.es>	<4A6D9D6B.90205@knaff.lu>	<4A9D957C.4090509@knaff.lu>	<4A9E2DC3.1040404@enigma.det.uvigo.es>
	<4A9E46B1.7040307@enigma.det.uvigo.es>
Message-ID: <4B3BCC2D.8050507@knaff.lu>

Jorge Muñoz Castañer wrote:
> Jorge Muñoz Castañer escribió:
>> Alain Knaff escribió:
>>   
>>> Alain Knaff wrote:
>>>   
>>>     
>>>> On 07/22/09 18:36, Jorge Muñoz Castañer wrote:
>>>>     
>>>>       
>>>>> Hi list,
>>>>>
>>>>> I was looking for a tool to send a stream of data with FEC where the 
>>>>> client/receiver can connect even if the stream has yet begun. I haven't 
>>>>> found anything but Udpcast that can do anything similar. I think that 
>>>>> maybe an "streaming" option can be added so the sender sends Hello 
>>>>> packets at the end of a block of slices+FEC so a receiver can hook to 
>>>>> the UDP stream.
>>>>>
>>>>> What do you think about this? Can this be made modifying Udpcast without 
>>>>> broken it all? Is there another software that I can use?
>>>>>
>>>>> Greetings,
>>>>>
>>>>> Jorge M
>>>>>
>>>>>       
>>>>>         
>>>> Sounds like a good idea. I'll consider adding this for the next version.
>>>>
>>>> Regards,
>>>>
>>>> Alain
>>>>     
>>>>       
>>> I just released version 20090830, which has support for this idea.
>>>
>>> You can now add a special flag (-Z or --streaming) to the sender, which
>>> makes it retransmit HELLO packets during the transmission, which
>>> receivers can then use to "jump onto" the ongoing transmission.
>>>
>>> Regards,
>>>
>>> Alain
>>>
>>> _______________________________________________
>>> Udpcast mailing list
>>> Udpcast at udpcast.linux.lu
>>> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>>>   
>>>     
>> Hi Alain,
>>
>> Sounds great! Thanks Alain. I'll test it and tell you anything.
>>
>> Jorge M
>>
>>   
> Hi again,
> 
> It works great. We are using UDPCAST to send multimedia data that can be 
> played from any point of the stream so the "streaming" option is very 
> near of what we need. We also use the Asynchronous mode in order to 
> avoid great latency.
> 
> There may be another functionality that can be useful with this option. 
> If the FEC correction is not enough to correct a slice udp-receiver 
> stops. This is useful when you are transmiting data files where there 
> must be integrity, but in most multimedia streamings it is not very 
> important to loss a small percentage of packets. Can I suggest a 
> "multimedia" option which keeps udp-receiver active even if there are 
> unrecoverable slices?. These slices can be marked as "no recovered" in 
> the receiver slices queue and are not written in the output file or 
> fifo. What do you think?
> 
> Regards,
> 
> Jorge M
> 

This feature is now supported via the new --ignore-lost-data flag on
udp-receiver in 20091230.

If this flag is supplied, lost blocks do not stop the transmission, but
instead are filled with "random" data.

Regards,

Alain



From alain at knaff.lu  Wed Dec 30 22:56:13 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 30 Dec 2009 22:56:13 +0100
Subject: [Udpcast] Network card Error
In-Reply-To: <F9652F31-766B-42EB-B06A-BCC8CC1CF782@hatsize.com>
References: <78C50AF9-6F40-419C-B720-5EE561223344@hatsize.com>	<48D95937.8050200@knaff.lu>	<8FB4AF77-8D57-46F7-B6B3-124020444FAB@hatsize.com>	<D58A2352-C9A6-4F73-AA4A-6DE5A749D52B@hatsize.com>	<26A58433-CFBC-47A3-B515-892BAC920E83@hatsize.com>
	<F9652F31-766B-42EB-B06A-BCC8CC1CF782@hatsize.com>
Message-ID: <4B3BCC7D.9070109@knaff.lu>

Darin MacLachlan wrote:
> think i might have found the issue
> It looks like the number of virutal IPS is more that the udpsender can  
> handle.
> I have removed all the virtual IP addresses from eth2 and now the  
> sender will activate on eth3.
> 

In udpcast 20091230, this limit is now gone. It now supports an
unlimited number of network interfaces.

Regards,

Alain


From alain at knaff.lu  Wed Dec 30 23:02:59 2009
From: alain at knaff.lu (Alain Knaff)
Date: Wed, 30 Dec 2009 23:02:59 +0100
Subject: [Udpcast] Missing Kernel Config & USB Memory Stick Probs
In-Reply-To: <4B278762.60601@knaff.lu>
References: <76ce20420912090229u575efecer2d5bf7db01138ce6@mail.gmail.com>	<4B1F9B1A.5040207@knaff.lu>	<76ce20420912092255m606382cdk311a5a095f9f9139@mail.gmail.com>
	<4B278762.60601@knaff.lu>
Message-ID: <4B3BCE13.5040005@knaff.lu>

Alain Knaff wrote:
> For the next release, I'll change it such that now the ums* modules also
> show up in the list of disk controller modules, and that device nodes are
> created unconditionally.
> 
> Regards,
> 
> Alain

This is now supported in 20091230

Regards,

Alain


From jorgem at enigma.det.uvigo.es  Thu Dec 31 02:18:31 2009
From: jorgem at enigma.det.uvigo.es (=?ISO-8859-1?Q?Jorge_Mu=F1oz_Casta=F1er?=)
Date: Thu, 31 Dec 2009 02:18:31 +0100
Subject: [Udpcast] Udpcast for streaming data.
In-Reply-To: <4B3BCC2D.8050507@knaff.lu>
References: <4A673FFC.2090609@enigma.det.uvigo.es>	<4A6D9D6B.90205@knaff.lu>	<4A9D957C.4090509@knaff.lu>	<4A9E2DC3.1040404@enigma.det.uvigo.es>	<4A9E46B1.7040307@enigma.det.uvigo.es>
	<4B3BCC2D.8050507@knaff.lu>
Message-ID: <4B3BFBE7.4050306@enigma.det.uvigo.es>

Alain Knaff wrote:
> Jorge Muñoz Castañer wrote:
>   
>> Jorge Muñoz Castañer escribió:
>>     
>>> Alain Knaff escribió:
>>>   
>>>       
>>>> Alain Knaff wrote:
>>>>   
>>>>     
>>>>         
>>>>> On 07/22/09 18:36, Jorge Muñoz Castañer wrote:
>>>>>     
>>>>>       
>>>>>           
>>>>>> Hi list,
>>>>>>
>>>>>> I was looking for a tool to send a stream of data with FEC where the 
>>>>>> client/receiver can connect even if the stream has yet begun. I haven't 
>>>>>> found anything but Udpcast that can do anything similar. I think that 
>>>>>> maybe an "streaming" option can be added so the sender sends Hello 
>>>>>> packets at the end of a block of slices+FEC so a receiver can hook to 
>>>>>> the UDP stream.
>>>>>>
>>>>>> What do you think about this? Can this be made modifying Udpcast without 
>>>>>> broken it all? Is there another software that I can use?
>>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> Jorge M
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>             
>>>>> Sounds like a good idea. I'll consider adding this for the next version.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alain
>>>>>     
>>>>>       
>>>>>           
>>>> I just released version 20090830, which has support for this idea.
>>>>
>>>> You can now add a special flag (-Z or --streaming) to the sender, which
>>>> makes it retransmit HELLO packets during the transmission, which
>>>> receivers can then use to "jump onto" the ongoing transmission.
>>>>
>>>> Regards,
>>>>
>>>> Alain
>>>>
>>>> _______________________________________________
>>>> Udpcast mailing list
>>>> Udpcast at udpcast.linux.lu
>>>> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>>>>   
>>>>     
>>>>         
>>> Hi Alain,
>>>
>>> Sounds great! Thanks Alain. I'll test it and tell you anything.
>>>
>>> Jorge M
>>>
>>>   
>>>       
>> Hi again,
>>
>> It works great. We are using UDPCAST to send multimedia data that can be 
>> played from any point of the stream so the "streaming" option is very 
>> near of what we need. We also use the Asynchronous mode in order to 
>> avoid great latency.
>>
>> There may be another functionality that can be useful with this option. 
>> If the FEC correction is not enough to correct a slice udp-receiver 
>> stops. This is useful when you are transmiting data files where there 
>> must be integrity, but in most multimedia streamings it is not very 
>> important to loss a small percentage of packets. Can I suggest a 
>> "multimedia" option which keeps udp-receiver active even if there are 
>> unrecoverable slices?. These slices can be marked as "no recovered" in 
>> the receiver slices queue and are not written in the output file or 
>> fifo. What do you think?
>>
>> Regards,
>>
>> Jorge M
>>
>>     
>
> This feature is now supported via the new --ignore-lost-data flag on
> udp-receiver in 20091230.
>
> If this flag is supplied, lost blocks do not stop the transmission, but
> instead are filled with "random" data.
>
> Regards,
>
> Alain
>
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>   
That's great! Thanks, Alain, for your effort.

Happy new year to  you  and all the community,

Jorge Muñoz

-- 
---------------------------------------
         Jorge Muñoz Castañer
     e-mail: jorgem(en)det.uvigo.es
  Grupo de Tecnologías de la Información
   Departamento de Ingeniería Telemática
           Universidad de Vigo
          ETSI Telecomunicación
         Campus 36310 Vigo SPAIN
----------------------------------------