Re: audio recorder mockup

[Laurent Savaëte]

Master pushed again to devbox with fixes for all items below. Let me
know if you're still getting issues.
I don't intend to amend the recorder more than this (unless major bug)
until we actually move on to adding getUserMedia() (we're still waiting
on a major bug in both mozilla and chromium...)

On Fri 27 Jul 2012 07:44:41 PM CEST, Ian Sullivan wrote:
> Moving this to ductus-dev for increased visibility.
>
> I like the look of this and don't think the flash security popup when
> you first start recording is a problem. Adding an explanation of what to
> click on to that popup, as you mention, would help new users and I agree
> that a loading bar or notification while uploading the audio recording
> would make the whole thing feel more responsive. While recording my
> short audio snippets I did not find the upload delay troublesome.
>
> One issue I did run into is recording multiple audio elements. I played
> around in both chrome and firefox but cannot get the widget to add more
> than one audio recording without saving first. Adding the first element
> works as expected and after a momentary save the new audio-player
> element replaces the recording widget appropriately. If I try and click
> on a second empty cell and add audio I get the recording widget but
> hitting "stop" never results in the recording widget being replaced by
> an audio-player one. If you save the lesson after the first recording,
> then you can add another element normally. Also, if you record an
> element and then delete it you similarity can record a new element.
>
> -Ian
>
> On 07/26/2012 09:14 PM, Laurent Savaëte wrote:
>> I pushed a "beta" to devbox in the hope of catching bugs that are hard
>> to find locally (because of network lag).
>> Got one already (flash card deck, record some audio, then while it's
>> uploading hit "new audio" elsewhere, your audio will land in the wrong
>> place).
>> I've left the flash authorisation at the very beginning, which would be
>> a problem if we embedded a 5s widget on a page that has other content.
>> But having that panel show up after clicking "record" makes for very odd
>> recordings, because you're not sure when it actually starts.
>> Please take a min or 2 to test it out on flashcard decks and 5s widget,
>> and let me know how it works.
>> I'll also try to add a "loading" icon where it makes sense (during
>> uploads, or while loading flash), and an explanation for what to do when
>> facing the security panel.

[Ian Sullivan]

[Ian]

Works great in Chromium, which even adds a little spinning progress
indicator into the record button while uploading. In Firefox (14.1 and
iceweasel 10.0.6) the first time I record something in a particular cell
and hit the "stop" button, nothing happens besides the "stop" button
turning back into a "record" button. Only after recording a second time
does anything appear to upload and do I get the audio player widget in
place of the recording one.

-Ian

[Laurent Savaete]

> Works great in Chromium, which even adds a little spinning progress

glad that my code is so clean you think it's a chromium built-in feature ;)

> indicator into the record button while uploading. In Firefox (14.1 and
> iceweasel 10.0.6) the first time I record something in a particular cell
> and hit the "stop" button, nothing happens besides the "stop" button
> turning back into a "record" button. Only after recording a second time
> does anything appear to upload and do I get the audio player widget in
> place of the recording one.

Unfortunately, I can't reproduce the bug, everything works fine for me
(open the page, authorise flash, start recording, stop recording,
spinner is shown, then switch to audio player from the first attempt
to record), both in FF 14.0.1 and FF nightly 17.0a1 (also chromium 18
and chrome 22).
I've had trouble earlier with firefox caching that wouldn't let go of
the old version of the page, despite the cache-busting system we use
(restarting the browser seems to have solved the issue last time).
If you can't get it to work, try a different url (like a different FCD
template, or no template at all). If it all fails, can you provide
step by step instructions to reproduce?
You should get the instruction text around the flash security panel.
If not, FF is still using the previous version of the page.

[Jim Garrison]

On 07/28/12 18:06, Laurent Savaete wrote:
> I've had trouble earlier with firefox caching that wouldn't let go of
> the old version of the page, despite the cache-busting system we use
> (restarting the browser seems to have solved the issue last time).

Do you know what specifically is being cached too long? It's quite
possible that we're using overzealous Expires headers somewhere...

[Laurent Savaëte]

Since we use a cache buster with versioned filenames for all CSS+JS,
the problem has to come from the main html page.
I got an example of what is happening.
First query to
http://laurent.dev.wikiotics.net/new/flashcard_deck?template=podcast at
14:04 (haven't opened that page in over 24h)
response headers below:
=============================================
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Mon, 30 Jul 2012 12:04:21 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Content-Language: en
Expires: Tue, 31 Jul 2012 12:03:40 GMT
Vary: Accept-Language, Cookie
Last-Modified: Mon, 30 Jul 2012 12:03:40 GMT
Cache-Control: private, max-age=86400
x-frame-options: SAMEORIGIN
Set-Cookie: csrftoken=k4vMl5kFrw3pc5uddxqTUhhUKXwtz5c1; expires=Mon,
29-Jul-2013 12:03:40 GMT; Max-Age=31449600; Path=/
Content-Encoding: gzip
=============================================
then updated the code on the server (only a change in base.css, nothing
else).
Same url reloaded in the same browser gives me the same page (headers
below), note the 304 NOT MODIFIED response from nginx.
=============================================
HTTP/1.1 304 NOT MODIFIED
Date: Mon, 30 Jul 2012 12:13:35 GMT
Expires: Tue, 31 Jul 2012 12:03:40 GMT
Vary: Accept-Language, Cookie
Last-Modified: Mon, 30 Jul 2012 12:03:40 GMT
Cache-Control: private, max-age=86400
=============================================
Same page loaded in a different browser (not previously cached) shows
the updated content (ie the <hash>.css file is different and is what I
expect)

So I think what is happening is that nginx does not see that
django-compressor implicitly modified the content of the HTML file (by
changing the hash in the filenames) and thus keeps serving the same
content for up to 24h. So my guess on a bug in FF above was a mistake.
From a quick chat with the compressor guys, there doesn't seem to be a
way for nginx to know that the hashes have changed, so we may have to
be more cautious with caching those pages.

[Jim Garrison]

I'm not surprised that some documents (urns and wikipages) are being
cached even when they shouldn't be, but I am surprised that things in
/new are being cached in such a way. It doesn't even look like an ETag
is being served in the http response, so I'm not sure why it's returning
a 304. (It seems to be due to the Last-Modified header, but I'm not
sure where that's being intercepted for a 304 response...)