Generating Multiple Text-to-Speech Fails in AI Explorer

Can you re-test this as the AI Explorer has just had a major refactor merged.

I just tried to upgrade to beta 3 and it broke my site, so I can't test this at this time. I made a bug report about the upgrade error I received.

It was recommended to upgrade to the dev version when beta 3 did not work. I was able to successfully upgrade to the dev version, but this issue was not resolved using the dev version.

As of now, each time I try to generate a new tts file, it give me a sample file that I created yesterday and does not provide the new tts creation.

I just successfully updated to beta-4 but I am still experiencing this issue.

So, I don't have time at the moment to look at this, but I will describe the issue here for anyone wanting to fix it.

The current audio explorer works like this:
1. You create a text-to-speech audio file.
2. This audio file is saved in the public file structure with a fixed name. The reason is that we don't want to create a lot of garbage and this was a simple solution.
3. The audio player can now play that file.

The problem when using external storage like blob storage, or if you have a varnish cache or a CDN is that this file gets cached or might take time to refresh in the blob storage example. A file save should in theory flush this cache, but it might not always be true. This leads it to no being able to save.

The way we should do this instead, to get rid of the headache is that on the ajax response we need to play the binary instead with the audio player, see https://stackoverflow.com/a/36746554

That way no file needs to store and no caching issues.

Will that approach still work with the "Save as Media" functionality in some of the plugins? That also seems to assume a public file system.

Would it not be better (and easier) for the player to store the file in the temporary file system? All Drupal sites must have a tmp folder somewhere, and this means the unneeded files will eventually get cleaned up as well? Presumably there's a way of asking Drupal what the defauilt file system is and using that as well, before we start having to roll our own media players with custom javascript.

Oh, you are right - you can reach the tmp system via proxy, correct. Yes, a better solution @mrdalesmith. I think though anyway for the save as media we need to figure out the default file system, but lets keep that in the separate issue then.

OK using tmp doesn't work - I didn't take into account that files in tmp don't have a public URL to play the file from.

Instead, I've fixed a bug in the media creator and told it to always use the settings in the media field - which is much better because we can trust users to decide where their files should save. For the rest of it, it will just store them in the default file system, which for most people will still be ://public

I think there should be a proxy on /system/temporary?file={file_name}, that is how you can preview files when you use file_managed form component. But maybe that requires some session to be viewable.

Anyway, for this issue this will solve it. Will check the code soon, maybe you can try out the so the bug is fixed for you @jbuttler?

The code is all good - @jbuttler it would be great if you test this, so I don't have to setup s3 for this test only.

No problem, I'm happy to help. Should I use the latest dev version?

Preferably getting the branch, if you know how to do that. Otherwise I will merge with dev and if its not working we continue on this branch.

I do not know how to do that. I haven't been able to find much helpful information how to do this, and my attempts have failed. If you know of a link to some instructions I can try to figure it out, but I am not successful installing the dev branch.

You could try these https://jaybeaton.com/blog/how-use-version-module-drupal-issue-fork-comp... - otherwise I tend to just download the fork using git and copy the files into my site manually.

Thanks for your suggestion, that put me in the right direction. I am still having trouble applying the fork as described, but I was able to apply the changes as a patch with composer. I have some interesting results. Essentially it works.

When I generate a tts file in the AI explorer:
1. The error is no longer received.
2. The file is saved to the medial library correctly.
3. The saved file is based on the actual prompt, and plays correctly using the requested configuration.
4. Everything seems to line up on the side of the media library.

There are a few issues:
1. The AI Explorer does not provide the new file on-screen. The file provided is an old cached file that I made yesterday.
2. Each new tts I create shows the same cached file on screen, but the correct file is saved to the media library.
3. In short, the AI explorer appears to fail when it actually does not, it provides a cached file instead of the file it just created.

I am experiencing a different issue related to this with the automator, but it seems different enough to need its own issue.

The patch I tested seems to mostly resolve the issue on my website, based on the description above.

Great, for your secondary issue, this is the same issue as this: https://www.drupal.org/project/ai/issues/3490968 🐛 Saving Text to Speech fails in AI Explorer Active

We might have to look into creating and playing a temporary file via the proxy if its available there - the issue is that s3 or maybe if you have cloudfront caches the filename we are using or another theory is that different browser settings or header output settings could lead to caching this in the browser.

However that issue continues in that ticket, saving the media works as expected now on none traditional file systems. Thanks for testing and thanks Paul for fixing the issue. Getting merged.

I am using s3, and cloudfront to serve s3 files. I don't think it is the browser cache because I have been clearing my browser cache multiple times per day while working on css. If it was the browser cache I would be able to get the new files.

When I tested the dev release recently, this issue was unaffected. I was able to save files to the media library on the dev release, but if I did not save the file to the media library I received an old file.

The changes now in dev rename every file created with a unique file name, so the question is academic in any case.