Starting, but "loading previous buffers" and no sound

[MrHarcombe]

Back to our school roll-out, again...

Got the 2.8 version installed and rolled-out and it does seem to be reliably starting up.

Sadly, as commented by "hopbit" in issue 711, I just get the message "# Loading previous buffer contents. Please wait..." in all buffers and even if I try and add sample code, no sound is played.

Any thoughts? What can we do to help diagnose this?

[samaaron]

I wonder if this is Sonic Pi attempting to save the contents of the buffer and failing due to permissions issues. Do you have a HOME environment set to a readable directory?

[MrHarcombe]

Home is, in theory set to a readable directory (in our case, it's a root drive H:) - and I see a ".sonic-pi" folder get created. But there are certain types (ie extensions) of file you aren't allowed to create (eg .cmd) - what files should be in there?

[samaaron]

Sonic Pi attempts to do three things:

• Create log output files in ~/.sonic-pi/log - each with the extension .log
• Create a .spi file containing the contents of the buffer in: ~/.sonic-pi/store/default/workspace_n.sps
• Create a new git commit with the contents of the buffer in a local git repo in ~/.sonic-pi/store/default/.git

The last action isn't creating one file but a number of them using Git's internal system. Perhaps this is creating the issue?

Are you able to find and hack the Ruby source in the app bundle? If so, we can start playing around commenting things out to see if we can find the cause...

[MrHarcombe]

I do get a ~/.sonic-pi but it only has a store directory, no log.

Equally, in store\default there are no files being created.

So, it does look like write permissions... when you say "the app bundle", if it's in the installation folder, I can't get to the C: drive but I have a "man who can" standing next to me at the moment :)

[samaaron]

Great!

We're looking to find the app/server/sonicpi/lib/sonicpi folder. If you can find it, let me know!

[MrHarcombe]

I'm about to teach again, but I'm free P4 (in about 90 minutes) so I can go and login on a machine that can access the C: drive and look in that folder. If you can post some hints as to what we're looking for in the first instance, I'm happy to have a hack around and see what we can fix.

If it's okay, I'll ping you on Twitter when I'm at the machine (same username/avatar)?

[samaaron]

Around line #688 there's this:

  File.open(path, 'w') {|f| f.write(content) }

This is where we're trying to write the contents of the buffer to disk. If you can comment out that line and try again...

[samaaron]

Yep, please do ping me. Perhaps @jweather can also help to find the location of the file on your machine...

[samaaron]

Could you also check to see whether .spi extensions are allowed?

[MrHarcombe]

Insofar as I can do a Save as... in notepad and save a document called blah.spi... yes, I can create .spi files.

[samaaron]

Hmm, but you see no .spi files in ~/.sonic-pi/store/default?

[MrHarcombe]

Actually I do see the files, now...

But look at those timestamps - I was in the middle of teaching a lesson on webpages at 11:39; there's no way I was running SonicPi let alone editing a file. So could this be a buffering issue?

[samaaron]

Saving all the files (which is what's causing all those files to exist) happens automatically on shutdown of Sonic Pi. Could it have been that Sonci Pi was shut down at 11:39?

Also, are you still seeing the same issue, or can you now run:

play 80

[MrHarcombe]

Red herring - my tech tried to paste files in under me to see if that helped...

[samaaron]

Haha :-)

[samaaron]

Did you manage to find the file:

app/server/sonicpi/lib/sonicpi/runtime.rb

[MrHarcombe]

Yup. What should I be tweaking? Found the method __save_buffer at around line 688.

[samaaron]

Yep, comment out the line:

 File.open(path, 'w') {|f| f.write(content) }

By prepending a #:

 #File.open(path, 'w') {|f| f.write(content) }

and see if that fixes things...

[MrHarcombe]

Might be of significance - even as an admin user, I can go to %HOMEDRIVE% but not %HOME%.

[samaaron]

Interesting...

are %HOMEDRIVE% and %HOME% set to the same value?

[MrHarcombe]

That works for me - commenting out that line and re-running means I can play sound!

But presumably that's not a long-term solution ;)

[samaaron]

