akc42 / pi_record Goto Github PK

This is basically as a result of leaving space for the long filenames that we are creating. After some throught I believe that the device name only need be a single letter "S" for the Scarlett 2i2 and "B" for the Blue Yeti, we only really need day of month in the date section and the nearest 10 seconds in the time section (we ought to not keep any recording that is less than 10 seconds long) and we don't need the separators between the numerics. So a file made on the YETI microphone at "2020-03-21T07:17:55.134Z" (Date.toISOString()) should produce a filename B2107175.flac

Any recording shorter that a time (see also #2) should not be kept to avoid cluttering up with short irrelevant recordings. I'm thinking 30 seconds as a minimum time, but we could make in environment variable configurable

It should be that when the server shuts down the client keeps polling the server with its status requests so that it re-awakens when the server restarts. I did this when the two (ipad and desktop) browsers where both running. The ipad restarted and the desktop didn't

It might have something to do with closing the Status Channel when the desktop was shutting down. Need to investigate

See https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker It looks like it might be able to remain running in the background. However its existance depends on a page keeping a ref to it, so not sure.

• run some tests with a server side event to see if it keeps working with a shared worker when the browser is hidden
• Implement if it works

Hi, how can I install your project on my raspberry pi 4?
Can you write tutorial?

The /api/status call is not matched with the regex that we have for the service worker.

TypeError: Cannot read property 'stderr' of undefined
1|recorder | at Recorder.record (/home/alan/recorder/server/recorder.js:172:24)
1|recorder | at /home/alan/recorder/server/server.js:170:51
1|recorder | at Layer.handle [as handle_request] (/home/alan/recorder/node_modules/router/lib/layer.js:93:5)
1|recorder | at next (/home/alan/recorder/node_modules/router/lib/route.js:144:13)
1|recorder | at checkRecorder (/home/alan/recorder/server/server.js:305:7)
1|recorder | at Layer.handle [as handle_request] (/home/alan/recorder/node_modules/router/lib/layer.js:93:5)
1|recorder | at next (/home/alan/recorder/node_modules/router/lib/route.js:144:13)
1|recorder | at Route.dispatch (/home/alan/recorder/node_modules/router/lib/route.js:109:3)
1|recorder | at handle (/home/alan/recorder/node_modules/router/index.js:520:11)
1|recorder | at Layer.handle [as handle_request] (/home/alan/recorder/node_modules/router/lib/layer.js:93:5)

It appears the client is calling take control, which succeeds. It then calls take control a second time, which fails, so the state goes to Await R until the next status message which confirms that the client is in control.

We should not send that second take control, but right now I cannot see where it is happening and why

Readme file needs to be updated to reflect that fact that we now use NGINX as the static web server and only the api requests are passed through.

In addition, client id is now derived from ip address and not Date.now

In addition we can now log client events through /api/log

turns out current versions of node do not support international date formats. So change logger to build up the date manually to the desired format

IOS goes to sleep when the browser is placed behind another app. Given the prime driver for this app is to allow us to record whilst using the camera to record this is unacceptable.

The requirement is to allow it to carry on.

After some trial and error not documented here we have to change the way in which the system runs. In particular

• no closing the channel if the status stream is closed (IOS does this as it puts the browser in the background)

• It must be possible to not renew for a long period of time (until 4:am the next day! - except when recording where within 4 hours, else the recording will be stopped)

• A new api call /api/:client/done is introduced which a closing client can throw at the server as the window is unloaded. This is what should stop recordings and release control

• A new api call /subscribeid which will return a uuid which we can use to identify the client. A service worker will cache the reply from the server on registering and will serve it from cache for ever after.

When its been put to the background the current timer doesn't update. Can we detect it coming back and re-read the time