Bug 1409958 - sooperlooper not connecting
Summary: sooperlooper not connecting
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sooperlooper
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fernando Lopez-Lezcano
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-04 02:15 UTC by J. Bruce Fields
Modified: 2017-08-06 03:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-06 03:03:58 UTC
Type: Bug


Attachments (Terms of Use)
packet capture from lo during sooperlooper startup (488 bytes, application/octet-stream)
2017-01-04 03:04 UTC, J. Bruce Fields
no flags Details
Packet capture from lo from working startup (21.81 KB, application/octet-stream)
2017-01-11 15:08 UTC, Hans de Goede
no flags Details

Description J. Bruce Fields 2017-01-04 02:15:25 UTC
After starting slgui I get a "Lost connection to SooperLooper engine" dialog.  I can see it is running:

ps ax|grep -i sooperlooper
sooperlooper -q -U osc.udp://localhost:13482/ -p 9951 -l 1 -c 2 -t 40 -m /home/bfields/.sooperlooper/default_midi.slb

Starting a new one doesn't help.

Using sooperlooper-1.7.3-3.fc24.x86_64 on Fedora 25.

Comment 1 J. Bruce Fields 2017-01-04 03:04:15 UTC
Created attachment 1237054 [details]
packet capture from lo during sooperlooper startup

I don't know anything about osc, but from the attached it *looks* like the gui and engine exchanged a succesful ping?

Comment 2 Hans de Goede 2017-01-11 11:20:43 UTC
I've tried to reproduce this problem, but I'm not seeing this error. I assume you are letting slgui start the engine itself ?

Comment 3 J. Bruce Fields 2017-01-11 14:29:07 UTC
(In reply to Hans de Goede from comment #2)
> I've tried to reproduce this problem, but I'm not seeing this error. I
> assume you are letting slgui start the engine itself ?

I've tried it that way, and also tried manually starting the engine, with no luck.

Out of curiosity--maybe you could attach a network trace of a succesful connection?  ("tcpdump -s0 -wtmp.pcap -ilo", then start sooperlooper, then kill tcpdump and attach tmp.pcap--or something along those lines).  It might be interesting to compare the good and bad cases.

Comment 4 Hans de Goede 2017-01-11 15:08:13 UTC
Created attachment 1239466 [details]
Packet capture from lo from working startup

Here is a capture from a working slgui startup on my machine. I also pressed record and let it run for a bit to get some more commands send / test things were really working.

Here is the terminal output from the slgui command during this:

slgui: our URL is osc.udp://shalem.localdomain:16481/
Changing our url to be : osc.udp://localhost:16481/
execing: 'sooperlooper -q -U osc.udp://localhost:16481/ -p 9951 -l 1 -c 2 -t 40 -m "/home/hans/.sooperlooper/default_midi.slb"'

slgui: spawned new engine
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot lock down 42435354 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/60)(1: Operation not permitted)
AcquireSelfRealTime error
slgui: remote looper is at osc.udp://shalem.localdomain:9951/ version=1.7.3   loopcount=1  id=1484147098
  but treating the engine URL as osc.udp://localhost:9951/
Stored settings into /home/hans/.sooperlooper
Stored settings into /home/hans/.sooperlooper
[hans@shalem ~]$ JackTemporaryException : now quits...
Jack main caught signal 2

Comment 5 J. Bruce Fields 2017-01-24 02:56:21 UTC
Thanks!

Weird that there's an ICMPv6 "destination unreachable" reply to slgui's initial request followed 1.77 seconds later by a reply from the engine.

Also weird how after the initial packet all the slgui->engine traffic is IPv4 to 192.168.1.100, and all the engine->slgui traffic is IPv6 to ::1.  I guess that was somehow the result of resolving those initial URL's that they exchanged?

OK, anyway I'm not figuring anything out from this....  Maybe I need to get a little more debugging information out of slgui next time I try.

Comment 6 J. Bruce Fields 2017-08-06 03:03:58 UTC
It's working for me now on F26.  I don't know why, but I guess I'll assume a bug was fixed.


Note You need to log in before you can comment on or make changes to this bug.