OK, interesting! That means it is a permissions problem. For some reason Sonic Pi can't save to the directory it wants to. It means that Sonic Pi has no memory on your machines which would be a shame.

It would be useful to know where the users should save to. Do you have a preferred notion of a home directory and is it set to one of the environment variables? If so, which one and what is the path?

[MrHarcombe]

Now I'm on an admin PC, I can see that we don't actually have a %HOME% environment variable set. Only a %HOMEDRIVE% and %HOMEPATH% - I was previously trying to get at the env from within Python code - wonder if it was putting together a HOME% for me... Will get back to you in a sec?

[samaaron]

However, you were still seeing a .sonic-pi directory being created - or is that not correct?

[MrHarcombe]

I am, yes.

For the record, though, Python seems to put the %HOME% env variable together for me, as it is still listed when I run the same code on this admin PC. But from the command prompt, it doesn't.

[MrHarcombe]

Oh, just tried closing an re-opening...

The program starts up okay, but even on this PC with the fragged runtime.rb I now get the "# Loading previous buffer contents..." message.

Although it does play sounds.

[samaaron]

Yep, that's because the loading of buffers is broken due to file permissions. That should be fixed once we figure out the best way to re-route around your permissions security!!

[samaaron]

Could you run the following code in Sonic Pi and give me the results:

puts Dir.home
puts File.resolve_path("~")

[MrHarcombe]

Um, as in "put in a buffer and hit Run"?

Nothing happens - where would you expect to see output?

[samaaron]

I'd expect to see output in the log on the right.

Do you see log output at all even when you run:

play 80

[samaaron]

:-)

[samaaron]

Another thing to try is:

d785cbb

[samaaron]

@hopbit does d785cbb fix things for you also?

[hopbit]

Nope, d785cbb doesn't help.

Replacing

File.open(path, 'w') {|f| f.write(content) }

with

File.open(path, 'w') {|f| f.puts(content) } 

doesn't help after restarting system too :/ I've googled a lil' bit on File.write and File.puts, the difference at API level is like @samaaron said - it add new line and one more thing is that puts uses write within it.

It's definitely looks like something related to user permissions.

[MrHarcombe]

Really sorry - Ofsted rang at lunchtime on Monday, so not really been in a position to look at this! I do have some non-contact time tomorrow, so will try and run those test cases then.

[MrHarcombe]

Right, well I've copied in the file as-is from d785cbb and I'm still seeing the errors. It very much feels like a loading issue, rather than a writing issue. I'll try and get timings for the...

1000.times do
  IO.read(project_path + "/workspace_one.spi")
end

...kind of run and see whether our network is prolonging the load-time agony, so to speak.

[MrHarcombe]

I'm now having issues even getting to the point where I can run code in the buffers...

It's looking like sc_synth process isn't running - would the UI then wait for that before it could proceed? Could that be part of our startup problems, still?

If I start a fresh instance, I'm just not seeing an sc_synth process start - which feels a lot like the issue we have in 2.7.0. Does this version now block until it finds the SuperCollider process running before going any futher?

[samaaron]

The GUI asks the server to start which in turn fires up scsynth.exe.

Are you seeing anything in your ~/.sonic-pi/log files?

[MrHarcombe]

Um... it's not creating any! I'll stop it and start again... :(

[gregoryyoung]

From reading through this I think this issue could be resolved if an opt-in configuration point could be offered to not use HOME but instead use whatever path I give it. This is useful in general as well and would bypass the issue of people who have remote HOME directories.

[sccmentor]

As mentioned on Twitter I thing this is a latency issue. Normally the .sonic-pi resides in the C;\users folder but its likely that MrHarcombe's school has folder redirection set to redirect the users data to H:\

Is it possible to set the env variable "%localappdata% as the location for the .sonic-pi folder? This is never redirected natively as part of Windows folder redirection policies and resides in the C:\Users\Username\AppData\Local\ folder. User also have full permissions to any data in that folder.

[kenwhelan]

OK, I've seen this problem on some of our student's machines. These are their personal machines and most would have appropriate permissions to write files under their c:\users directory.

We tried a number of methods including killing scsynth.exe in Task Manager and rebooting completely.

My own machine running Windows 10 and SPi 2.7 hasn't had the problem yet but my daughter's laptop running Windows 10 and SPi 2.7 has.

I'm going to upgrade both of them to 2.8 and do some testing.

Sysinternals.com has a neat tool called procmon.exe which could help in this instance as it can track why a file did/didn't launch and will flag if it's a permissions problem or missing directory etc.

Let me take a look at it here...

[garrybodsworth]

procmon is definitely the way forward to debug this issue https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx it doesn't need installing (you can install via chocolatey as well if you want) - just execute the process and capture. You will generate a lot of data so be sure to make notes of the timings of events to help narrow down the search.

If it is felt to be a network latency problem you can simulate this using clumsy http://jagt.github.io/clumsy/index.html

[gregoryyoung]

using remote drives is harmful

[dearchap]

Yes I agree with @garrybodsworth . Processmon is the way to go for this.

[sccmentor]

I've been able to replicate the issue on a VM that I can revert back to a snapshot and keep reproducing the error.

Everything is local on the device, no folder redirection or network drive mappings.

The Windows Defender AV is already disabled as I use this for sequencing virtual applications and Windows Search is also disabled.

It's a vanilla install of Windows 8.1 x64 with nothing else installed, except for the App-V Sequencer.

On tests last night SP would fail on first launch every time, and sometimes 2nd launch, but would then rectify itself.

Observed behaviour - No spi files created on exit of app in the .sonic-pi/store/default folder. I initially thought that the.git files weren't created but I had hidden items hidden.

sonic-pi.exe, ruby and scsynth.exe process all launched at start up of the app and all process closing down as expected nothing zombied.

I have noticed a spike in CPU and Disk activity that does not occur on 2nd/3rd launch. The app is writing to the disk at the time so this may be expected but it's a noticeable maxing of the activity.

I did run a perfmon but didn't see anything out of sorts. It was getting late so I called it a night in the end. I'll re-run tests today and see if there's anything else to identify.

[sccmentor]

I've pre-populated the .sonic-pi folder before launching the app for the first time so that all the files - including spi files existed. Issue still occurs.

[dansmith9]

I have this same issue on both my teacher PC's at school, but as @sccmentor says, on the second or third time I load Sonic Pi it seems to fix itself. Our students are using the Pi version though, so I can't say if it affects student machines on our network too.

[samaaron]

Please could everyone try v2.9: http://sonic-pi.net/#windows

[kenwhelan]

Cool, downloading and installing now.

On 30 December 2015 at 21:30, Sam Aaron [email protected] wrote:

Please could everyone try v2.9: http://sonic-pi.net/#windows

—
Reply to this email directly or view it on GitHub
#830 (comment).

[kenwhelan]

Working flawlessly so far on Windows 10 64 bit desktop machine.

I'll try it on my W10-64bit laptop shortly.

Well done (again)!

On 30 December 2015 at 22:27, Kenneth Whelan [email protected] wrote:

Cool, downloading and installing now.

On 30 December 2015 at 21:30, Sam Aaron [email protected] wrote:

Please could everyone try v2.9: http://sonic-pi.net/#windows

—
Reply to this email directly or view it on GitHub
#830 (comment).

[dumbledad]

Installed 2.9 on Windows 10 laptop (11091 insider build of early beta) over 2.7 and all works wonderfully

[samaaron]

Fabulous news :)

[MrHarcombe]

And it works in my school environment, too! Many thanks for all the hard work - can't wait to see what the Y9s get making, next term :)

[hopbit]

Works fine on Win 7 64 bit too.

2016-02-05 17:19 GMT+01:00 Ian Harcombe [email protected]:

And it works in my school environment, too! Many thanks for all the hard
work - can't wait to see what the Y9s get making, next term :)

—
Reply to this email directly or view it on GitHub
#830 (comment).

Łukasz Siwiński
http://siwinski.info

[xavriley]

So this is an epic thread with lots of useful info, and I want to take the chance to thank everyone for their contributions here. That said, I think this was probably the issue to do with latency which was fixed in v2.9. If people are still having trouble with v2.9 then let us know, or maybe open a separate issue.