Reply to thread

Message

<blockquote data-quote="and-81" data-source="post: 238792" data-attributes="member: 11844">hrox:I've got a feeling this is the same problem a couple of others are seeing ... The good news is I think I'm really close to a solution...Here's what I think is happening ...I think people are holding down the button on their remote when they teach the IR command... and I think for some remotes the delay between repeats is small enough that the code at the moment doesn't detect the pause as a pause between codes ... this results in a really long IR blast sequence, but the device can only handle continuous blasting of a certain length (which I think I'm really close to discovering).I'll make some changes in the next version that will try to detect the appropriate code length and also to prevent the code from trying to send blast sequences that will overflow the device.Thanks for the feedback, I hope I can give you some good news within a day or two.Actually, on the other hand it kind of looks like the method to convert time code data into native data for the blaster is failing ... I'll use the time codes from your log and feed them into the converter and see what's going on ...There could be two blasting bugs here ...&nbsp; Either way, I should have it sorted out within a few days ...Thanks,</blockquote>

[QUOTE="and-81, post: 238792, member: 11844"] [B]hrox:[/B] I've got a feeling this is the same problem a couple of others are seeing ... The good news is I think I'm really close to a solution... Here's what I think is happening ... I think people are holding down the button on their remote when they teach the IR command... and I think for some remotes the delay between repeats is small enough that the code at the moment doesn't detect the pause as a pause between codes ... this results in a really long IR blast sequence, but the device can only handle continuous blasting of a certain length (which I think I'm really close to discovering). I'll make some changes in the next version that will try to detect the appropriate code length and also to prevent the code from trying to send blast sequences that will overflow the device. Thanks for the feedback, I hope I can give you some good news within a day or two. Actually, on the other hand it kind of looks like the method to convert time code data into native data for the blaster is failing ... I'll use the time codes from your log and feed them into the converter and see what's going on ... There could be two blasting bugs here ... Either way, I should have it sorted out within a few days ... Thanks, [/QUOTE]

Verification