8 Feb
2007
8 Feb
'07
7:51 p.m.
Hello group, This is my first post and wanted to thank everyone and the
author(s) for their hard work.
I work in the broadcast industry and have been developing Datacast
solutions for KET. Well, after seeing this project I realized that this
could replace our propitiatory software. The only hurdle is to be able
to throttle the output on demand, as the one- way stream and forward
error correction system has been implemented. I will get details on the
throttling procedures for the group if anyone is interested. The
hardware that it needs to talk to is a Logic Innovations IPE (IP
Encapsulator) that embeds the IP traffic in the 19.39 Mbit data stream.
I can give more info on request.
David Crider
Special Projects Engineer
Kentucky Educational Television
Alain Knaff wrote:
Jens Breuer wrote:
Hello List,
Hello Alain,
thank you for implementing the feature in the current version.
Unfortunately I have to second what Gunner said as it seems that this
new feature introduced a weird behaviour.
I just tested the new version. I had my initrd build by cast-o-matic
and specified as extra command line parameters "--nokbd
--start-timeout 600". Additionally I always check the option "Reboot
system after udpcast" together with "full featured shell".
I waited 10 minutes because I wanted to see what happens when the
timeout exceeds and then I saw the following messages on the screen:
"Receiver error.
Error. Not rebooting."
The machine did not reboot what I don't think is the desired effect.
Regards
Jens
Yes, the "reboot" option in cast-o-matic was initially intended to
reboot the machine into the installed OS in case of success. However, if
--start-timeout is supplied and triggered, udp-receiver returns an error.
I've now added an "unconditional reboot" checkbox to cast-o-matic which
should address this issue.
Regards,
Alain
_______________________________________________
Udpcast mailing list
Udpcast(a)udpcast.linux.lu
https://lll.lgl.lu/mailman/listinfo/udpcast