Trial fails when switching to x64Solved

On Mac OS X, the trial data is not forward/backward compatible between x86/x64. Is this switching behavior normal for your users?

Hello Sam,

Thank you for your reply. Yes switching from x86/x64 is normal : as x86 is the default behavior, but x64 can be used in some conditions for better performances.My product is a video application, so performances are very important, and every optimization matters.

What perfect/not-perfect solutions do I have ?Why the trial extensions don't suffer from such a behavior ?

Thank you. Philippe

What perfect/not-perfect solutions do I have ?

Unfortunately it goes back to the way we store dates (in a very "raw" form that differs between architectures like x86/x64/PPC on Unix OSs -- Windows is uneffected by this problem). If this is actual behavior that your customer do, then we'll have to fix this problem and use a more generalized time format that is compatible between architectures.

In the meantime the best solution is to tell the users that want to use the x64 version of your app to always use that version of your app (or at least until we fix this problem).

Why the trial extensions don't suffer from such a behavior ?

Because trial extensions aren't stored in a "raw" format that's architecture dependent.

Hello,

So a solution could be to set the default trial days to zero, and use a trial extension when first starting the app, right ?As extension trial cannot be used several times, I think it's safe.

Tell me if this workaround could work.

Thank you. Philippe

No, that wouldn't work. The only thing that works (w/ TA 3.3.4) is to either use x86 or x64 and not switch in between. We'll fix this with the next version.

Hello Sam,

I don't understand :- you said : "trial extensions aren't stored in a "raw" format that's architecture dependent"- but at the same time, you said I cannot use a trial extension when first starting the app, as workaround

For the moment I need to send a trial extension to every new user, that downloaded the trial version.I'd like to find a solution asap.

When do you think, you will released the next version ?

Thank you. Philippe

I don't understand :- you said : "trial extensions aren't stored in a "raw" format that's architecture dependent"- but at the same time, you said I cannot use a trial extension when first starting the app, as workaround

The trials extension, while not stored in a "raw" format, depends on a value that *is* stored in a "raw" format. Thus, you're building your house on sand, so to speak.

When do you think, you will released the next version ?

We want to get TurboFloat out first. But if we don't get that out within the week then we'll put together a quick fix for this problem.

Hello Sam,

Any news about the fix ? Thank you.

Philippe

It's coming soon. It will be released alongside the Android version. (Around middle of next week.)

Hello,

Sorry to bother you, but any news regarding the around-middle-of-the-week update ?For the moment I need to send a trial extension to every new user, so it's not very confortable ...

Thank you,Philippe

Yes, it's coming with the Android version.

Hello Wyatt,

Ok, but when this update will be published ?Last week, Sam told me "Around middle of next week", and we're sunday already ...

Best. Philippe

Ok, but when this update will be published ?

We're working to get it out as soon as possible. Days, not weeks.

Ok. Thank you.This answer makes me happy 🙂

Hello Wyatt,

Any news about the release date for the fix ?I don't want to hassle you, but keep in mind that I use your time estimation to talk with my users about this fix ...

Best,Philippe

Soon. We had intended to release both the Android TA and this fix at the same time. We're putting off the Android release a bit longer and releasing this fix (and a few others) in a couple of days.

Hello Wyatt,

Any news ?The quick fix was supposed to be released around April the 10th. Now it's has been delayed every week for 1 month ...I prefer to hear "release date is next month" rather than "release date was next week, but it's now delayed next week" every week ... I'm wondering why your estimations went so wrong, and as a customer, I always imagine the worst : not good for your credibility. And as I'm a software maker too, my own customers think the same for my product : not good for me.

Best. Philippe

Sorry, we didn't intend to mislead you.

This bug fix was originally intended to be wrapped up with the Android release. The Android release is taking longer than expected. Thus we're wrapping up the release with a few other bug fixes.

Hello Wyatt,

30 days ago, you told me : "We're working to get it out as soon as possible. Days, not weeks."As I depends on LimeLM to release my product update, I'd like a hear a CLEAR answer to this question : will the update be published within the next 7 days.If not sure, please dare to tell me NO. Simply NO, so I can release my own update without your fix.

I'm a software maker, so I perfectly understand "NO".What is a problem for me is "waiting for something that won't come anyway" : because, if I don't have the right informations, I cannot take the right decision (I mean : releasing an update of my product with or without your fix).

Sorry to be direct, I know that support isn't easy, and fixing issues is hard. But I need a clear vision for your update.

Thank you. Philippe

I'd like a hear a CLEAR answer to this question : will the update be published within the next 7 days.

We hope to, yes.

If not sure, please dare to tell me NO. Simply NO, so I can release my own update without your fix.

The problem with non-critical bugs (like this date/time bug) is that critical bugs take precedence. And unfortunately a few of those critical bugs popped up and were solved over the preceding weeks.

So, it's not about saying yes or no. It's about uncontrollable circumstances.

Although I should hire more people so these necessary diversions don't take such a bite out of our planned releases.

What is a problem for me is "waiting for something that won't come anyway" : because, if I don't have the right informations, I cannot take the right decision (I mean : releasing an update of my product with or without your fix).

Release your update without the fix. When we release the fixed TA, release a new update of your app.

Hello,

I submitted this bug 2 months ago, and still no fix. The same for the IsDateValid() problem (https://wyday.com/forum/t/1980/isdatevalid-not-working/). If I read you, these bugs have been fixed ages ago ...

For small companies, I think reactivity should be a strength, not a weakness ... Even if there are still critical bugs (and you got a lot apparently), you should have published an intermediate update within the last 2 months (just as you did for version 3.3.4).

So I followed your very obvious advice ("Release your update without the fix. When we release the fixed TA, release a new update of your app."), and I code myself a workaround for this problem.Now, I think it's time that you apply this advice to your own company, and release an intermediate update.

I hope you'll understand why I'm a bit disappointed.Best. Philippe

PS : I don't think hiring people would be the solution (in fact, I think the opposite, it'd bring new problems)

I hope you'll understand why I'm a bit disappointed.

Yes, I do. We paired this bugfix with other bug fixes and features and our ETA was consistently off.

I'm sorry.

TurboActivate 3.4 is now out. This problem is solved.

Hello,

I confirm this problem is solved.

Best. Philippe