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@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast