mikeill / appension Goto Github PK

Butler says, I thought The Glitch Oracle was supposed to function thusly: enter a word, the Oracle treats this as a "key word", and pulls up a lyric from the lyric page for an answer? Example: I just added three chunks, and their accompanying lyrics, typed in "Christmas", "Grandma" = both words used in Missile Toe's chunk, but I didn't get the couplet with those words.

Following error messages following CTRL+C in renderer terminal when it's frozen:

2016-12-26 15:30:18,243:INFO:aiohttp.access:165.120.119.253 - - [26/Dec/2016:20:30:18 +0000] "GET /status.json HTTP/1.1" 200 238
65 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:30:18,273:INFO:aiohttp.access:108.205.63.107 - - [26/Dec/2016:20:30:18 +0000] "GET /crossdomain.xml HTTP/1.1" 404 
14 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:30:20,060:INFO:aiohttp.access:108.205.63.107 - - [26/Dec/2016:20:30:20 +0000] "GET /status.json HTTP/1.1" 200 2386
5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:30:31,468:INFO:aiohttp.access:108.205.63.107 - - [26/Dec/2016:20:30:31 +0000] "GET /status.json HTTP/1.1" 200 2386
5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:30:45,398:ERROR:aiohttp.server:Error handling request
Traceback (most recent call last):
  File "/home/mikekilmer/appension/env/lib/python3.7/site-packages/aiohttp/web_server.py", line 61, in handle_request
	resp = yield from self._handler(request)
  File "/home/mikekilmer/appension/env/lib/python3.7/site-packages/aiohttp/web.py", line 249, in _handle
	resp = yield from handler(request)
  File "/home/mikekilmer/appension/glitch/renderer.py", line 178, in moosic
	await resp.drain()
  File "/home/mikekilmer/appension/env/lib/python3.7/site-packages/aiohttp/web_reqrep.py", line 888, in drain
	yield from self._resp_impl.transport.drain()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 333, in drain
	yield from self._protocol._drain_helper()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 211, in _drain_helper
	yield from waiter
2016-12-26 15:30:48,324:INFO:aiohttp.access:165.120.119.253 - - [26/Dec/2016:20:30:48 +0000] "GET /status.json HTTP/1.1" 200 23865 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:30:50,045:INFO:aiohttp.access:108.205.63.107 - - [26/Dec/2016:20:30:50 +0000] "GET /status.json HTTP/1.1" 200 23865 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:31:00,041:ERROR:aiohttp.server:Error handling request
Traceback (most recent call last):
  File "/home/mikekilmer/appension/env/lib/python3.7/site-packages/aiohttp/web_server.py", line 61, in handle_request
	resp = yield from self._handler(request)
  File "/home/mikekilmer/appension/env/lib/python3.7/site-packages/aiohttp/web.py", line 249, in _handle
	resp = yield from handler(request)
  File "/home/mikekilmer/appension/glitch/renderer.py", line 169, in moosic
	await asyncio.sleep(1)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 476, in sleep
	return (yield from future)
concurrent.futures._base.CancelledError
2016-12-26 15:31:02,940:INFO:aiohttp.access:108.205.63.107 - - [26/Dec/2016:20:31:02 +0000] "GET /status.json HTTP/1.1" 200 23864 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:50.0) Gecko/20100101 Firefox/50.0"
2016-12-26 15:31:18,264:INFO:aiohttp.ac

If we render the last 10 seconds of track A with a hard transition into the last ten seconds of track B the total length should be twenty seconds.

Can we make a function that tests that?

Says Keith... even when front end is working. This is, perhaps when renderer is not running. I was also seeing 404 on status.json

there is no REWIND/BACK TO ZERO button on The Devil Glitch or The Major Glitch players.

This looks like a useful tutorial. However it may make more sense to use Cloudflare SSL.

Could backup to AWS relatively easily.

It finally came up that password reset wasn't working.

Poking around a little bit, I discovered two things:

1. Server's confirm_reset function is checking for return from database.reset_user_password
2. database.reset_user_password wasn't returning anything.

Updated database.reset_user_password to if cur.rowcount, return True, which seems to be working.

Then I noticed that we hadn't actually built out the password reset function. I just resets the password the "changeme", with a TODO about building the functionality out.

So I think that there are two approaches to this:

1. pass the temporary hexkey through as a hidden field in a form where the user inputs a password, and then to a new app.route in which that password is input to the database.

2. Use Ajax to retrieve desired password string from user.

My guess is that approach number one will be simplest.

Some of the tracks definitely need trimming.

In pydub this is trivial. we could update renderer.infinitely_glitch() as follows:

# remove itrim and otrim
itrim = nexttrack.track_details['itrim']; otrim = nexttrack.track_details['otrim']
dub2 = dub2[itrim:otrim]

Then when we analyze the first and last beats with Amen, we we insure that they are at times after itrim and previous to otrim.

