From info1 at wolframhumann.de Mon Sep 16 09:33:52 2019 From: info1 at wolframhumann.de (Wolfram Humann) Date: Mon, 16 Sep 2019 10:33:52 +0200 Subject: [winswitch] Downgrading xpra In-Reply-To: <2c48fc03-bc52-f96f-c965-85493cfd87d7@nagafix.co.uk> References: <9bd89603-ea33-b764-2b34-acf3b1221b8e@nagafix.co.uk> <2c48fc03-bc52-f96f-c965-85493cfd87d7@nagafix.co.uk> Message-ID: Do you expect a release in the near future so I can try out the fix from r23459 ? Or is it fairly safe to install a 3.0 beta? (Can I use a 2.5.3 server on RHEL7 with a 3.0 windows client? -- if I understand correctly, the fix is just in the client???) Best regards Wolfram On Thu, 1 Aug 2019 at 16:20, Antoine Martin wrote: > Can you please re-send to the mainling list? > > Antoine > > On 01/08/2019 20:54, Wolfram Humann wrote: > > Thanks for your reply. Some observations: > > 1. I managed to install 1.0.13 doing "sudo yum --releasever=7.1 install > > xpra" (had to manually install python-crypto before it would work but > > that's all) > > I had tried something similar before editing winswitch.repo and > > replacing > > "baseurl=http://winswitch.org/dists/CentOS/$releasever/$basearch/" with > > "baseurl=http://winswitch.org/dists/CentOS/7.1/$basearch/" but to my > > surprise yum still wanted to install version 2.5.3 (and failed as > > mentioned before when I tried to force yum to install 1.0.13) > > > > 2. I have a Konsole window receiving lots of output from a program and > > therefore scrolling fast. In 1.0.13 there is no problem with that. In > > 2.5.3 it always hangs a bit between screen updates. Also in 2.5.3 I > > sometimes receive messages about my connection being slow with some > > options what to do about it. I've never seen those in 1.0.13 > > > > 3. In 2.5.3 when I have menus hitting the bottom of the screen, I will > > have a vertical offset between the mouse-pointer and the selected entry > > (see attached screenshots -- the mouse pointer is 6-7 entries higher > > than the selection). That does not happen in 1.0.13. It might be worth > > mentioning that I have an (unusual?) setup of one horizontal (main) > > monitor and one vertical on the left, so there are screen coordinates on > > the left monitor extending below and above the main screen. > > > > If you have any suggestions, I can go back to 2.5.3. and try them out. > > But I will be on vacation for one week starting tomorrow, so I would do > > that afterwards. > > > > Thanks for maintaining and supporting this nice and very useful piece of > > software! > > Wolfram > > > > > > On Wed, 31 Jul 2019 at 19:17, Antoine Martin > > wrote: > > > > On 31/07/2019 20:41, Wolfram Humann via shifter-users wrote: > > > I've been using xpra 1.0.x before on an older workstation and > > 2.5.3 on the > > > current workstation. My impression is that the old version was > running > > > smoother and had less network problems. > > That's possible but it would be extremely surprising. > > There are no "network problems" that I am aware of. > > > > > That may be true or not!! I just > > > wanted to try it out. So I yum remove-ed the current version and > some > > > dependencies and tried > > > sudo yum install xpra-1.0.13 > > > and got > > > Loaded plugins: langpacks, search-disabled-repos > > > RHEL7-ATE_Workstation_tools > > (..) > > > Error: Package: xpra-1.0.13-1.r21370.el7_6.x86_64 (winswitch) > > > Requires: libvpx.so.5()(64bit) > > > Available: libvpx-xpra-1.7.0-1.el7_5.x86_64 (winswitch) > > > libvpx.so.5()(64bit) > > > Available: libvpx-xpra-1.7.0-1.el7_6.x86_64 (winswitch) > > > libvpx.so.5()(64bit) > > > Installing: libvpx-xpra-1.8.0-1.el7_6.x86_64 (winswitch) > > > ~libvpx.so.6()(64bit) > > > You could try using --skip-broken to work around the problem > > > You could try running: rpm -Va --nofiles --nodigest > > > > > > What can I do? > > yum is not capable of figuring out which libvpx version it should be > > installing, trying to install the latest one instead. > > That's a known issue with yum. > > > > You may be able to install the old version by manually installing > > libvpx-1.7 first. If yum still tries to upgrade libvpx, you will > have to > > hand pick the packages yourself.. > > > > Bear in mind that the 1.0 branch will be EOLed very soon. > > Personally, I wouldn't bother with it. Especially on RHEL 7.x, which > can > > run newer versions very well. > > > > Cheers, > > Antoine > > > > > > > > Best regards > > > Wolfram > > > > From antoine at nagafix.co.uk Mon Sep 16 09:44:46 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Sep 2019 15:44:46 +0700 Subject: [winswitch] Downgrading xpra In-Reply-To: References: <9bd89603-ea33-b764-2b34-acf3b1221b8e@nagafix.co.uk> <2c48fc03-bc52-f96f-c965-85493cfd87d7@nagafix.co.uk> Message-ID: <0967a3bc-a387-73c8-836e-99fd4e3c7b38@nagafix.co.uk> On 16/09/2019 15:33, Wolfram Humann via shifter-users wrote: > Do you expect a release in the near future so I can try out the fix from > r23459 ? Version 3 should be released sometime this week. > Or is it fairly safe to install a 3.0 beta? Unless I have missed something, it should be totally safe: the current beta builds are likely near identical to the final 3.0 release. > (Can I use a 2.5.3 server on > RHEL7 with a 3.0 windows client? Yes: http://xpra.org/trac/wiki/Versions All supported versions are compatible with each other. > -- if I understand correctly, the fix is > just in the client???) Correct. Cheers, Antoine > > Best regards > Wolfram > > On Thu, 1 Aug 2019 at 16:20, Antoine Martin wrote: > >> Can you please re-send to the mainling list? >> >> Antoine >> >> On 01/08/2019 20:54, Wolfram Humann wrote: >>> Thanks for your reply. Some observations: >>> 1. I managed to install 1.0.13 doing "sudo yum --releasever=7.1 install >>> xpra" (had to manually install python-crypto before it would work but >>> that's all) >>> I had tried something similar before editing winswitch.repo and >>> replacing >>> "baseurl=http://winswitch.org/dists/CentOS/$releasever/$basearch/" with >>> "baseurl=http://winswitch.org/dists/CentOS/7.1/$basearch/" but to my >>> surprise yum still wanted to install version 2.5.3 (and failed as >>> mentioned before when I tried to force yum to install 1.0.13) >>> >>> 2. I have a Konsole window receiving lots of output from a program and >>> therefore scrolling fast. In 1.0.13 there is no problem with that. In >>> 2.5.3 it always hangs a bit between screen updates. Also in 2.5.3 I >>> sometimes receive messages about my connection being slow with some >>> options what to do about it. I've never seen those in 1.0.13 >>> >>> 3. In 2.5.3 when I have menus hitting the bottom of the screen, I will >>> have a vertical offset between the mouse-pointer and the selected entry >>> (see attached screenshots -- the mouse pointer is 6-7 entries higher >>> than the selection). That does not happen in 1.0.13. It might be worth >>> mentioning that I have an (unusual?) setup of one horizontal (main) >>> monitor and one vertical on the left, so there are screen coordinates on >>> the left monitor extending below and above the main screen. >>> >>> If you have any suggestions, I can go back to 2.5.3. and try them out. >>> But I will be on vacation for one week starting tomorrow, so I would do >>> that afterwards. >>> >>> Thanks for maintaining and supporting this nice and very useful piece of >>> software! >>> Wolfram >>> >>> >>> On Wed, 31 Jul 2019 at 19:17, Antoine Martin >> > wrote: >>> >>> On 31/07/2019 20:41, Wolfram Humann via shifter-users wrote: >>> > I've been using xpra 1.0.x before on an older workstation and >>> 2.5.3 on the >>> > current workstation. My impression is that the old version was >> running >>> > smoother and had less network problems. >>> That's possible but it would be extremely surprising. >>> There are no "network problems" that I am aware of. >>> >>> > That may be true or not!! I just >>> > wanted to try it out. So I yum remove-ed the current version and >> some >>> > dependencies and tried >>> > sudo yum install xpra-1.0.13 >>> > and got >>> > Loaded plugins: langpacks, search-disabled-repos >>> > RHEL7-ATE_Workstation_tools >>> (..) >>> > Error: Package: xpra-1.0.13-1.r21370.el7_6.x86_64 (winswitch) >>> > Requires: libvpx.so.5()(64bit) >>> > Available: libvpx-xpra-1.7.0-1.el7_5.x86_64 (winswitch) >>> > libvpx.so.5()(64bit) >>> > Available: libvpx-xpra-1.7.0-1.el7_6.x86_64 (winswitch) >>> > libvpx.so.5()(64bit) >>> > Installing: libvpx-xpra-1.8.0-1.el7_6.x86_64 (winswitch) >>> > ~libvpx.so.6()(64bit) >>> > You could try using --skip-broken to work around the problem >>> > You could try running: rpm -Va --nofiles --nodigest >>> > >>> > What can I do? >>> yum is not capable of figuring out which libvpx version it should be >>> installing, trying to install the latest one instead. >>> That's a known issue with yum. >>> >>> You may be able to install the old version by manually installing >>> libvpx-1.7 first. If yum still tries to upgrade libvpx, you will >> have to >>> hand pick the packages yourself.. >>> >>> Bear in mind that the 1.0 branch will be EOLed very soon. >>> Personally, I wouldn't bother with it. Especially on RHEL 7.x, which >> can >>> run newer versions very well. >>> >>> Cheers, >>> Antoine >>> >>> > >>> > Best regards >>> > Wolfram >>> >> >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From basil.thompson at flyingbark.com.au Thu Sep 19 11:50:43 2019 From: basil.thompson at flyingbark.com.au (Basil Thompson) Date: Thu, 19 Sep 2019 20:50:43 +1000 Subject: [winswitch] xpra sound sink Message-ID: Hi There xpra audio sink question Do I have to have the same default plugin set on client and server in order for the sync to work ? I am struggling to get the audio sync feature enabled in the xpra client. Well at least I think that is the problem. So, so give as much info as possible.. When I run xpra attach on my Windows 10 box.. in the command line - and attach to a running server - if I right click on the xpra icon.. then hover over audio.. the video sync is greyed out. and there is a "pop up" or tip - that says server doesnt support video sync. Sound is enabled and sound does play.. just there is no sound buffer. The sound buffer chart exists .. if I open session info.. but the graph shows no info. If I run the server with -d av-sync I see a line that says something like Server = True , Client = False So from that it appears that the server actually does support av-sync. The server is a Centos 7 box. if I run the gstreamer utils on the centos box ( server ) .. it shows alsasink, pulsesink, and autoaudiosink - default is pulsesink on the windows box if I run the gstreamer utils I see directsoundsink, autoaudiosink - default is directsoundsink So, do I have to have the same default plugin set on client and server in order for the sync to work ? Audio works... its just delayed .. and gets more delayed the longer I play something with audio. I am running the latest version of xpra as of todays date // on both the server and the client. I have tried with and without nvidia encoding.. not that that would make a difference just mentioning that I am using nvenc / cuda .. Kind Regards Basil Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From antoine at nagafix.co.uk Thu Sep 19 15:14:05 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 19 Sep 2019 21:14:05 +0700 Subject: [winswitch] xpra sound sink In-Reply-To: References: Message-ID: On 19/09/2019 17:50, Basil Thompson via shifter-users wrote: > Hi There > > xpra audio sink question > > Do I have to have the same default plugin set on client and server in order > for the sync to work ? I'm not sure what the "default plugin" is. The audio codec must match, but that's automatic. > I am struggling to get the audio sync feature enabled in the xpra client. > Well at least I think that is the problem. > > So, so give as much info as possible.. > > When I run xpra attach on my Windows 10 box.. in the command line - and > attach to a running server - if I right click on the xpra icon.. then hover > over audio.. the video sync is greyed out. and there is a "pop up" or tip - > that says server doesnt support video sync. > > Sound is enabled and sound does play.. just there is no sound buffer. > The sound buffer chart exists .. if I open session info.. but the graph > shows no info. > > If I run the server with -d av-sync I see a line that says something like > Server = True , Client = False > > So from that it appears that the server actually does support av-sync. The > server is a Centos 7 box. > > if I run the gstreamer utils on the centos box ( server ) .. it shows > alsasink, pulsesink, and autoaudiosink - default is pulsesink > > on the windows box if I run the gstreamer utils I see > directsoundsink, autoaudiosink - default is directsoundsink > > > So, do I have to have the same default plugin set on client and server in > order for the sync to work ? > > Audio works... its just delayed .. and gets more delayed the longer I play > something with audio. > > I am running the latest version of xpra as of todays date // on both the > server and the client. You must be affected by this bug: http://xpra.org/trac/changeset/23662/xpra You can just download any recent beta builds and it will have that fix included. As for av-sync in general, your mileage may vary: there are so many variables at play that it is simply impossible to make it work reliably in all cases. Cheers, Antoine > > I have tried with and without nvidia encoding.. not that that would make a > difference just mentioning that I am using nvenc / cuda .. > > Kind Regards > > Basil From stdedos at gmail.com Mon Sep 23 09:15:38 2019 From: stdedos at gmail.com (=?UTF-8?B?zqPPhM6xz43Pgc6/z4Igzp3PhM6tzr3PhM6/z4I=?=) Date: Mon, 23 Sep 2019 11:15:38 +0300 Subject: [winswitch] xpra: probe for active sessions Message-ID: Hello there, In some of my bug reports, it appears that I am doing a mistake of "specifying" where to start xpra instances. [i] One example is trying to start on a screen that already exists. However, it seems complicated to my usecase "not" to specify a screen number, since: 1] I usually have 2 sessions active (`xpra shadow` and `xpra start gnome-terminal`) 2] I'd like not to keep stale sessions active For [i], I would assume a fail-fast (instead of a timeout) client-side solution would quickly inform me that "try to attach instead". It could even automatically/interactively ask to do so? For [2], I'd assume that `--start-child` / `--exit-with-child` would help (I don't use it, since I think I had issues with it. I'll try to dig on that one). However, what's the behavior on children started from that process? Children started from `--start-new-commands=yes`? Is it wait-all, or simply polling the pid of the initially started process? What if multiple `--start-child` are given? I assume that `xpra attach` (plain) would try to attach to the exactly-one child active on the server. To "solve" [1], is it acceptable to, otherwise, provide an error message roughly saying: Cannot decide where to attach. Please specify applicable screen: `xpra list`-output Additionally, for `xpra list`: Can the screens have names? And/or specify "how" they are started? xpra client can tell `xpra gnome-terminal :20` or `xpra compiz :0` (or equivalent) on the tray icon. Can `xpra list` do that too? I can create the tickets myself, if you believe that the missing features are well-defined (or you can reply with links yourself). ??????? ??????? From antoine at nagafix.co.uk Mon Sep 23 13:19:45 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 23 Sep 2019 19:19:45 +0700 Subject: [winswitch] xpra: probe for active sessions In-Reply-To: References: Message-ID: <088a6de1-3f14-b2df-31e8-d7c0e889dc79@nagafix.co.uk> On 23/09/2019 15:15, ??????? ??????? via shifter-users wrote: > Hello there, > > In some of my bug reports, it appears that I am doing a mistake of > "specifying" where to start xpra instances. > [i] One example is trying to start on a screen that already exists. > > However, it seems complicated to my usecase "not" to specify a screen > number, since: > 1] I usually have 2 sessions active (`xpra shadow` and `xpra start > gnome-terminal`) > 2] I'd like not to keep stale sessions active > > For [i], I would assume a fail-fast (instead of a timeout) client-side > solution would quickly inform me that "try to attach instead". It could > even automatically/interactively ask to do so? I'm sure it sounds easy, but when starting over ssh it isn't so. Feel free to create a ticket. > For [2], I'd assume that `--start-child` / `--exit-with-child` would help > (I don't use it, since I think I had issues with it. I'll try to dig on > that one). > However, what's the behavior on children started from that process? Which process? > Children started from `--start-new-commands=yes`? Those are the same as "--start", they are not taken into account by "--exit-with-children". > Is it wait-all, or simply > polling the pid of the initially started process? On MS Windows, we use polling, on Posix we have SIGHUP. > What if multiple `--start-child` are given? Then it waits for the last child to exit to trigger exit-with-children. > I assume that `xpra attach` (plain) would try to attach to the exactly-one > child active on the server. I assume that you mean "instance" here instead of child? Attaching to a child doesn't make sense. > To "solve" [1], is it acceptable to, otherwise, provide an error message > roughly saying: > Cannot decide where to attach. Please specify applicable screen: > `xpra list`-output The current version shows this message: xpra initialization error: there are multiple servers running, please specify I am reluctant to change the wording too much, because servers may or may not be attached to a display, ie: proxy server instance are not. > Additionally, for `xpra list`: > Can the screens have names? They can have one if you start your server with --session-name= Or if you start a single application with --start=, then this will be used as default session name. You can view this value with: xpra id :DISPLAY (or amongst more information via xpra info) Listing the names in xpra list would be possible, but: * I am reluctant to change the xpra list command output format * You can already use the "xpra sessions" GUI for that > And/or specify "how" they are started? xpra client can tell `xpra > gnome-terminal :20` or `xpra compiz :0` (or equivalent) on the tray icon. > Can `xpra list` do that too? > > I can create the tickets myself, if you believe that the missing features > are well-defined (or you can reply with links yourself). Please create tickets for the issues you care about. Thanks, Antoine > > ??????? ??????? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From stdedos at gmail.com Tue Sep 24 12:43:54 2019 From: stdedos at gmail.com (=?UTF-8?B?zqPPhM6xz43Pgc6/z4Igzp3PhM6tzr3PhM6/z4I=?=) Date: Tue, 24 Sep 2019 14:43:54 +0300 Subject: [winswitch] Install python3-only xpra Message-ID: Hello there, On a new Ubuntu 18.04 system, I do: $ sudo apt-get install xpra python3-xpra However, among numerous packages, I am getting: [...] python2-xpra [...] Why is that? Isn't / Should there be an easier way to install python3-only xpra? I understand your need to support it, but AFAIK you are also saying that Py3 is fully supported and working. ??????? ??????? From antoine at nagafix.co.uk Tue Sep 24 14:23:57 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 24 Sep 2019 20:23:57 +0700 Subject: [winswitch] Install python3-only xpra In-Reply-To: References: Message-ID: <828b0efb-b0de-0890-6942-be9610bb1be5@nagafix.co.uk> On 24/09/2019 18:43, ??????? ??????? via shifter-users wrote: > Hello there, > > On a new Ubuntu 18.04 system, I do: > > $ sudo apt-get install xpra python3-xpra > > However, among numerous packages, I am getting: > > [...] python2-xpra [...] > > Why is that? Isn't / Should there be an easier way to install python3-only > xpra? Maybe this will work? (untested): apt-get install python3-xpra apt-get install xpra "xpra" is a meta-package, which depends on either "python2-xpra" or "python3-xpra", and recommends "python2-xpra" in version 2.x > I understand your need to support it, but AFAIK you are also saying that > Py3 is fully supported and working. It is, and it is now the default in v3. So installing "xpra" will only install "python3-xpra" by default. Cheers, Antoine > > ??????? ??????? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Sep 24 14:48:16 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 24 Sep 2019 20:48:16 +0700 Subject: [winswitch] Install python3-only xpra In-Reply-To: <828b0efb-b0de-0890-6942-be9610bb1be5@nagafix.co.uk> References: <828b0efb-b0de-0890-6942-be9610bb1be5@nagafix.co.uk> Message-ID: <98bcf2ad-d525-eddd-a683-0a4600af4b03@nagafix.co.uk> On 24/09/2019 20:23, Antoine Martin wrote: > On 24/09/2019 18:43, ??????? ??????? via shifter-users wrote: >> Hello there, >> >> On a new Ubuntu 18.04 system, I do: >> >> $ sudo apt-get install xpra python3-xpra >> >> However, among numerous packages, I am getting: >> >> [...] python2-xpra [...] >> >> Why is that? Isn't / Should there be an easier way to install >> python3-only >> xpra? > Maybe this will work? (untested): > apt-get install python3-xpra > apt-get install xpra Forgot one important command line argument: apt-get install xpra --no-install-recommends Or just wait less than 48 hours for 3.0 to be released. Antoine > > "xpra" is a meta-package, which depends on either "python2-xpra" or > "python3-xpra", and recommends "python2-xpra" in version 2.x > >> I understand your need to support it, but AFAIK you are also saying that >> Py3 is fully supported and working. > It is, and it is now the default in v3. > So installing "xpra" will only install "python3-xpra" by default. > > Cheers, > Antoine > >> >> ??????? ??????? >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > From totaam at xpra.org Mon Sep 30 19:46:20 2019 From: totaam at xpra.org (Antoine Martin) Date: Tue, 1 Oct 2019 01:46:20 +0700 Subject: [winswitch] ANNOUNCE: Xpra 3.0 LTS Message-ID: Hi, The new Xpra 3.0 LTS release is here. This is the first version to switch to Python 3 by default, on all the platforms that support it. Python 2 builds will continue to be available for the duration of this LTS branch, which should be at least 3 years. More information on versions and compatibility can be found here: https://xpra.org/trac/wiki/Versions Apart from completing the Python 3 port, here are some of the key improvements in this release: * HTML5 client user interface, thanks to Mark Harkin * Window handling: smoother resizing, honouring gravity, readonly lock * "xpra top" subcommand * Faster client and server startup * OpenGL: reliable driver probing, cursor paint, MacOS transparency * Encodings: lossless window scrolling, scrolling acceleration, etc * Clipboard: native code re-write, HTML5 asynchronous clipboard & images * Authentication: modular client authentication handlers, SQL modules * Network: listen mode, retry to connect, mDNS updates, better proxy * Testing: more test coverage, including HTML5 client automated testing * Misc: basic native Wayland client support, user interface cleanups.. For more details, including links to the documentation and tickets, see: https://xpra.org/trac/wiki/News#a3.0ImportantFeatures The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From basil.thompson at flyingbark.com.au Thu Sep 26 02:46:10 2019 From: basil.thompson at flyingbark.com.au (Basil Thompson) Date: Thu, 26 Sep 2019 11:46:10 +1000 Subject: [winswitch] xpra sound sink In-Reply-To: References: Message-ID: Hi Antoine I still haven't had to time test this.. but wanted to at least reply and say that you for your quick response and suggestions. Kind Regards Basil On Fri, 20 Sep 2019 at 00:14, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 19/09/2019 17:50, Basil Thompson via shifter-users wrote: > > Hi There > > > > xpra audio sink question > > > > Do I have to have the same default plugin set on client and server in > order > > for the sync to work ? > I'm not sure what the "default plugin" is. > The audio codec must match, but that's automatic. > > > I am struggling to get the audio sync feature enabled in the xpra client. > > Well at least I think that is the problem. > > > > So, so give as much info as possible.. > > > > When I run xpra attach on my Windows 10 box.. in the command line - and > > attach to a running server - if I right click on the xpra icon.. then > hover > > over audio.. the video sync is greyed out. and there is a "pop up" or > tip - > > that says server doesnt support video sync. > > > > Sound is enabled and sound does play.. just there is no sound buffer. > > The sound buffer chart exists .. if I open session info.. but the graph > > shows no info. > > > > If I run the server with -d av-sync I see a line that says something like > > Server = True , Client = False > > > > So from that it appears that the server actually does support av-sync. > The > > server is a Centos 7 box. > > > > if I run the gstreamer utils on the centos box ( server ) .. it shows > > alsasink, pulsesink, and autoaudiosink - default is pulsesink > > > > on the windows box if I run the gstreamer utils I see > > directsoundsink, autoaudiosink - default is directsoundsink > > > > > > So, do I have to have the same default plugin set on client and server in > > order for the sync to work ? > > > > Audio works... its just delayed .. and gets more delayed the longer I > play > > something with audio. > > > > I am running the latest version of xpra as of todays date // on both the > > server and the client. > You must be affected by this bug: > http://xpra.org/trac/changeset/23662/xpra > > You can just download any recent beta builds and it will have that fix > included. > > As for av-sync in general, your mileage may vary: there are so many > variables at play that it is simply impossible to make it work reliably > in all cases. > > Cheers, > Antoine > > > > > > I have tried with and without nvidia encoding.. not that that would make > a > > difference just mentioning that I am using nvenc / cuda .. > > > > Kind Regards > > > > Basil > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From fuzzytew at gmail.com Mon Sep 30 23:10:24 2019 From: fuzzytew at gmail.com (Karl Semich) Date: Mon, 30 Sep 2019 18:10:24 -0400 Subject: [winswitch] Xpra as screen recorder? Message-ID: Hi, I've been thinking on how to make highly compact screen recordings and my focus landed on xpra packet logs. Does anybody have any thoughts on possibly using xpra to record/replay sessions? Has this been attempted before / does it seem a reasonable idea to you? Thanks so much, Karl Semich