Each Amen timeslice in timings['beats'] contains a start time: t1.timings['beats'][-1].time, so I think if we update the list indexing here: b.duration.value for b in t1b[-1-LAST_BEAT_AVG : -1] we can get first and last beats inside of the itrim and otrim parameters.

Steal from Hogan. TODO.

Stdio.File("/etc/systemd/system/"+svc,"wct")->write(#"[Unit]
Description=Hogan calling on %s

[Service]
Environment=DISPLAY=%s
WorkingDirectory=%s
ExecStart=%s %s %[0]s
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
",goldiname,getenv("DISPLAY")||"",getcwd(),pike,argv[0]);
Process.create_process(({"systemctl","--system","daemon-reload"}))->wait();
Process.create_process(({"systemctl","enable",svc}))->wait();
Process.create_process(({"systemctl","start",svc}))->wait();```

It looks like the information delivered via the status.json route in renderer are not in sync with the segments of all.mp3. Even the three tracks we are listing as playing now-ish are out of range.

I think that all.mp3 is behind the status.json details. Would it help to render a sync.log file that prints filename and times for adding track to all.json and info to status.json? Possibly the output of sudo systemctl status -l glitch-renderer will be enough. Ideally we want the first item in status.json to be the info for the most recently added track, correct?

Am still trying to wrap my head around the relationship between status.json and all.mp3. It looks like _render_output_audio is pretty much tracking/generating the timing, via the rendered_until global.

If I am understanding the code correctly, rendered_until is set to ten seconds prior to time.time() when the server starts, and is then incremented by the duration_seconds of each (pydubAudio) segment _render_audio_output receives, which includes:

1. bulk of track A (dub1[skip : t1_end - t2_start])
2. end of track A overlaid with track B up to it's first beat (olay1)
3. start of track B overlaid with track A following it's final beat (olay2)

So every time _render_output_audio gets a segment, the rendered_until global is incremented by the amount of seconds of the duration of that segment, as returned by pydub? And then it is never actually compared again to time.time() until the renderer is restarted again? Are we risking a drift there?

On line 418 of database username = cur.fetchone()[0] may not return an admin.

As noted in TODO: Currently, any track added after the system's been up for a while will be played to death.

Workaround, manually reset played column in database.

I think that in the first version of the App we were enqueueing (there’s that vowel-heavy word again) all the tracks at once, so that a track wouldn’t be repeated until each unique track had been played once.

I like the idea of dynamically equalizing the played counts by prioritizing less-popular tracks, but imagine that another approach would be to dynamically updated the played count of each new track to match the (average, lowest) play counts of others.

Chris asks: What's it supposed to do?

This is the systemd log:

sudo journalctl -fu glitch.service
Mar 17 18:51:34 indu gunicorn[26194]: [2017-03-17 18:51:34 -0400] [27684] [DEBUG] POST /submit
Mar 17 18:52:04 indu gunicorn[26194]: [2017-03-17 18:52:04 -0400] [26194] [CRITICAL] WORKER TIMEOUT (pid:27684)
Mar 17 18:52:05 indu gunicorn[26194]: [2017-03-17 18:52:05 -0400] [27770] [INFO] Booting worker with pid: 27770

Looked at:

sudo journalctl _PID=27684
-- Logs begin at Wed 2017-03-15 19:17:13 EDT, end at Fri 2017-03-17 18:53:53 EDT. --
sudo journalctl _PID=27770
-- Logs begin at Wed 2017-03-15 19:17:13 EDT, end at Fri 2017-03-17 18:54:02 EDT. --

But that's not very revealing, at least to me. This is the behavior each time I try to submit a new track.

Admin would like to be able to override the automatic crossfade.

My idea for front end was a checkbox on the manage_transition page and inserting a -1 into the xfade field in the database to signify a hard transition.

Looked around the renderer a bit. Expecting that the parameter would need to get, ultimately to infinitely_glitch() both for render_all() and render_audition().

I see that both of those functions are enqueueing into _track_queue, and that that's what infinitely_glitch() pulls from via get_track_to_play().

Would it make sense to send a parameter to infinitely_glitch() telling it to consider nexttrack.track_details["xfade"], and if it = -1, don't overlay?

Butler says: on the Admin page, when I was adding the latest chunk, tried to upload a .wav file. Got an error message. An MP3 worked, tho. So..either it won't take .wavs, something went wrong at this particular time, and/or we need to change the instructions on the SUBMISSIONS page to only allow MP3s?

I thought I had see and addressed this. http://infiniteglitch.net/instrumental_track route should work, obviously.

We should let the user see what is happening when stream is downloading to their computer.

I think we aren't sending emails at all. Must have skipped implementing that feature as it's got TODOs on it in server.

This library might be useful:

https://pypi.org/project/Flask-SendGrid/

if can't get working, may look into alternative like http://createjs.com/#!/Demos/SoundJS/Audio-Test-Suite